From pinedev@shivax2.cac.washington.edu Mon Aug 31 22:03:16 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19927; Mon, 31 Aug 92 22:03:16 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21670; Mon, 31 Aug 92 22:03:15 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21664; Mon, 31 Aug 92 22:03:14 -0700 Date: Mon, 31 Aug 1992 21:47:56 -0700 (PDT) From: Mark Crispin Subject: welcome to the c-client interest list To: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello. If you received this message, you are on the c-client interest list at the University of Washington. The purpose of this list is for discussion and announcements related to the c-client library for mail software. You are on this list because at some point in the past you expressed an interest in this topic. It is intended that this list be of a low-volume, high-signal, and technical nature. To post mail to this list, send mail to: c-client@CAC.Washington.EDU To request addition/deletions to the list, send mail to: c-client-request@CAC.Washington.EDU Related mailing lists which may be of interest: IMAP@CAC.Washington.EDU IMAP protocol pine-info@CAC.Washington.EDU Pine mail UA information ECS-info@EDM.ISAC.CA ECS (Windows IMAP client) information Regards, Mark Crispin Networks and Distributed Computing University of Washington From pinedev@shivax2.cac.washington.edu Tue Sep 1 05:15:17 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26528; Tue, 1 Sep 92 05:15:17 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23717; Tue, 1 Sep 92 05:15:16 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from relay1.UU.NET by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23711; Tue, 1 Sep 92 05:15:14 -0700 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA18837; Tue, 1 Sep 92 08:15:13 -0400 Received: from bwc.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 081349.23280; Tue, 1 Sep 1992 08:13:49 EDT Received: from xenia.bwc.org by bwc.org (4.1/SMI-4.1) id AA09174; Tue, 1 Sep 92 14:54:28 IDT Received: by xenia.bwc.org (4.1/SMI-4.1) id AA04763; Tue, 1 Sep 92 14:56:08 IDT Date: Tue, 1 Sep 1992 14:14:05 +0300 (IDT) From: Laurence Lundblade Subject: Hostnames for hostless addresses To: C-Client Mailing List Cc: Bob Gregory Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I'm looking for a way to tell the c-client what address to use when qualifying domainless addresses. Right now it use the result of gethostbyname (the /etc/hosts, YP and DNS lookup). This results in an address with a hostname in it, where it might be better not to have one. Also, one can't always control what the hostname is set too. I realize that it would be best to have the addresses in the mail files fully qualified, but that isn't possible in this case. Could either an argument be added to mail_open, or a mail_setdomain() call be added to set the domain name so the calling program could control this? Then for example in Pine, all the domain names would be consistent. Thanks... Laurence Lundblade 206-543-5617 lgl@cac.washington.edu Computing and Communications, University of Washington, Seattle (Temporarily abroad till Sept 19; reply to lgl@cac.washington.edu) From pinedev@shivax2.cac.washington.edu Tue Sep 8 01:14:28 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04850; Tue, 8 Sep 92 01:14:28 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25077; Tue, 8 Sep 92 01:14:16 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from relay2.UU.NET by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25071; Tue, 8 Sep 92 01:14:15 -0700 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA26974; Tue, 8 Sep 92 04:14:14 -0400 Received: from bwc.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 041358.9727; Tue, 8 Sep 1992 04:13:58 EDT Received: from xenia.bwc.org by bwc.org (4.1/SMI-4.1) id AA06945; Tue, 8 Sep 92 10:13:09 IST Received: by xenia.bwc.org (4.1/SMI-4.1) id AA12745; Tue, 8 Sep 92 10:14:55 IST Date: Tue, 8 Sep 1992 10:02:39 +0200 (IST) From: Laurence Lundblade Subject: mail_append() To: C-Client Mailing List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm starting to work on mail_append() for the c-client driver I'm writing here. Don't quite know who all's on this list so I'll mention that this corresponds the the APPEND command in an upcoming version of IMAP2bis. What I'm trying to figure out is how to decide what driver to call. Mail_append() is a bit of a new thing in that it is not an operation on an already open mailbox, the format of which known, and therefor the driver is known. I'm planning on passing mail_append the mailbox name and a string which contains the RFC-822 message. Seems like the choices are: - Just pass it the mailbox name and the message and let it decide on the format of the mailbox either based on a default, or based on the format of the existing mailbox if it exists. Would have to default if it didn't exist. - Pass it a stream of some other open mailbox to serve to indicate the format of the mailbox. - Some other way, indicate the format of the mailbox I'll probably pick #2 for now since it's easy and there's not much code involved in any of these options. I'm mainly sending this message to see if anyone has any immediate ideas or plans. Thanks, LL From pinedev@shivax2.cac.washington.edu Tue Sep 8 10:55:54 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA13530; Tue, 8 Sep 92 10:55:54 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29411; Tue, 8 Sep 92 10:55:39 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29405; Tue, 8 Sep 92 10:55:38 -0700 Received: from (KSL-Mac-78.Stanford.EDU) by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA12584; Tue, 8 Sep 92 10:50:32 PDT Date: Tue, 8 Sep 1992 10:56:00 PDT From: Bill Yeager Subject: Re: mail_append() To: Laurence Lundblade Cc: C-Client Mailing List In-Reply-To: Your message of Tue, 8 Sep 1992 10:02:39 +0200 (IST) Message-Id: >> - Pass it a stream of some other open mailbox to serve to indicate the format of the mailbox. I think this can be somewhat subtle. 1. If the mailbox to which one is appending exists, then the driver can be automatically decided by the mailbox type of this mailbox. 2. If it doesn't exist, then if the mailbox type of INBOX is known, I imagine a user would like to have that format for append. I certainly would, even if I often open mailboxes of a different mailbox type. I, for example, use tenex format for the majority of my messages, but often read bezerkly mailboxes. I'd want my backing-store of saved messages to be in tenex format(*). 3. If INBOX format isn't known, then your plan above makes sense. The question I have is: What does append mean if a user's INBOX mailbox type is mh mode? Does one create a subdirectory in the Mail/ folder called Append/ and then iterate by message number as is done in mh mode? Bill (*) The intention all along with IMAP was that the user should never have to worry about the format of mail on the repository, but this hasn't worked out because people often connect directly to this system to read their mail from home. This mode of operation will persist until most users have network connections to their homes which I think is still in the near-distant future. So, I guess it is necessary to be able to accomodate all of these formats. ------- From pinedev@shivax2.cac.washington.edu Wed Sep 9 09:56:30 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA05868; Wed, 9 Sep 92 09:56:30 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA10250; Wed, 9 Sep 92 09:55:26 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from Ikkoku-Kan.Panda.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA10244; Wed, 9 Sep 92 09:55:19 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NeXT-1.0 (From Sendmail 5.52)/UW-NDC/Panda Revision: 2.27.MRC ) id AA00591; Wed, 9 Sep 92 09:55:10 PDT Date: Wed, 9 Sep 1992 09:49:50 -0700 (PDT) From: Mark Crispin Subject: re: mail_append() To: Laurence Lundblade Cc: C-Client Mailing List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Laurence - I have already decided to add a `driver type' string to the driver dispatch table, and make those functions which create a mailbox use that. In the case of an existing mailbox, it should use the format of that mailbox. I haven't gotten around to it yet because I've been tied up with lots of other stuff. -- Mark -- From pinedev@shivax2.cac.washington.edu Thu Sep 10 05:43:29 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19470; Thu, 10 Sep 92 05:43:29 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19303; Thu, 10 Sep 92 05:43:22 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from relay1.UU.NET by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19297; Thu, 10 Sep 92 05:43:20 -0700 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA29215; Thu, 10 Sep 92 08:43:16 -0400 Received: from bwc.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 084223.9412; Thu, 10 Sep 1992 08:42:23 EDT Received: from xenia.bwc.org by bwc.org (4.1/SMI-4.1) id AA10715; Thu, 10 Sep 92 14:39:20 IST Received: by xenia.bwc.org (4.1/SMI-4.1) id AA16311; Thu, 10 Sep 92 14:41:08 IST Date: Thu, 10 Sep 1992 14:30:54 +0200 (IST) From: Laurence Lundblade Subject: re: mail_append() To: Mark Crispin Cc: C-Client Mailing List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Mark, I don't quite know what you mean. Are you adding the "driver type" to each entry in the dispatch table (the "DRIVER" defined in mail.h) or are you adding on type to the whole dispatch table to act as a default type. I've thought about this a little bit and concluded that we don't really have to support multiple different mail formats for mail_find(), mail_append() and such since 99% of all users will only have mail in one format. I know we all enjoy a challenge, but it seems a reasonable simplification to support one driver at a time for the active mail, and other drivers in case the fellow wants to occasionally browse a mailbox in some other format. Phrased another way, it seems much more important to get things like net news, subscribe/unsubscribe, fancy searching, and append running than it does to support some fellow who wants to have his mail in three different formats and operate freely between them because the searching and news are what the users will care about. Based on this I suggest that mail_append(), mail_find(), mail_rename(), mail_delete() and mail_create() only operate on the first driver that is lunk in with mail_link(). Seems it will make our lives much easier. LL On Wed, 9 Sep 1992, Mark Crispin wrote: > > Laurence - > > I have already decided to add a `driver type' string to the driver > dispatch table, and make those functions which create a mailbox use that. In > the case of an existing mailbox, it should use the format of that mailbox. > > I haven't gotten around to it yet because I've been tied up with lots of > other stuff. > > -- Mark -- > From pinedev@shivax2.cac.washington.edu Thu Sep 10 10:20:51 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA24578; Thu, 10 Sep 92 10:20:51 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21840; Thu, 10 Sep 92 10:20:36 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21834; Thu, 10 Sep 92 10:20:35 -0700 Received: from (KSL-Mac-78.Stanford.EDU) by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA25837; Thu, 10 Sep 92 10:08:59 PDT Date: Thu, 10 Sep 1992 10:14:32 PDT From: Bill Yeager Subject: re: mail_append() To: Laurence Lundblade Cc: Mark Crispin , C-Client Mailing List In-Reply-To: Your message of Thu, 10 Sep 1992 14:30:54 +0200 Message-Id: >> Based on this I suggest that mail_append(), mail_find(), mail_rename(), mail_delete() and mail_create() only operate on the first driver that is lunk in with mail_link(). Seems it will make our lives much easier. Seems a little strange to me that which mail box format is chosen is a function of the hardcoded sequence of calls to mail_link() from imapd.c. That certainly would not work here where we have: mail_link (&tenexdriver); /* install the Tenex mail driver */ mail_link (&mboxdriver); /* install the mbox driver - wjy 17 Aout 92*/ mail_link (&bezerkdriver); /* install the Berkeley mail driver */ And, most people use tenex format by others also use the other two formats. Maybe you don't mean hard linked in the code, but perhaps the first driver loaded in mail_open() as the "factory?" I don't think either of these choices are good solutions in environments where multiple mailbox formats are supported. Bill ------- From pinedev@shivax2.cac.washington.edu Thu Sep 10 10:30:36 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA24786; Thu, 10 Sep 92 10:30:36 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21942; Thu, 10 Sep 92 10:30:33 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from Ikkoku-Kan.Panda.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21936; Thu, 10 Sep 92 10:30:23 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NeXT-1.0 (From Sendmail 5.52)/UW-NDC/Panda Revision: 2.27.MRC ) id AA00471; Thu, 10 Sep 92 10:30:17 PDT Date: Thu, 10 Sep 1992 10:27:09 -0700 (PDT) From: Mark Crispin Subject: re: mail_append() To: Laurence Lundblade Cc: C-Client Mailing List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Laurence - The `driver type' will be a string in the dispatch table, a single entry such as "mbox", etc. So you can get a `name' of the type of mailbox. The idea then is that you can do something like: mail_create (name,"tenex"); Of course, there *will* be defaulting. I haven't thought all of this through since, as you noted, there are other things that are much higher on the queue to do. -- Mark -- From pinedev@shivax2.cac.washington.edu Fri Sep 11 11:49:46 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA16287; Fri, 11 Sep 92 11:49:46 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04382; Fri, 11 Sep 92 11:49:27 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from relay2.UU.NET by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04376; Fri, 11 Sep 92 11:49:17 -0700 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA08605; Fri, 11 Sep 92 14:48:48 -0400 Received: from bwc.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 144358.10763; Fri, 11 Sep 1992 14:43:58 EDT Received: from xenia.bwc.org by bwc.org (4.1/SMI-4.1) id AA12557; Fri, 11 Sep 92 20:27:18 IST Received: by xenia.bwc.org (4.1/SMI-4.1) id AA18016; Fri, 11 Sep 92 20:29:09 IST Date: Fri, 11 Sep 1992 20:22:37 +0200 (IST) From: Laurence Lundblade Subject: re: mail_append() To: Mark Crispin Cc: C-Client Mailing List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sounds great Mark! It give us the option to do what we want. I was worried about things like the ambiguity of mailboxes of the same name in different formats and naming mailboxes in formats like mh where the the mailbox isn't a particular file. This sounds like it will take care of things just fine. Bill, What I was thinking about the mail_link() calls, was that you have control at run time as to which driver you link first. You could have command line flags that cause the drivers to be linked in various orders, though it's true that you'll only get to create, delete and append for that one driver. Mark's solution is much better. LL On Thu, 10 Sep 1992, Mark Crispin wrote: > > Laurence - > > The `driver type' will be a string in the dispatch table, a single entry > such as "mbox", etc. So you can get a `name' of the type of mailbox. The > idea then is that you can do something like: > mail_create (name,"tenex"); > > Of course, there *will* be defaulting. I haven't thought all of this > through since, as you noted, there are other things that are much higher on > the queue to do. > > -- Mark -- > From pinedev@shivax2.cac.washington.edu Fri Sep 11 14:13:18 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19443; Fri, 11 Sep 92 14:13:18 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA05995; Fri, 11 Sep 92 14:13:14 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA05989; Fri, 11 Sep 92 14:13:12 -0700 Received: from (KSL-Mac-78.Stanford.EDU) by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA14828; Fri, 11 Sep 92 13:57:37 PDT Date: Fri, 11 Sep 1992 14:03:13 PDT From: Bill Yeager Subject: re: mail_append() To: Laurence Lundblade Cc: Mark Crispin , C-Client Mailing List In-Reply-To: Your message of Fri, 11 Sep 1992 20:22:37 +0200 Message-Id: Laurence, Thanks for the clarification. I too agree with Mark's approach with appropriate defaulting for environments like ours where different users have different default INBOX types. Bill ------- From pinedev@shivax2.cac.washington.edu Wed Sep 23 12:05:47 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA01930; Wed, 23 Sep 92 12:05:47 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25618; Wed, 23 Sep 92 12:03:30 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from olive.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25612; Wed, 23 Sep 92 12:03:29 -0700 Received: by olive.cac.washington.edu (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.21 ) id AA07372; Wed, 23 Sep 92 11:59:38 PDT Date: Wed, 23 Sep 1992 11:50:12 -0700 (PDT) From: Laurence Lundblade Subject: Re: Domain names (fwd) To: c-client@cac.washington.edu Cc: Bob Gregory Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A while ago I indicated that it would be nice if you could set the mail domain the c-client uses for parsing unqaulified addresses. Here's some other folks that would like to see it happen. I suppose we could be pedegogical and say no to encourage people to fully qualify addresses, but sendmail configuration is difficult and I don't know if this is a battle worth fighting. I think this would also make Pine a little more self consistent. LL ---------- Forwarded message ---------- Date: Wed, 23 Sep 1992 17:13:40 +0100 (BST) From: Laurie Cuthbert To: Philip Hazel Cc: pine-info@cac.washington.edu Subject: Re: Domain names Yes - it does do this and at first we thought, like you, that it would be a major problem. However, we have decided that pine is so worth using that we changed the sendmail configuration to add the local domain name to all mail, irrespective of the MUA being used. Presumably you are using the UK sendmail configuration version 2.1 - if so there is a parameter that turns on or off the local channel domain stamping. In fact it proved to have an added benefit for us becuase we use departmental domains internally, but only the site domain for external messages, with PP massaging the name fields. By ensuring that the domain name is ALWAYS stamped PP will correctly massage all fields, including local CC fields. Regards Laurie Cuthbert On Wed, 23 Sep 1992, Philip Hazel wrote: > I've had to back off using Pine for the moment, because of the problem > described below. Luckily, I was just experimenting with it. Any ideas as > to how to get round it, apart from hacking the code? > > I have > > # Domain name you are in e.g. nwnet.net, cac.washington.edu, bwc.org > user-domain=cus.cam.ac.uk > > # Eliminate host part from hostname, using only domain part for domain name > use-only-domain-name=yes > > and for all the mail I send out, this works fine. Unqualified names end up > as "name@cus.cam.ac.uk", which is what is wanted. There are several > machines in the cus.cam.ac.uk domain, but they form a common mail system. > The problem arises when I receive mail from another local user whose mail > user agent does *not* fully qualify names. So I have something like > > From: someuser > > in my inbox. Pine displays this as > > From: someuser@bootes.cus.cam.ac.uk > > when I am running it on the machine bootes.cus.cam.ac.uk, or with a > different name if I run it on another machine. This is disastrous, > especially if I want to reply. [It is more disastrous for a machine in the > UK than for other Internet machines, because of the dual mail registration > with the JANET network. Only the shorter name is registered with JANET.] > It looks as if Pine (version 3.05, running on a Sun) is ignoring the > use-only-domain-name parameter when displaying unqualified names in > incoming mail. > > Philip Hazel > > -- > Internet: P.Hazel@ucs.cam.ac.uk University Computing Service, > JANET: P.Hazel@uk.ac.cam.ucs Computer Laboratory, Pembroke St, > Phone: +44 223 334714 Cambridge CB2 3QG, England. From pinedev@shivax2.cac.washington.edu Wed Sep 23 13:18:01 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03296; Wed, 23 Sep 92 13:18:01 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26464; Wed, 23 Sep 92 13:17:56 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from eco.twg.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26458; Wed, 23 Sep 92 13:17:46 -0700 Received: from LOCAL.eco.twg.com by eco.twg.com (5.65/ECO.m-$Revision: 2.16 $) id AA00944; Wed, 23 Sep 92 16:18:15 -0400 Message-Id: <9209232018.AA00944@eco.twg.com> Received: from navajo.twg.com by apache.twg.com id <12747-0@apache.twg.com>; Wed, 23 Sep 1992 13:17:15 -0700 From: "David Herron" Subject: Re: Domain names (fwd) To: Laurence Lundblade Cc: c-client@cac.washington.edu, Bob Gregory Date: Wed, 23 Sep 92 13:20:27 PDT In-Reply-To: Your message of Wed, 23 Sep 1992 11:50:12 -0700 (PDT). Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 26 TEXT , 4 TEXT Always stamping fully qualified domain names on mail addresses is a Very Good Practice. One of the major misfeatures that Sendmail has foisted upon the world is the practice of not doing so. Places where I've seen problems: - If the nameservers are currently dead & you've got a partially qualified name it might do the wrong thing (or at least take a long time to do nothing because it's waiting for nameserver timeouts). NOTE: It's been a couple of years since this was seen and I don't remember details. - If someone forwards a piece of mail sent by a local user, it doesn't have qualified addresses. If it's forwarded to a non-local user the local MTA is unable to rewrite the addresses & the recipient gets mail with an embedded message containing addresses which looks to be local to that user. If the user then tries to use that embedded message to create a reply, the addresses are way-wrong & confusion can easily result. - Some digest creators do not qualify addresses in the embedded headers. This is the same as the previous problem, and is the common case where it happens. Some UA's provide a command for automagically bursting a digest and turning it into `n' new messages in the users mailbox. The user may wish to reply and/or forward to any of those messages but they've got screwed up addresses ... <- David Herron (work) (home) <- <- During the '80s Usenet's mantra was: "Not all the world's a VAX". <- During the '90s I hope it becomes: "Not all the world's DOS (ick)". From pinedev@shivax2.cac.washington.edu Wed Sep 23 13:59:42 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04062; Wed, 23 Sep 92 13:59:42 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26927; Wed, 23 Sep 92 13:59:37 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from Ikkoku-Kan.Panda.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26917; Wed, 23 Sep 92 13:58:13 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA00329; Wed, 23 Sep 92 13:56:37 -0700 Date: Wed, 23 Sep 1992 13:45:01 -0700 (PDT) From: Mark Crispin Subject: Re: Domain names (fwd) To: Laurence Lundblade Cc: c-client@cac.washington.edu, Bob Gregory In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mr. c-client is aware of this problem. He is of the religion that states that addresses without a fully-qualified domain name cannot possibly work well enough to ever be trusted. Furthermore, he feels that what bits are on the disk should be of little concern to the user; if users want host-less addressing that is what their wonderful user interfaces are supposed to accomplish for them. However, he is also aware that circumstances force him to do something to parse an address without a host name other than just toss it out. And he is also aware that it's all his fault that he sets that default host name to the local host name and gives the main program no opportunity to change it. So... he is probably going to make that default host name be a global variable that gets defaulted to the local host name if the main program doesn't take care of it first. This will hopefully solve the immediate hassle in Pine. However, that doesn't change his fundamental lack of sympathy for the idea that it is ever reasonable to transmit e-mail bits without proper domain names. He has wasted entirely too many hours of his life in dealing with something that is essentially invalid and undefined. -- Mark -- From pinedev@shivax2.cac.washington.edu Wed Sep 23 14:06:38 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04309; Wed, 23 Sep 92 14:06:38 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA27034; Wed, 23 Sep 92 14:06:30 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from olive.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA27027; Wed, 23 Sep 92 14:06:29 -0700 Received: by olive.cac.washington.edu (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.21 ) id AA07434; Wed, 23 Sep 92 14:00:02 PDT Date: Wed, 23 Sep 1992 13:58:06 -0700 (PDT) From: Laurence Lundblade Subject: Re: Domain names (fwd) To: Mark Crispin Cc: c-client@cac.washington.edu, Bob Gregory In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sounds good to me Mark. I will also happily reflect your advise in the Pine tech-notes that use of this features is best considered a transitionary measure until the site can get to the point where they can use fully qualified host names. Thanks! LL On Wed, 23 Sep 1992, Mark Crispin wrote: > Date: Wed, 23 Sep 1992 13:45:01 -0700 (PDT) > From: Mark Crispin > To: Laurence Lundblade > Cc: c-client@cac.washington.edu, Bob Gregory > Subject: Re: Domain names (fwd) > > Mr. c-client is aware of this problem. > > He is of the religion that states that addresses without a fully-qualified > domain name cannot possibly work well enough to ever be trusted. Furthermore, > he feels that what bits are on the disk should be of little concern to the > user; if users want host-less addressing that is what their wonderful user > interfaces are supposed to accomplish for them. > > However, he is also aware that circumstances force him to do something to > parse an address without a host name other than just toss it out. And he is > also aware that it's all his fault that he sets that default host name to the > local host name and gives the main program no opportunity to change it. > > So... he is probably going to make that default host name be a global > variable that gets defaulted to the local host name if the main program > doesn't take care of it first. This will hopefully solve the immediate hassle > in Pine. > > However, that doesn't change his fundamental lack of sympathy for the idea > that it is ever reasonable to transmit e-mail bits without proper domain > names. He has wasted entirely too many hours of his life in dealing with > something that is essentially invalid and undefined. > > -- Mark -- > From pinedev@shivax2.cac.washington.edu Fri Oct 2 02:37:06 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04922; Fri, 2 Oct 92 02:37:06 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25532; Fri, 2 Oct 92 02:36:51 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25526; Fri, 2 Oct 92 02:36:49 -0700 Return-Path: Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA06806; Fri, 2 Oct 92 02:36:46 -0700 Date: Fri, 2 Oct 1992 02:35:11 -0700 (PDT) From: Mark Crispin Subject: re: Hostnames for hostless addresses To: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 1 Sep 1992 14:14:05 +0300 (IDT), Laurence Lundblade wrote: > I'm looking for a way to tell the c-client what address to use > when qualifying domainless addresses. Right now it use the result > of gethostbyname (the /etc/hosts, YP and DNS lookup). This > results in an address with a hostname in it, where it might be > better not to have one. Also, one can't always control what the > hostname is set too. I realize that it would be best to have the > addresses in the mail files fully qualified, but that isn't > possible in this case. > Could either an argument be added to mail_open, or a > mail_setdomain() call be added to set the domain name so the > calling program could control this? Then for example in Pine, > all the domain names would be consistent. The very latest c-client (not yet publicly released) makes this available via a global char* variable called lhostn which the main program can set. If it does not, c-client defaults it as before. From pinedev@shivax2.cac.washington.edu Thu Oct 22 20:42:09 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA13672; Thu, 22 Oct 92 20:42:09 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04976; Thu, 22 Oct 92 20:42:01 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04970; Thu, 22 Oct 92 20:41:58 -0700 Return-Path: Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA07863; Thu, 22 Oct 92 20:41:54 -0700 Date: Thu, 22 Oct 1992 20:40:20 -0700 (PDT) From: Mark Crispin Subject: c-client mailing list archives now available To: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII You can ftp it from ftp.cac.washington.edu on mail/c-client_archive This is a copy of the actual archive, updated daily at 1AM. From pinedev@shivax2.cac.washington.edu Mon Oct 26 21:40:45 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29123; Mon, 26 Oct 92 21:40:45 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA11938; Mon, 26 Oct 92 21:40:41 -0800 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA11926; Mon, 26 Oct 92 21:40:26 -0800 Return-Path: Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA12290; Mon, 26 Oct 92 22:40:17 -0700 Date: Mon, 26 Oct 1992 21:32:06 -0800 (PST) From: Mark Crispin Subject: bug discovered in UW imapd server To: c-client Interest List Cc: IMAP Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In the course of adding support for the IMAP2bis APPEND command to c-client, I discovered that the UW IMAP server didn't properly handle literals from the client to the server. Specifically, the `+' response to prompt for more output did not get transmitted until after the literal was transmitted. This bug did not show up in the current version of c-client. Client literals were only used for passwords in LOGIN and mailbox names in SELECT, and the complete command was sent in one chunk instead of waiting for the `+' response as the specification says. This was an expedient kludge to handle certain bizarre passwords and mailbox names until I implemented it right. Well, I implemented it right today. The bug is fixed in the 2.2 distribution of c-client, now available on ftp.cac.washington.edu as mail/imap.tar.Z (which is a link to imap-2.2.tar.Z). I urge developers to pick up this version as soon as possible, since there will be interoperability problems with support for the new APPEND command (as well as funny characters in passwords and mailbox names) until the older versions of imapd are exterminated. This new version also has the fix for certain base64 conversions outlined by Laurence Lundblade in his announcement to the Pine list, as well as the change to the IMAP client software to do client literals right. It would probably be prudent to hold off on using the new c-client/imap2.c in this new version until you have made sure that the new imapd is deployed. From pinedev@shivax2.cac.washington.edu Mon Oct 26 22:20:59 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29459; Mon, 26 Oct 92 22:20:59 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA11938; Mon, 26 Oct 92 21:40:41 -0800 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA11926; Mon, 26 Oct 92 21:40:26 -0800 Return-Path: Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA12290; Mon, 26 Oct 92 22:40:17 -0700 Date: Mon, 26 Oct 1992 21:32:06 -0800 (PST) From: Mark Crispin Subject: bug discovered in UW imapd server To: c-client Interest List Cc: IMAP Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In the course of adding support for the IMAP2bis APPEND command to c-client, I discovered that the UW IMAP server didn't properly handle literals from the client to the server. Specifically, the `+' response to prompt for more output did not get transmitted until after the literal was transmitted. This bug did not show up in the current version of c-client. Client literals were only used for passwords in LOGIN and mailbox names in SELECT, and the complete command was sent in one chunk instead of waiting for the `+' response as the specification says. This was an expedient kludge to handle certain bizarre passwords and mailbox names until I implemented it right. Well, I implemented it right today. The bug is fixed in the 2.2 distribution of c-client, now available on ftp.cac.washington.edu as mail/imap.tar.Z (which is a link to imap-2.2.tar.Z). I urge developers to pick up this version as soon as possible, since there will be interoperability problems with support for the new APPEND command (as well as funny characters in passwords and mailbox names) until the older versions of imapd are exterminated. This new version also has the fix for certain base64 conversions outlined by Laurence Lundblade in his announcement to the Pine list, as well as the change to the IMAP client software to do client literals right. It would probably be prudent to hold off on using the new c-client/imap2.c in this new version until you have made sure that the new imapd is deployed. From pinedev@shivax2.cac.washington.edu Tue Nov 3 01:21:05 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22042; Tue, 3 Nov 92 01:21:05 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA24080; Tue, 3 Nov 92 01:20:48 -0800 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from cc.nsysu.edu.tw by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA24067; Tue, 3 Nov 92 01:20:19 -0800 Received: by cc.nsysu.edu.tw (4.1/SysuNet-1.1-C.C) id ; Tue, 3 Nov 92 17:20:20 CST Date: Tue, 3 Nov 92 17:20:20 CST From: hsu@cc.nsysu.edu.tw (Hsu Li-Cheng) Message-Id: <9211030920.AA00413@cc.nsysu.edu.tw> To: c-client@cac.washington.edu Subject: addition From pinedev@shivax2.cac.washington.edu Fri Nov 13 11:22:37 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07172; Fri, 13 Nov 92 11:22:37 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA18141; Fri, 13 Nov 92 11:22:17 -0800 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from madhaus.utcs.utoronto.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA18133; Fri, 13 Nov 92 11:22:11 -0800 Received: from cathaus.utcs.utoronto.ca by madhaus.utcs.utoronto.ca (5.65/1.34) id AA04335; Fri, 13 Nov 92 14:22:09 -0500 Received: by cathaus.utcs.utoronto.ca (4.1/1.34) id AA05269; Fri, 13 Nov 92 14:21:50 EST Message-Id: <9211131921.AA05269@cathaus.utcs.utoronto.ca> To: imap-request@cac.washington.edu, c-client@cac.washington.edu Subject: please add Organization: UTCC Network & Operations Services, Network Development Phone: +1 416 978 6134 Date: Fri, 13 Nov 92 14:21:49 -0500 From: "Eric M. Carroll" Please add eric@utcs.utoronto.ca to the mailing lists. Thanks. Eric Carroll University of Toronto Computing & Communications Network & Operations Services, Network Development From pinedev@shivax2.cac.washington.edu Fri Dec 4 23:12:04 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA15151; Fri, 4 Dec 92 23:12:04 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23948; Fri, 4 Dec 92 23:11:49 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23936; Fri, 4 Dec 92 23:11:22 -0800 Return-Path: Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA06089; Fri, 4 Dec 92 23:11:13 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA11308; Fri, 4 Dec 92 23:11:05 -0800 Date: Fri, 4 Dec 1992 23:00:25 -0800 (PST) From: Mark Crispin Subject: Bugfix to the `Bogus entry in new cache list' crash To: dmandell@saintmarys.edu Cc: pine-info@cac.washington.edu, c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="16816888-2078917053-723539469:#10458" --16816888-2078917053-723539469:#10458 Content-Type: TEXT/PLAIN; charset=US-ASCII The MIME-attached difference file fixes a bug in c-client's berkeley mail driver (bezerk.c) which caused a crash with the message `Bogus entry in new cache list' when it encounted a mailbox that had empty messages such as in this example (I have inserted leading spaces to prevent possible confusion): From <@UICVM.UIC.EDU:WMST-L@UMDD.BITNET> Fri Dec 4 07:08 EST 1992 From <@UICVM.UIC.EDU:WMST-L@UMDD.BITNET> Fri Dec 4 07:23 EST 1992 From <@UICVM.UIC.EDU:WMST-L@UMDD.BITNET> Fri Dec 4 07:27 EST 1992 From <@pucc.PRINCETON.EDU:SBN@INDYCMS.BITNET> Fri Dec 4 07:30 EST 1992 From albr8047@jade.saintmarys.edu Fri Dec 4 09:58 EST 1992 When the mailbox is rewritten by c-client, two additional newlines will be inserted as well as a Status and X-Status line. Thanks to Dan Mandell for giving me excellent sample data which reproduced the problem. This problem was evidentally caused by a disk full condition on their HP-UX system, leading to appends to the mailbox of the `From ' headers but not the actual mail data. This fix is also in the latest mail/imap.tar.Z on ftp.cac.washington.edu. -- Mark -- --16816888-2078917053-723539469:#10458 Content-Type: APPLICATION/OCTET-DATA; NAME="bezerk.diff" Content-Transfer-Encoding: BASE64 Content-Description: attached file KioqIGJlemVyay5jLm9sZAlGcmkgRGVjICA0IDE2OjIyOjIwIDE5OTIKLS0t IGJlemVyay5jCUZyaSBEZWMgIDQgMjI6NTE6MTIgMTk5MgoqKioqKioqKioq KioqKioKKioqIDEyODEsMTI5MCAqKioqCiAgCWlmIChlKSBqID0gKGUgLSBz KSAtIDE7CS8qIGNhbGN1bGF0ZSBtZXNzYWdlIGxlbmd0aCAqLwogIAllbHNl IGogPSBzdHJsZW4gKHMpIC0gMTsvKiBvdGhlcndpc2UgaXMgcmVtYWluZGVy IG9mIGRhdGEgKi8KICAJaWYgKG0pIHsJCS8qIG5ldyBjYWNoZSBuZWVkZWQs IGhhdmUgcHJldmlvdXMgZGF0YT8gKi8KISAJICBuLT5oZWFkZXIgPSAoY2hh ciAqKSBmc19nZXQgKHNpemVvZiAoRklMRUNBQ0hFKSArIGopOwogIAkgIG4g PSAoRklMRUNBQ0hFICopIG4tPmhlYWRlcjsKICAJfQohIAllbHNlIG0gPSBu ID0gKEZJTEVDQUNIRSAqKSBmc19nZXQgKHNpemVvZiAoRklMRUNBQ0hFKSAr IGopOwogIAkJCQkvKiBjb3B5IG1lc3NhZ2UgZGF0YSAqLwogIAlzdHJuY3B5 IChuLT5pbnRlcm5hbCxzLGopOwogIAluLT5pbnRlcm5hbFtqXSA9ICdcMCc7 Ci0tLSAxMjgxLDEyOTAgLS0tLQogIAlpZiAoZSkgaiA9IChlIC0gcykgLSAx OwkvKiBjYWxjdWxhdGUgbWVzc2FnZSBsZW5ndGggKi8KICAJZWxzZSBqID0g c3RybGVuIChzKSAtIDE7Lyogb3RoZXJ3aXNlIGlzIHJlbWFpbmRlciBvZiBk YXRhICovCiAgCWlmIChtKSB7CQkvKiBuZXcgY2FjaGUgbmVlZGVkLCBoYXZl IHByZXZpb3VzIGRhdGE/ICovCiEgCSAgbi0+aGVhZGVyID0gKGNoYXIgKikg ZnNfZ2V0IChzaXplb2YgKEZJTEVDQUNIRSkgKyBqICsgMSk7CiAgCSAgbiA9 IChGSUxFQ0FDSEUgKikgbi0+aGVhZGVyOwogIAl9CiEgCWVsc2UgbSA9IG4g PSAoRklMRUNBQ0hFICopIGZzX2dldCAoc2l6ZW9mIChGSUxFQ0FDSEUpICsg aiArIDEpOwogIAkJCQkvKiBjb3B5IG1lc3NhZ2UgZGF0YSAqLwogIAlzdHJu Y3B5IChuLT5pbnRlcm5hbCxzLGopOwogIAluLT5pbnRlcm5hbFtqXSA9ICdc MCc7CioqKioqKioqKioqKioqKgoqKiogMTMyOCwxMzM0ICoqKioKICAgIGZv ciAoaSA9IHN0cmVhbS0+bm1zZ3MsIG4gPSBtOyBpIDwgbm1zZ3M7IGkrKykg ewogICAgICBMT0NBTC0+bXNnc1tpXSA9IG0gPSBuOwkvKiBzZXQgY2FjaGUs IGFuZCBuZXh0IGNhY2hlIHBvaW50ZXIgKi8KICAgICAgbiA9IChGSUxFQ0FD SEUgKikgbi0+aGVhZGVyOwohICAgICBpZiAoISgocyA9IG0tPmludGVybmFs KSAmJiBWQUxJRCkpIGZhdGFsICgiQm9ndXMgZW50cnkgaW4gbmV3IGNhY2hl IGxpc3QiKTsKICAgICAgbS0+aGVhZGVyID0gcyA9ICsrdDsJLyogcG9pbnRl ciB0byBtZXNzYWdlIGhlYWRlciAqLwogICAgICBtLT5oZWFkZXJzaXplIC09 IG0tPmhlYWRlciAtIG0tPmludGVybmFsOwogICAgICBtLT5ib2R5ID0gTklM OwkJLyogYXNzdW1lIG5vIGJvZHkgYXMgeWV0ICovCi0tLSAxMzI4LDEzNDAg LS0tLQogICAgZm9yIChpID0gc3RyZWFtLT5ubXNncywgbiA9IG07IGkgPCBu bXNnczsgaSsrKSB7CiAgICAgIExPQ0FMLT5tc2dzW2ldID0gbSA9IG47CS8q IHNldCBjYWNoZSwgYW5kIG5leHQgY2FjaGUgcG9pbnRlciAqLwogICAgICBu ID0gKEZJTEVDQUNIRSAqKSBuLT5oZWFkZXI7CiEgICAgIC8qIFRoaXMgaXMg YSBidWd0cmFwIGZvciBib2dvbnMgaW4gdGhlIG5ldyBtZXNzYWdlIGNhY2hl LCB3aGljaCBtYXkgaGFwcGVuCiEgICAgICAqIGlmIG1lbW9yeSBpcyBjb3Jy dXB0ZWQuICBOb3RlIHRoYXQgaW4gdGhlIGNhc2Ugb2YgYSB0b3RhbGx5IGVt cHR5CiEgICAgICAqIG1lc3NhZ2UsIGEgbmV3bGluZSBpcyBhcHBlbmRlZCBh bmQgY291bnRzIGFkanVzdGVkLgohICAgICAgKi8KISAgICAgaWYgKCghKChz ID0gbS0+aW50ZXJuYWwpICYmIFZBTElEKSkgJiYKISAJIShzICYmICFzdHJj aHIgKHMsJ1xuJykgJiYgc3RyY2F0IChzLCJcbiIpICYmIFZBTElEICYmCiEg CSAgbS0+aGVhZGVyc2l6ZSsrKSkgZmF0YWwgKCJCb2d1cyBlbnRyeSBpbiBu ZXcgY2FjaGUgbGlzdCIpOwogICAgICBtLT5oZWFkZXIgPSBzID0gKyt0Owkv KiBwb2ludGVyIHRvIG1lc3NhZ2UgaGVhZGVyICovCiAgICAgIG0tPmhlYWRl cnNpemUgLT0gbS0+aGVhZGVyIC0gbS0+aW50ZXJuYWw7CiAgICAgIG0tPmJv ZHkgPSBOSUw7CQkvKiBhc3N1bWUgbm8gYm9keSBhcyB5ZXQgKi8K --16816888-2078917053-723539469:#10458-- From pinedev@shivax2.cac.washington.edu Fri Dec 11 15:00:15 1992 -0700 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA18313; Fri, 11 Dec 92 15:00:15 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04670; Fri, 11 Dec 92 15:00:43 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04650; Fri, 11 Dec 92 15:00:07 -0800 Return-Path: Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA01803; Fri, 11 Dec 92 14:59:11 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA04157; Fri, 11 Dec 92 14:59:05 -0800 Date: Fri, 11 Dec 1992 14:47:59 -0800 (PST) From: Mark Crispin Subject: MIME-Version after Content-Type bug in Pine To: pine-info@cac.washington.edu Cc: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thanks to data provided to me by Mike Seibel that demonstrated the bug, I was able to find a bug in the header parsing code in c-client and fix it. This fixes the problem that the fellow in Finland reported. I have just updated the mail/imap.tar.Z c-client distribution on ftp.cac.washington.edu to incorporate this bugfix. Problem: Messages in which the MIME-Version: header occurs as the line immediately after the Content-Type: header are not recognized and parsed as MIME. If the MIME-Version: header occurs later in the header, everything works. Diagnosis: The code to scan the remainder of the header for the string `MIME-Version' prefixes the search string with a newline to make sure it only sees ones that start a line. Unfortunately, it starts the search at the first character of the next line, instead of at the newline that terminates the current header line. Solution: Begin the search a character earlier. In routine rfc822_parse_msg() in rfc822.c, there is the following code: case 'C': /* possible cc: or Content-*/ if (!strcmp (tmp+1,"C")) rfc822_parse_adrlist (&env->cc,d,host); else if ((tmp[1] == 'O') && (tmp[2] == 'N') && (tmp[3] == 'T') && (tmp[4] == 'E') && (tmp[5] == 'N') && (tmp[6] == 'T') && (tmp[7] == '-') && body && (MIMEp || (search (s-1,i,"\012MIME-Version",(long) 13)))) rfc822_parse_content_header (body,tmp+8,d); break; Note the ``s-1'' in the call to search(). Version with the bug have ``s'' instead. Change the ``s'' to ``s-1'' and rebuild. From pinedev@shivax2.cac.washington.edu Tue Jan 19 13:08:21 1993 -0700 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA09430; Tue, 19 Jan 93 13:08:21 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26902; Tue, 19 Jan 93 13:08:00 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from Delphi.CS.UCLA.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26896; Tue, 19 Jan 93 13:07:58 -0800 Received: from twinsun.UUCP by delphi.cs.ucla.edu (Sendmail 5.61d+YP/3.21ns) id AA21164; Tue, 19 Jan 93 13:07:56 -0800 Received: from set.twinsun.com by twinsun.com (4.1/SMI-4.1) id AA14519; Tue, 19 Jan 93 13:03:13 PST Received: by set.twinsun.com (4.1/SMI-4.1) id AA15829; Tue, 19 Jan 93 13:03:11 PST Date: Tue, 19 Jan 93 13:03:11 PST From: makr@twinsun.com (Makr Keasling) Message-Id: <9301192103.AA15829@set.twinsun.com> To: c-client@cac.washington.edu Subject: EINTR received during connect when opening a remote folder. Cc: mrc@cac.washington.edu Here is the error message: !! Can't connect to set,143: Interrupted system call my fix is to: MAILSTREAM *my_mail_open (MAILSTREAM *stream, char *mailbox) { int mask = sigblock (sigmask (SIGCHLD)); stream = mail_open (stream, mailbox, 0); sigsetmask (mask); return stream; } I need to receive SIGCHLD's because I am running processes in the "background" and need to know when they are finished. The SIGCHLD that is received is from the process that gets forked when trying to connect via /etc/rimapd. The problem occurs when network latency is high. I would like to know if there is a better, more portable solution to this problem. Mark Keasling makr@twinsun.com From pinedev@shivax2.cac.washington.edu Wed Jan 20 22:47:35 1993 -0700 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25164; Wed, 20 Jan 93 22:47:35 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA11406; Wed, 20 Jan 93 22:47:28 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA11400; Wed, 20 Jan 93 22:47:27 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA06676; Wed, 20 Jan 93 22:47:20 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA00461; Wed, 20 Jan 93 22:47:11 -0800 Date: Wed, 20 Jan 1993 22:35:58 -0800 (PST) From: Mark Crispin Subject: re: EINTR received during connect when opening a remote folder. To: Makr Keasling Cc: c-client Interest List In-Reply-To: <9301192103.AA15829@set.twinsun.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 19 Jan 93 13:03:11 PST, Makr Keasling wrote: > I need to receive SIGCHLD's because I am running processes in the > "background" > and need to know when they are finished. The SIGCHLD that is received is > from the process that gets forked when trying to connect via /etc/rimapd. > The problem occurs when network latency is high. > > I would like to know if there is a better, more portable solution to this > problem. You probably have to defer any signal which may adversely impact TCP every time you call c-client. I'm sure SIGCHLD isn't the only one; nor is TCP open the only thing that can be adversely impacted by a signal at the wrong time. This is a deficiency in the Unix kernel. Ideally, a signal should just call the signal handler and let you resume the TCP system call (perhaps by backing out into user mode so redoing the system call resumes the operation). Very few operating systems do this right; ITS (R.I.P.) is the only one I know of that did. ;-( One possible way of dealing with the problem is by having the c-client part of your application run in a separate child, so it would never get SIGCHLDs. I don't know how badly this may tangle your application though. -- Mark -- From pinedev@shivax2.cac.washington.edu Mon Feb 15 20:54:32 1993 -0700 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA05294; Mon, 15 Feb 93 20:54:32 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA06079; Mon, 15 Feb 93 20:54:12 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA06073; Mon, 15 Feb 93 20:54:11 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA08521; Mon, 15 Feb 93 20:54:06 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA00743; Mon, 15 Feb 93 20:54:01 -0800 Date: Mon, 15 Feb 1993 20:23:15 -0800 (PST) From: Mark Crispin Subject: c-client 2.3 frozen; 2.4 started To: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Version 2.3 of the IMAP toolkit has been frozen. It has, as of this writing, no known bugs. Besides bugfixes from 2.2 (frozen last October 26), 2.3 has the following major features: . Implementation of the new mailbox naming rules in imap/Naming.TXT. Note that these have tripped up a few people; so please read this document carefully. . Subscription management for mailboxes and bboards is now implemented. . The ``ms'' demo client supports the mailbox management features (create, delete, rename, subscribe, unsubscribe). . The IMAP server now supports PARTIAL fetching, and has a dummy for PURGE, making it fully IMAP2bis compliant. . Berkeley parser now handles 10 different formats of ``From '' line. . NNTP client implemented for Unix and for DOS. The mailbox syntax is *[host]newsgroup . SUN-OS port has its own version of strstr(), since the one provided by SUN is buggy and extremely slow. A full list is in imap/Updates.DOC. - - - - - The first version of 2.4 is now available; note that this is NOT a stable or final version of 2.4!! 2.4 begins with an implementation of Kiss Of Death for Berkeley/mbox mailbox streams. If a process attempts to open a Berkeley mailbox that is already open and locked read/write by another process, it will send a SIGUSR2 signal as a ``kiss of death'' to the process which has it open. If the other process releases the mailbox within 15 seconds, the process sending the KOD will take over the read/write lock. This is intended to help the annoying ``mailbox already open by another process, access is read-only'' condition when the other process is an abandoned or lost imapd or Pine. The action taken upon receipt of a KOD depends upon the main program. At this writing (8:40PM on February 16) only imapd has a KOD handler. If it has been more than 2 minutes since the last IMAP operation, imapd will relenquish the read/write lock and go read-only on the stream. imapd will continue to run until its autologout timer (currently 30 minutes from the time of the last IMAP operation) expires. I'm not sure precisely what sort of action Pine will take when it gets a KOD, but I'm sure the Pine UA folks will do something neat now that they're no longer waiting on me. It is also now possible in 2.4 to change a read/write stream into a readonly stream. If anyone using c-client is currently using SIGUSR2 for some other purpose, please get in touch with me right away while there's still the opportunity to go with some other mechanism. Other items likely to go into subsequent edits of 2.4: . Disconnected operation extensions to IMAP2bis (more on this to come on the IMAP list) . Possible conversion of the tenex driver to not use much memory at all (at the expense of possible slower searches). . Possible mechanism to import a Berkeley mbox folder to DOS. . Support for smail-style `` remote from node'' suffix in mbox folders. . Possible support for the new SVR4 ``Content-Length'' header (this may be a problem since it could slow down Berkeley mbox parsing for everyone else). . Possible MMDF folder support. -- Mark -- From pinedev@shivax2.cac.washington.edu Mon Feb 15 21:25:30 1993 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA05612; Mon, 15 Feb 93 21:25:30 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA15594; Mon, 15 Feb 93 21:25:24 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA15588; Mon, 15 Feb 93 21:25:23 -0800 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21117; Mon, 15 Feb 93 21:25:22 -0800 Date: Mon, 15 Feb 1993 21:20:04 -0800 (PST) From: Terry Gray Subject: Re: c-client 2.3 frozen; 2.4 started To: Mark Crispin Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Just a small caveat for all interested parties: the mailbox naming rules and syntax decisions (e.g. [host]) should be considered work in progress, and may well change. Hopefully these issues will get nailed down in the next two weeks. -teg On Mon, 15 Feb 1993, Mark Crispin wrote: > Version 2.3 of the IMAP toolkit has been frozen. It has, as of this writing, > no known bugs. Besides bugfixes from 2.2 (frozen last October 26), 2.3 has > the following major features: > . Implementation of the new mailbox naming rules in imap/Naming.TXT. Note > that these have tripped up a few people; so please read this document > carefully. > . Subscription management for mailboxes and bboards is now implemented. > . The ``ms'' demo client supports the mailbox management features (create, > delete, rename, subscribe, unsubscribe). > . The IMAP server now supports PARTIAL fetching, and has a dummy for PURGE, > making it fully IMAP2bis compliant. > . Berkeley parser now handles 10 different formats of ``From '' line. > . NNTP client implemented for Unix and for DOS. The mailbox syntax is > *[host]newsgroup > . SUN-OS port has its own version of strstr(), since the one provided by SUN > is buggy and extremely slow. > > A full list is in imap/Updates.DOC. > > - - - - - > > The first version of 2.4 is now available; note that this is NOT a stable or > final version of 2.4!! > > 2.4 begins with an implementation of Kiss Of Death for Berkeley/mbox mailbox > streams. If a process attempts to open a Berkeley mailbox that is already > open and locked read/write by another process, it will send a SIGUSR2 signal > as a ``kiss of death'' to the process which has it open. If the other process > releases the mailbox within 15 seconds, the process sending the KOD will take > over the read/write lock. This is intended to help the annoying ``mailbox > already open by another process, access is read-only'' condition when the > other process is an abandoned or lost imapd or Pine. > > The action taken upon receipt of a KOD depends upon the main program. At this > writing (8:40PM on February 16) only imapd has a KOD handler. If it has been > more than 2 minutes since the last IMAP operation, imapd will relenquish the > read/write lock and go read-only on the stream. imapd will continue to run > until its autologout timer (currently 30 minutes from the time of the last > IMAP operation) expires. > > I'm not sure precisely what sort of action Pine will take when it gets a KOD, > but I'm sure the Pine UA folks will do something neat now that they're no > longer waiting on me. > > It is also now possible in 2.4 to change a read/write stream into a readonly > stream. > > If anyone using c-client is currently using SIGUSR2 for some other purpose, > please get in touch with me right away while there's still the opportunity to > go with some other mechanism. > > Other items likely to go into subsequent edits of 2.4: > . Disconnected operation extensions to IMAP2bis (more on this to come on the > IMAP list) > . Possible conversion of the tenex driver to not use much memory at all (at > the expense of possible slower searches). > . Possible mechanism to import a Berkeley mbox folder to DOS. > . Support for smail-style `` remote from node'' suffix in mbox folders. > . Possible support for the new SVR4 ``Content-Length'' header (this may be a > problem since it could slow down Berkeley mbox parsing for everyone else). > . Possible MMDF folder support. > > -- Mark -- > From pinedev@shivax2.cac.washington.edu Tue Feb 16 19:48:13 1993 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02226; Tue, 16 Feb 93 19:48:13 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07354; Tue, 16 Feb 93 19:47:57 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07303; Tue, 16 Feb 93 19:47:50 -0800 Received: by po2.andrew.cmu.edu (5.54/3.15) id for c-client@cac.washington.edu; Tue, 16 Feb 93 22:47:44 EST Received: via switchmail; Tue, 16 Feb 1993 22:47:43 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 16 Feb 1993 22:45:50 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 16 Feb 1993 22:45:40 -0500 (EST) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Tue, 16 Feb 1993 22:45:34 -0500 (EST) Message-Id: Date: Tue, 16 Feb 1993 22:45:34 -0500 (EST) From: John Gardiner Myers To: c-client@cac.washington.edu Subject: Naming rules w.r.t. ambiguous names Beak: is Not I disagree with the following rule in Naming.txt: "c-client will look for ambiguous names ONLY in the same technology as the INBOX mailbox." C-client should look for ambiguous names in all technologies. Each technology must have the ability to determine whether or not it has an object of that name. When two or more technologies have an object with the same name it is an implementation issue to determine which has precedence. It is reasonable to state the rule that ambiguous names will only be CREATED in the same technology as the INBOX mailbox. _.John From pinedev@shivax2.cac.washington.edu Tue Feb 16 20:06:45 1993 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02507; Tue, 16 Feb 93 20:06:45 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22046; Tue, 16 Feb 93 20:06:29 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22002; Tue, 16 Feb 93 20:06:24 -0800 Received: by andrew.cmu.edu (5.54/3.15) id for c-client@cac.washington.edu; Tue, 16 Feb 93 23:06:19 EST Received: via switchmail; Tue, 16 Feb 1993 23:06:19 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 16 Feb 1993 23:05:51 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 16 Feb 1993 23:05:47 -0500 (EST) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Tue, 16 Feb 1993 23:05:43 -0500 (EST) Message-Id: Date: Tue, 16 Feb 1993 23:05:43 -0500 (EST) From: John Gardiner Myers To: c-client@cac.washington.edu Subject: Subscription management and ambiguous names Beak: is Not When subscribing to an ambiguous name, the bezerk driver in c-client 2.3 converts it into an unambiguous name before adding it to the subscription database. Also, bezerk_find_all() given an ambiguous pattern will return unambiguous names. In my opinion, this is incorrect. In many cases, it will cause imapd to behave contrary to the protocol spec. It also exposes implementation information that should remain hidden from the user. For example, I gave imapd a "tag subscribe INBOX" command and a subsequent "tag find mailboxes *" command returned "* MAILBOX /usr/spool/mail/jm36". A "tag find all.mailboxes *" command gave information as to where the user's mailboxes were stored on the imap server. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From pinedev@shivax2.cac.washington.edu Tue Feb 16 22:46:43 1993 -0700 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04427; Tue, 16 Feb 93 22:46:43 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA15792; Tue, 16 Feb 93 22:46:30 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA15786; Tue, 16 Feb 93 22:46:29 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA01788; Tue, 16 Feb 93 22:46:24 -0800 Date: Tue, 16 Feb 1993 20:24:25 -0800 (PST) From: Mark Crispin Subject: re: Subscription management and ambiguous names To: John Gardiner Myers Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII John (& the c-client list) - The idea was to have a constant frame of reference. Home-directory relative unambiguous names are supposed to be of the form ~/name, not something like /u1/users/jm36 which is subject to change. The recording of the special name INBOX as an absolute /usr/spool/mail pathname is probably a bug though. It is certainly not intended. Anyway, this stuff is still under development, so expect to see more changes in 2.4. -- Mark -- From pinedev@shivax2.cac.washington.edu Wed Feb 17 06:47:42 1993 -0700 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA11145; Wed, 17 Feb 93 06:47:42 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA17913; Wed, 17 Feb 93 06:47:35 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from csgrad.cs.vt.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA17907; Wed, 17 Feb 93 06:47:33 -0800 Received: by csgrad.cs.vt.edu (5.65/DEC-Ultrix/4.3) id AA07739; Wed, 17 Feb 1993 09:47:28 -0500 Date: Wed, 17 Feb 1993 09:46:58 -0500 (EST) From: Laurence Lundblade Subject: Re: Subscription management and ambiguous names To: John Gardiner Myers Cc: c-client@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Here here! I agree, but Mark and company already know that all to well. LL On Tue, 16 Feb 1993, John Gardiner Myers wrote: > When subscribing to an ambiguous name, the bezerk driver in c-client > 2.3 converts it into an unambiguous name before adding it to the > subscription database. Also, bezerk_find_all() given an ambiguous > pattern will return unambiguous names. > > In my opinion, this is incorrect. In many cases, it will cause imapd > to behave contrary to the protocol spec. It also exposes > implementation information that should remain hidden from the user. > For example, I gave imapd a "tag subscribe INBOX" command and a > subsequent "tag find mailboxes *" command returned > "* MAILBOX /usr/spool/mail/jm36". A "tag find all.mailboxes *" > command gave information as to where the user's mailboxes were stored > on the imap server. > > -- > _.John G. Myers Internet: jgm+@CMU.EDU > LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up > > From pinedev@shivax2.cac.washington.edu Thu Feb 18 05:01:25 1993 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA08404; Thu, 18 Feb 93 05:01:25 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29268; Thu, 18 Feb 93 05:01:09 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from csgrad.cs.vt.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29262; Thu, 18 Feb 93 05:01:06 -0800 Received: by csgrad.cs.vt.edu (5.65/DEC-Ultrix/4.3) id AA29111; Thu, 18 Feb 1993 08:01:02 -0500 Date: Thu, 18 Feb 1993 07:55:19 -0500 (EST) From: Laurence Lundblade Reply-To: Laurence Lundblade Subject: Re: Naming rules w.r.t. ambiguous names To: John Gardiner Myers Cc: c-client@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I agree with John here, as long as the ambiguous names across all technologies are not required to be unique, as I believe is the current implementation is. I also agree that Pine 3.05 knows too much about technology formats. It's probably in the worst state possible now as the process of moving all that stuff into the c-client is not complete. Some is in the c-client, but there's a huge amount of code in Pine. The work hasn't progresses because we've found the naming scheme and semantics of some routines in the c-client lacking. For example mail_find() always returns FQ (fully qualified -- unambiguous) names, it is not really appropriate to present such names to the use, and it's not possible to undo the FQ without knowledge of the OS of the server. The basic name of a folder includes: technology, path, ambiguous name, and host. The basic problem is how to put these all together. At the moment I've got a ton of beginning Pascal progams to grade and home work due, so I won't say more for a day or two, but have more thoughts. LL On Tue, 16 Feb 1993, John Gardiner Myers wrote: > I disagree with the following rule in Naming.txt: > > "c-client will look for ambiguous names ONLY in the same technology as > the INBOX mailbox." > > C-client should look for ambiguous names in all technologies. Each > technology must have the ability to determine whether or not it has an > object of that name. When two or more technologies have an object > with the same name it is an implementation issue to determine which > has precedence. > > It is reasonable to state the rule that ambiguous names will only be > CREATED in the same technology as the INBOX mailbox. > > _.John From pinedev@shivax2.cac.washington.edu Tue Mar 2 05:16:53 1993 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA17229; Tue, 2 Mar 93 05:16:53 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26624; Tue, 2 Mar 93 05:16:42 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from genesis.iti.gov.sg by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26618; Tue, 2 Mar 93 05:16:37 -0800 Received: from pollux.iti.gov.sg by iti.gov.sg (4.1/SMI-4.1) id AA13483; Tue, 2 Mar 93 21:18:42 SST Date: Tue, 2 Mar 93 21:18:42 SST From: jinho@iti.gov.sg (Tan Jin Ho) Message-Id: <9303021318.AA13483@iti.gov.sg> To: c-client@CAC.Washington.edu Subject: c-clients for Windows Hi, Is there anyone who is working on a Windows c-client library (or have already done so) ? I tried compiling c-client with win wattcp but failed (it compiles fine but mtest crashed). Thanks, Jin-Ho From pinedev@shivax2.cac.washington.edu Tue Mar 2 10:58:18 1993 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA24164; Tue, 2 Mar 93 10:58:18 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29120; Tue, 2 Mar 93 10:58:12 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29114; Tue, 2 Mar 93 10:57:58 -0800 Received: from isagate by scapa.cs.ualberta.ca with UUCP id <42134>; Tue, 2 Mar 1993 11:57:12 -0700 Received: by isagate.edm.isac.ca (/\==/\ Smail3.1.20.1 #20.1) id ; Tue, 2 Mar 93 11:52 MST Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.26.7 #1) id m0nTc9Q-000cv9C; Tue, 2 Mar 93 11:57 MST Date: Tue, 2 Mar 1993 11:55:02 -0700 From: Steve Hole Subject: Re: c-clients for Windows To: Tan Jin Ho Cc: c-client@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 2 Mar 1993 12:18:42 -0700 Tan Jin Ho wrote: > From: Tan Jin Ho > Date: Tue, 2 Mar 1993 12:18:42 -0700 > Subject: c-clients for Windows > To: c-client@cac.washington.edu > > > Hi, > Is there anyone who is working on a Windows c-client library (or have > already done so) ? I tried compiling c-client with win wattcp but > failed (it compiles fine but mtest crashed). > We have been using the c-client inside windows for about 6 months now as the basis for ECSMail. It works fine. The problem would have to be in the win wattcp stack. We have noticed other problems with this stack, but haven't gotten around to correcting them. I believe that we will try to do so sometime this month. Cheers. -- Steve Hole Director of Research and Communications ISA Corporation mail: steve@edm.isac.ca Suite 835, 10040 - 104 St. phone: (403) 420-8081 Edmonton, Alberta, Canada fax: (403) 420-8037 T5J 0Z2 From pinedev@shivax2.cac.washington.edu Tue Mar 2 11:10:49 1993 -0700 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA24599; Tue, 2 Mar 93 11:10:49 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29796; Tue, 2 Mar 93 11:10:40 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29790; Tue, 2 Mar 93 11:10:39 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA03071; Tue, 2 Mar 93 11:10:21 -0800 Date: Tue, 2 Mar 1993 11:04:52 -0800 (PST) From: Mark Crispin Subject: re: c-clients for Windows To: Tan Jin Ho Cc: c-client Interest List In-Reply-To: <9303021318.AA13483@iti.gov.sg> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Is there anyone who is working on a Windows c-client library (or have > already done so) ? I tried compiling c-client with win wattcp but > failed (it compiles fine but mtest crashed). Hi - I am concerned about all reports of c-client crashes, and I will happily debug the problem if you give me enough information. Telling me that mtest crashed is inadequate. Preferably, I need to be able to reproduce the problem, or at least have an idea of what is going on. Can you tell me exactly what you did to cause the c-client crash? Is there any reason to believe that a particular piece of e-mail data may be associated with the crash? Thanks, -- Mark -- From pinedev@shivax2.cac.washington.edu Fri Mar 19 01:19:35 1993 -0700 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA14283; Fri, 19 Mar 93 01:19:35 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25494; Fri, 19 Mar 93 01:19:21 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25488; Fri, 19 Mar 93 01:19:20 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA00505; Fri, 19 Mar 93 01:19:18 -0800 Date: Fri, 19 Mar 1993 00:51:30 -0800 (PST) From: Mark Crispin Subject: change coming to address lists To: IMAP Interest List Cc: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A change is forthcoming to address lists in IMAP, and the corresponding structures in c-client, to provide a more useful representation of the envelope data for Pine. This change is largely upwards-compatible, but it may trip up some unprepared software. My ms and MailManager applications were. Because of its possible consequences, these changes will not appear until version 3.0 of the IMAP toolkit, so 2.4 is frozen as it stands now. I don't plan on releasing 3.0 of the IMAP toolkit until after the next release of Pine is released. The change makes it possible for an address structure to have a NIL host name and mailbox name. This is being used to support group syntax. An address structure with a non-NIL mailbox name but a NIL host name indicates the start of a group; one with both NIL indicates the end of a group. For example, the address list: To: Friends: Bob@FOO, Lisa@Bar;, Romans: Julius@CAESAR;, Joe@GARP will now be structured in IMAP as: ((NIL NIL Friends NIL) (NIL NIL Bob FOO) (NIL NIL Lisa Bar) (NIL NIL NIL NIL) (NIL NIL Romans NIL) (NIL NIL Julius CAESAR) (NIL NIL NIL NIL) (NIL NIL Joe GARP)) Previously, it was: ((NIL NIL Bob FOO) (NIL NIL Lisa Bar) (NIL NIL Julius CAESAR) (NIL NIL Joe GARP)) that is, the group information was ignored. More changes of this sort are likely in the near future to introduce netnews newsgroups. c-client software which religiously use c-client's routines will upgrade automatically on a relink. [ms and MailManager didn't, but they do now!] Implementors of c-client based software should look for cases where their program outputs data from an ADDRESS structure (as opposed to calling the routines in c-client). IMAP implementors should look for cases where they assume the mailbox or host name are non-NIL. -- Mark -- From pinedev@shivax2.cac.washington.edu Tue Mar 23 13:05:22 1993 -0700 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11702; Tue, 23 Mar 93 13:05:22 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23594; Tue, 23 Mar 93 13:05:03 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23588; Tue, 23 Mar 93 13:05:01 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA06465; Tue, 23 Mar 93 13:05:00 -0800 Date: Tue, 23 Mar 1993 11:33:56 -0800 (PST) From: Mark Crispin Subject: c-client network mailbox syntax To: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In the present c-client, network mailboxes are accessed with the following syntax for their names: {host}mailbox mailbox on host using IMAP {host:port}mailbox mailbox on host using IMAP on this port instead of 143 *{host}bboard bboard on host using IMAP *{host:port}mailbox bboard on host using IMAP on this port instead of 143 [host]mailbox mailbox on host using POP (future) *[host]bboard bboard on host using NNTP The notion is that {} refers to IMAP whereas [] refers to the older protocols. It has been proposed that the last two become instead: {host/POP2}mailbox *{host/NNTP}bboard That is, that slash followed by a service name identify an alternative service instead of IMAP. The default would, of course, be IMAP. Advantages: . possible elimination of confusion over the meaning of [] vs {}. It's felt that if users encounter this they would be seriously confused. . possible future extensibility. . fewer special characters in mailbox names. . simpler top-level rules, at the cost of more complex rules for {}. Disadvantages: . *{host/NNTP}bboard is arguably as mystical to users as *[host]bboard. . silly concepts such as *{host/POP}mailbox or {host/NNTP}bboard would exist, whereas they don't exist now. . extensibility arguments assume that anything we plan now would be at all suitable for a future mechanism. . it is necessary to state a protocol name, whereas before the protocol was inferred from the syntax. . more work for name parsers; they can't just grab things starting with { or [ any more. There has been a long, drawn out argument on this that finally ended with a general recognition that either one was arguably ``cleaner and better'' than the other. There is no clear technical superiority of one over the other; also, it can be reasonably argued that it is an implementation detail that can be hidden from users no matter what syntax is used. I'll state flat out: I like the current scheme. It's nice and tight with no loose ends, and it doesn't create silly cases (those of you will remember from the MIME WG that I *hate* silly states). But if the majority favors a change to the proposed format, I'll go along. So, if you have any feelings either way (or even if you don't particularly care), please share them. We do need to commit one way or another soon. -- Mark -- From pinedev@shivax2.cac.washington.edu Tue Mar 23 13:33:35 1993 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12719; Tue, 23 Mar 93 13:33:35 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19566; Tue, 23 Mar 93 13:33:17 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19560; Tue, 23 Mar 93 13:33:16 -0800 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA13632; Tue, 23 Mar 93 13:33:14 -0800 Date: Tue, 23 Mar 1993 13:25:12 -0800 (PST) From: Terry Gray Subject: Re: c-client network mailbox syntax To: Mark Crispin Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > There has been a long, drawn out argument on this that finally ended with > a general recognition that either one was arguably ``cleaner and better'' > than the other. Gosh Mark, my recollection was that there was only one person in the room who thought using { } and [] (with/without * ) was "cleaner and better"! :) > There is no clear technical superiority of one over the > other; also, it can be reasonably argued that it is an implementation > detail that can be hidden from users no matter what syntax is used. As John Meyers once pointed out, internal syntax has a nasty habit of creeping out and becoming user-visible! -teg From pinedev@shivax2.cac.washington.edu Tue Mar 23 14:29:24 1993 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14239; Tue, 23 Mar 93 14:29:24 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA20485; Tue, 23 Mar 93 14:29:15 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from SUMEX-AIM.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA20479; Tue, 23 Mar 93 14:29:11 -0800 Received: from jouez.stanford.EDU (ssrg-ds5000-1.Stanford.EDU) by SUMEX-AIM.Stanford.EDU (4.1/inc-1.0) id AA24682; Tue, 23 Mar 93 14:29:09 PST Received: by jouez.stanford.EDU (5.57/Ultrix4.0-(Rev. 174)) id AA12790; Tue, 23 Mar 93 14:28:13 -0800 Date: Tue, 23 Mar 1993 14:26:26 -0800 (PST) From: Bill Yeager Reply-To: Bill_Yeager@camis.stanford.edu Subject: RE: c-client network mailbox syntax To: Mark Crispin Cc: c-client Interest List In-Reply-To: Mark Crispin's message of Tue, 23 Mar 1993 11:33:56 -0800 (PST): Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII >I'll state flat out: I like the current scheme I too think the current scheme is sufficient. Bill From pinedev@shivax2.cac.washington.edu Tue Mar 23 14:50:53 1993 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15142; Tue, 23 Mar 93 14:50:53 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA20972; Tue, 23 Mar 93 14:50:45 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from eco.twg.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA20966; Tue, 23 Mar 93 14:50:38 -0800 Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA04497; Tue, 23 Mar 93 17:50:42 -0500 Message-Id: <9303232250.AA04497@eco.twg.com> Received: from apache.twg.com by apache.twg.com id <25822-0@apache.twg.com>; Tue, 23 Mar 1993 14:50:14 -0800 From: "David Herron" Subject: Re: c-client network mailbox syntax To: Mark Crispin Cc: c-client Interest List Date: Tue, 23 Mar 93 14:50:12 PST In-Reply-To: Your message of Tue, 23 Mar 1993 11:33:56 -0800 (PST). Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 26 TEXT , 4 TEXT IMO, using `*' to distinguish a `bboard' is pretty silly. So why not unify on something like {host/access-method}mailbox-idenifier-string Or {server/bboard}sf-lovers or {server/nntp}rec.arts.sf This means that a mailbox-access-method would provide a `type name' along with the function pointers. The users shouldn't be seeing these strings anyway. Even {host}mailbox is pretty ugly. The software should be encapsulating representation details like this and providing them a way to specify "host" and "mailbox-name" and it takes care of munging up the right strings. . it is necessary to state a protocol name, whereas before the protocol was inferred from the syntax. To me specifying the protocol by syntax is a big disadvantage to the current encoding. It greatly limits the number of available protocols because for every one you have to invent a new leading character. With the proposal above there is one syntax which you parse to find the appropriate server code. <- David Herron (work) (home) <- <- "That's our advantage at Microsoft; we set the standards and we can change them." <- Karen Hargrove of Microsoft quoted in the Feb 1993 Unix Review editorial. From pinedev@shivax2.cac.washington.edu Thu Mar 25 19:07:53 1993 -0700 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27540; Thu, 25 Mar 93 19:07:53 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07957; Thu, 25 Mar 93 19:07:39 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from Delphi.CS.UCLA.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07951; Thu, 25 Mar 93 19:07:37 -0800 Received: from twinsun.UUCP by delphi.cs.ucla.edu (Sendmail 5.61d+YP/3.21ns) id AA21127; Thu, 25 Mar 93 19:07:35 -0800 Received: from sirius by twinsun.com (4.1/SMI-4.1) id AA16243; Thu, 25 Mar 93 18:50:05 PST Message-Id: <9303260250.AA16243@twinsun.com> Date: Thu, 25 Mar 1993 18:44:38 EST From: Ram Krishnan Subject: Please add me to this mailing list To: imap@cac.washington.edu, c-client@cac.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Description: Please add me to this mailing list. Ram ====================================================================== Reporter (to Mahatma Gandhi): Mr Gandhi, what do you think of Western Civilization? Gandhi: I think it would be a good idea. From pinedev@shivax2.cac.washington.edu Sun Mar 28 22:06:16 1993 -0700 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00114; Sun, 28 Mar 93 22:06:16 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22855; Sun, 28 Mar 93 22:06:03 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22849; Sun, 28 Mar 93 22:06:01 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA13416; Sun, 28 Mar 93 22:06:00 -0800 Date: Sun, 28 Mar 1993 21:43:01 -0800 (PST) From: Mark Crispin Subject: remote mailbox naming syntax for c-client To: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The next version of c-client will support a new naming syntax for NNTP access, as a result of action to standardize the format of all remote mailbox names to be (in BNF form): ["*"] "{" host [":" port] ["/" access "}" [mailbox] where: "*" indicator to use bboard access host remote IP host to connect port TCP port number to use (defaults to service's normal port) access access mechanism, imap2 or nntp (defaults to imap2) mailbox defaults to INBOX for mail, general for bboard The syntax *[host]newsgroup for NNTP access is hereby declared dead. All of the people who supported that syntax indicated that it wouldn't be a show stopper for them if it changed, whereas those who advocated the change had quite strong feelings on the matter. -- Mark -- From pinedev@shivax2.cac.washington.edu Sun Mar 28 22:19:01 1993 -0700 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00251; Sun, 28 Mar 93 22:19:01 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22917; Sun, 28 Mar 93 22:18:56 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22911; Sun, 28 Mar 93 22:18:55 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA13431; Sun, 28 Mar 93 22:18:53 -0800 Date: Sun, 28 Mar 1993 22:09:28 -0800 (PST) From: Mark Crispin Subject: new memory-miser tenex driver To: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The next version of the c-client distribution will come with tenex2, a new memory-miser version of the tenex driver, as the default driver for the mail.txt format. It does not read the entire mailbox into memory, and thus uses what can be significantly less memory than the original tenex driver. For systems on which virtual memory/swap space is at a premium, this could result in swap space savings and resultant performance improvement. Users who have particularly large mailboxes may wish to consider using the mail.txt format once the tenex2 driver is installed in their mailer, since it may result in significant real time speedups and a reduction of system overhead. This is done at the possible cost of extra disk traffic and slower global free text searches. On a system with adequate memory for buffer cache, the overhead compared to the original driver may be merely a matter of some extra system call and context-switching overhead. For the nonce, the original mail.txt format driver will still be available as tenex.c/h, but the makefiles will only build the tenex2.c/h version. If the tenex2 driver turns out to be a winner, the original driver may be allowed to succumb to software rot, so please let me know if the original driver is still needed in your environment. From pinedev@shivax2.cac.washington.edu Sun Apr 18 19:36:58 1993 -0700 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20519; Sun, 18 Apr 93 19:36:58 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14715; Sun, 18 Apr 93 19:36:48 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14709; Sun, 18 Apr 93 19:36:46 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA00452; Sun, 18 Apr 93 19:36:45 -0700 Date: Sun, 18 Apr 1993 19:18:29 -0700 (PDT) From: Mark Crispin Subject: proposed IMAP protocol enhancement To: IMAP Interest List Cc: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I, perhaps more than anyone else, want to put a lid on further IMAP additions in the name of stability and getting a Proposed Standard out of this. However, something has come out that has survived even my harsh filters, and I'm throwing it out to the list to be blessed (or damned, as the case may be). The proposed change is a new form of FETCH which allows the selecting fetching of message headers. The problem to be solved is that RFC-822 certain header lines are not represented in the IMAP envelope structure, nor is there any reasonable way to extend the envelope structure to accomodate them. It is considered mandatory that any extension be upwards/downwards compatible and not require revisiting the next time we need to be able to snarf another header. The most obvious example is the ReSent-Date/ReSent-From/ReSent-To header lines. There is an additional problem with these particular header lines in that they can not be arbitrarily reordered and retain the same meaning. Other headers, such as Newsgroups:, are also perceived as interesting. The proposed two new functions are a ``fetch all header lines of this message whose field names match any in this list'' and ``fetch all header lines of this message whose names do not match any in this list''. They take an argument which consists of a list of the field names. The result of these functions is a text string similar to that from RFC822.HEADER. All header lines are returned in the original order of the message (note this is a requirement for useful ReSent information). For example (note that line breaks are here only for clarity): A001 FETCH 23:30 (ENVELOPE RFC822.HEADER.LINES ("Resent-Date" "Resent-From" "Resent-To") would fetch the envelopes and remail information for messages 23 to 30. A001 FETCH 23 RFC822.HEADER.LINES.NOT ("Return-Path" "Received") would fetch the header of message 23 without the ``Return-Path'' or ``Received'' header lines. This would become a fundamental API call in c-client, and c-client would simulate its results if it finds itself talking to an IMAP server that does not support it. Comments please. From pinedev@shivax2.cac.washington.edu Sun Apr 18 20:20:32 1993 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20958; Sun, 18 Apr 93 20:20:32 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28848; Sun, 18 Apr 93 20:20:26 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from csgrad.cs.vt.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28836; Sun, 18 Apr 93 20:20:04 -0700 Received: by csgrad.cs.vt.edu (5.65/DEC-Ultrix/4.3) id AA05499; Sun, 18 Apr 1993 23:20:02 -0400 Date: Sun, 18 Apr 1993 23:10:39 -0400 (EDT) From: Laurence Lundblade Subject: Re: proposed IMAP protocol enhancement To: Mark Crispin Cc: IMAP Interest List , c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'd welcome the addition of these to IMAP. I've got a few questions: Would the functions just return plain unparsed strings? If so, then the Resent-xxxx: cases would require the client to do address parsing. This isn't a huge problem since the routines are there in the client anyway. It sounds like you have a choice of requesting the header lines that you want, one at a time, or parsing a big string that comes back. The problem with requesting the lines one at a time would be an RTT for each one, right? I'm also having trouble coming up with a use for the LINES.NOT function. Did you have something in mind? That's not to say it should be take out. I'm interested in the References: field for threading news groups and other mail folders. I think you need it because the full tree of In-Reply-To:'s might not be in the mailbox being threaded. Laurence Lundblade lgl@csgrad.cs.vt.edu or lgl@cac.washington.edu (forwarded to same place) Blacksburg, Virginia or Seattle, Washington On Sun, 18 Apr 1993, Mark Crispin wrote: > > I, perhaps more than anyone else, want to put a lid on further IMAP additions > in the name of stability and getting a Proposed Standard out of this. > However, something has come out that has survived even my harsh filters, and > I'm throwing it out to the list to be blessed (or damned, as the case may be). > > The proposed change is a new form of FETCH which allows the selecting fetching > of message headers. The problem to be solved is that RFC-822 certain header > lines are not represented in the IMAP envelope structure, nor is there any > reasonable way to extend the envelope structure to accomodate them. It is > considered mandatory that any extension be upwards/downwards compatible and > not require revisiting the next time we need to be able to snarf another > header. > > The most obvious example is the ReSent-Date/ReSent-From/ReSent-To header > lines. There is an additional problem with these particular header lines in > that they can not be arbitrarily reordered and retain the same meaning. > > Other headers, such as Newsgroups:, are also perceived as interesting. > > The proposed two new functions are a ``fetch all header lines of this message > whose field names match any in this list'' and ``fetch all header lines of > this message whose names do not match any in this list''. They take an > argument which consists of a list of the field names. The result of these > functions is a text string similar to that from RFC822.HEADER. All header > lines are returned in the original order of the message (note this is a > requirement for useful ReSent information). > > For example (note that line breaks are here only for clarity): > > A001 FETCH 23:30 (ENVELOPE RFC822.HEADER.LINES ("Resent-Date" "Resent-From" > "Resent-To") > > would fetch the envelopes and remail information for messages 23 to 30. > > A001 FETCH 23 RFC822.HEADER.LINES.NOT ("Return-Path" "Received") > > would fetch the header of message 23 without the ``Return-Path'' or > ``Received'' header lines. > > This would become a fundamental API call in c-client, and c-client would > simulate its results if it finds itself talking to an IMAP server that does > not support it. > > Comments please. > From pinedev@shivax2.cac.washington.edu Sun Apr 18 22:10:40 1993 -0700 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22077; Sun, 18 Apr 93 22:10:40 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15104; Sun, 18 Apr 93 22:10:34 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15092; Sun, 18 Apr 93 22:10:23 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA00786; Sun, 18 Apr 93 22:10:16 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA14216; Sun, 18 Apr 93 22:10:09 -0700 Date: Sun, 18 Apr 1993 22:00:17 -0700 (PDT) From: Mark Crispin Subject: Re: proposed IMAP protocol enhancement To: Laurence Lundblade Cc: IMAP Interest List , c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 18 Apr 1993 23:10:39 -0400 (EDT), Laurence Lundblade wrote: > Would the functions just return plain unparsed strings? If so, then the > Resent-xxxx: cases would require the client to do address parsing. This > isn't a huge problem since the routines are there in the client anyway. Yes, just plain unparsed strings would be returned. I don't particularly understand why you would want to address-parse the ReSent-* strings (other than perhaps to canonicalize their format), but as you point out the routines you need are in c-client anyway. > It sounds like you have a choice of requesting the header lines that you > want, one at a time, or parsing a big string that comes back. The problem > with requesting the lines one at a time would be an RTT for each one, > right? Yes, that's correct. The real intent is to be able to gobble down the useful header lines in addition to what the envelope gives to you and possibly just blat them to the screen without any processing. > I'm also having trouble coming up with a use for the LINES.NOT function. > Did you have something in mind? That's not to say it should be take out. It's in there primarily for symmetry. I don't think Pine will need it, but I'm fairly confident that if I don't put it in now, someone will be nagging me for it later! :-) Also, it was a basic function in MM's header filters, so there is some precedent for its use. > I'm interested in the References: field for threading news groups and other > mail folders. I think you need it because the full tree of In-Reply-To:'s > might not be in the mailbox being threaded. I would be delighted if Pine solved the threading problem this way! ;-) Yes, enabling this sort of thing without having to go and change IMAP again was one of the motivations. It doesn't rescue me from someday having to deal with cross-post suppression in the .newsrc on the server case though. :-( -- Mark -- From pinedev@shivax2.cac.washington.edu Mon Apr 19 10:47:43 1993 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05382; Mon, 19 Apr 93 10:47:43 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05276; Mon, 19 Apr 93 10:47:36 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05270; Mon, 19 Apr 93 10:47:34 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for c-client@cac.washington.edu; Mon, 19 Apr 93 13:47:30 EDT Received: via switchmail; Mon, 19 Apr 1993 13:47:29 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 19 Apr 1993 13:46:23 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 19 Apr 1993 13:46:15 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Mon, 19 Apr 1993 13:46:00 -0400 (EDT) Message-Id: Date: Mon, 19 Apr 1993 13:46:00 -0400 (EDT) From: John Gardiner Myers To: c-client@cac.washington.edu, imap@cac.washington.edu Subject: Re: proposed IMAP protocol enhancement In-Reply-To: References: Beak: Is I strongly support the FETCH RFC822.HEADER.LINES parameter. I don't see the point of FETCH RFC822.HEADER.LINES.NOT. It could be helpful to a client that wants to avoid presenting "uninteresting" headers like "Received:" to a user, but any client that wants to provide this feature is going to have to deal with a server's not providing that parameter anyway. I suppose it comes down to a question of whether the bandwidth saved would justify the cost of the additional parameter. Would it be possible to consider adding an analogous "HEADER name string" SEARCH criteria without opening the entire Pandora's box that is associated with SEARCH? This extension would help greatly in implementing kill files. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From pinedev@shivax2.cac.washington.edu Mon Apr 19 14:01:34 1993 -0700 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12680; Mon, 19 Apr 93 14:01:34 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19403; Mon, 19 Apr 93 14:01:26 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19397; Mon, 19 Apr 93 14:01:24 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA01277; Mon, 19 Apr 93 14:01:16 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA17018; Mon, 19 Apr 93 14:01:09 -0700 Date: Mon, 19 Apr 1993 13:53:26 -0700 (PDT) From: Mark Crispin Subject: Re: proposed IMAP protocol enhancement To: John Gardiner Myers Cc: c-client Interest List , IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 19 Apr 1993 13:46:00 -0400 (EDT), John Gardiner Myers wrote: > I don't see the point of FETCH RFC822.HEADER.LINES.NOT. My main concern is to avoid regretting having *not* put it in. I think it is rather trivial to do at the same time. The same arguments against it could also be applied against the RFC822.HEADER.LINES functionality as well, but there is a definite groundswell of support for it (and especially for support in c-client). > Would it be possible to consider adding an analogous "HEADER name > string" SEARCH criteria without opening the entire Pandora's box that > is associated with SEARCH? This extension would help greatly in > implementing kill files. If you can come up with a way of doing this without opening Pandora's box on searching, please feel free to suggest it. I'm totally clueless! From pinedev@shivax2.cac.washington.edu Tue Apr 20 21:00:27 1993 -0700 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20045; Tue, 20 Apr 93 21:00:27 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27775; Tue, 20 Apr 93 21:00:20 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from csgrad.cs.vt.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27760; Tue, 20 Apr 93 20:59:49 -0700 Received: by csgrad.cs.vt.edu (5.65/DEC-Ultrix/4.3) id AA19328; Tue, 20 Apr 1993 23:59:39 -0400 Date: Tue, 20 Apr 1993 23:52:45 -0400 (EDT) From: Laurence Lundblade Reply-To: Laurence Lundblade Subject: Re: proposed IMAP protocol enhancement To: Mark Crispin Cc: IMAP Interest List , c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Sun, 18 Apr 1993, Mark Crispin wrote: > Yes, just plain unparsed strings would be returned. I don't particularly > understand why you would want to address-parse the ReSent-* strings (other > than perhaps to canonicalize their format), but as you point out the routines > you need are in c-client anyway. OK, The reason I had in mind was canonicalization of their format for presentation to the user -- it's a nice thing to keep all the addresses looking similar. > > It sounds like you have a choice of requesting the header lines that you > > want, one at a time, or parsing a big string that comes back. The problem > > with requesting the lines one at a time would be an RTT for each one, > > right? > > Yes, that's correct. The real intent is to be able to gobble down the useful > header lines in addition to what the envelope gives to you and possibly just > blat them to the screen without any processing. I'm a little concerned about RTT's in a mailer that regularly fetches the Resent-XXX:, References: and other fields (presumably many if not most good IMAP clients will do this). You're probably one to think about this more than I, but wouldn't it at least double the number of RTT's for a lot of the normal operations? Is doubling the RTT's a problem? I know there's probably not much else that can be done without breaking existing IMAP clients. Laurence Lundblade lgl@csgrad.cs.vt.edu or lgl@cac.washington.edu (both forward to same place) Blacksburg, Virginia or Seattle, Washington From pinedev@shivax2.cac.washington.edu Fri Apr 23 03:00:39 1993 -0700 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24400; Fri, 23 Apr 93 03:00:39 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12177; Fri, 23 Apr 93 03:00:26 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12171; Fri, 23 Apr 93 03:00:24 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA07229; Fri, 23 Apr 93 03:00:15 -0700 Date: Fri, 23 Apr 1993 02:56:50 -0700 (PDT) From: Mark Crispin Subject: Re: proposed IMAP protocol enhancement To: Laurence Lundblade Cc: IMAP Interest List , c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 20 Apr 1993 23:52:45 -0400 (EDT), Laurence Lundblade wrote: > I'm a little concerned about RTT's in a mailer that regularly fetches the > Resent-XXX:, References: and other fields (presumably many if not most > good IMAP clients will do this). You're probably one to think about this > more than I, but wouldn't it at least double the number of RTT's for a lot > of the normal operations? Is doubling the RTT's a problem? I know there's > probably not much else that can be done without breaking existing IMAP > clients. That's a good point. I think that when the API is done for this there should be some sort of means to all for it to be fetched it along with something else to avoid the extra RTT. How about fetching it along with section 1 of the body? It'd be a new API function, no matter what. From pinedev@shivax2.cac.washington.edu Fri Apr 23 06:15:35 1993 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26999; Fri, 23 Apr 93 06:15:35 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00451; Fri, 23 Apr 93 06:15:29 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from csgrad.cs.vt.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00439; Fri, 23 Apr 93 06:15:07 -0700 Received: by csgrad.cs.vt.edu (5.65/DEC-Ultrix/4.3) id AA12505; Fri, 23 Apr 1993 09:15:05 -0400 Date: Fri, 23 Apr 1993 09:02:07 -0400 (EDT) From: Laurence Lundblade Subject: Re: proposed IMAP protocol enhancement To: Mark Crispin Cc: IMAP Interest List , c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Yes, creating a new call in the API that fetches the extended header along with the 1st body part seems fine. I was going to mention this last time, but I was also thinking about the case when you're fetching envelopes. If we do threading based on the References: field (I'm still investigating whether or not that is the way to go) then you'll want to fetch this extended header information with all the envelopes. Since you can fetch them all with one RTT it's still only doubling, so I guess it's OK. I am a little worried about performance for threading. To do threading one has to fetch the envelopes of all the messages in the mailbox, as well as the References fields. While you're redesigning API's maybe an extended mail_fetchstructure could get the Resent-xxx, References and Newsgroups fields. Those are the ones for which we've got a clear need that I can think of. LL On Fri, 23 Apr 1993, Mark Crispin wrote: > > On Tue, 20 Apr 1993 23:52:45 -0400 (EDT), Laurence Lundblade wrote: > > I'm a little concerned about RTT's in a mailer that regularly fetches the > > Resent-XXX:, References: and other fields (presumably many if not most > > good IMAP clients will do this). You're probably one to think about this > > more than I, but wouldn't it at least double the number of RTT's for a lot > > of the normal operations? Is doubling the RTT's a problem? I know there's > > probably not much else that can be done without breaking existing IMAP > > clients. > > That's a good point. I think that when the API is done for this there should > be some sort of means to all for it to be fetched it along with something else > to avoid the extra RTT. How about fetching it along with section 1 of the > body? > > It'd be a new API function, no matter what. > From pinedev@shivax2.cac.washington.edu Fri Apr 23 06:59:06 1993 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27538; Fri, 23 Apr 93 06:59:06 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00756; Fri, 23 Apr 93 06:59:00 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from info.cren.net by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00744; Fri, 23 Apr 93 06:58:47 -0700 Received: by info.cren.net (4.1/1.0-BITnet NIC); id AA13199; Fri, 23 Apr 93 09:53:55 EDT Date: Fri, 23 Apr 1993 09:47:35 -0400 (EDT) From: Jim Conklin Subject: Re: proposed IMAP protocol enhancement To: Mark Crispin Cc: IMAP Interest List , c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Until a Mail Requirements group defines a real standard for list mail, CREN's RFP for Internet list-management software proposes to use the Resent- headers, so capturing those headers is of considerable importance to us. (It's available from info.cren.net as the files ip-listserv.txt, ip-listserv.ps, or ip-listserv.rtf in the directory /cren-rfp, if you haven't seen it and are interested.) Thanks, Jim Conklin From pinedev@shivax2.cac.washington.edu Wed Apr 28 10:44:35 1993 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27988; Wed, 28 Apr 93 10:44:35 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29013; Wed, 28 Apr 93 10:44:14 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from eco.twg.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29007; Wed, 28 Apr 93 10:44:10 -0700 Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA15576; Wed, 28 Apr 93 13:44:04 -0400 Message-Id: <9304281744.AA15576@eco.twg.com> Received: from apache.twg.com by apache.twg.com id <9288-0@apache.twg.com>; Wed, 28 Apr 1993 10:44:00 -0700 From: "David Herron" Subject: IMAP on SysVr3 To: c-client Interest List (Non Receipt Notification Requested) (IPM Return Requested) Date: Wed, 28 Apr 93 10:43:58 PDT Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 15 TEXT , 4 TEXT Greetings! I don't want to disrupt the mailing list too much .. but a question came to me of whether IMAP had been ported to System Vr3 (on either 3B2 or Amdahl .. which shouldn't make any difference). The reference implementation is only running on SysVr4 and there are some system calls (ftruncate() being the biggy) which are only on r4 and not r3. At one time I attempted a workaround for the missing ftruncate() but the workaround (copy needed bytes to a second file, then copy back) ended up losing the entire mailbox in some cases (full disk). Has anybody done this ?? David <- David Herron (work) (home) <- <- <- Where su-b-tlety is taken to an art! From pinedev@shivax2.cac.washington.edu Wed Apr 28 13:47:15 1993 -0700 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05185; Wed, 28 Apr 93 13:47:15 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12659; Wed, 28 Apr 93 13:47:01 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12653; Wed, 28 Apr 93 13:46:59 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA01006; Wed, 28 Apr 93 13:46:51 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA02517; Wed, 28 Apr 93 13:46:43 -0700 Date: Wed, 28 Apr 1993 13:29:55 -0700 (PDT) From: Mark Crispin Subject: re: IMAP on SysVr3 To: David Herron Cc: c-client Interest List In-Reply-To: <9304281744.AA15576@eco.twg.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII There is a system call in some versions of SysV called chsize() which does the exact same thing as ftruncate(). It doesn't seem to be common though. From pinedev@shivax2.cac.washington.edu Tue May 25 16:36:58 1993 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25606; Tue, 25 May 93 16:36:58 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09240; Tue, 25 May 93 16:36:47 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09234; Tue, 25 May 93 16:36:45 -0700 Received: from ssrg-ipc-5.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA02639; Tue, 25 May 93 16:36:42 PDT Date: Tue, 25 May 1993 15:53:16 -0700 (PDT) From: Mike Macgirvin Reply-To: Mike_Macgirvin@CAMIS.Stanford.EDU Subject: message/rfc822 (the other direction) To: c-client@cac.washington.edu Cc: mrc@camis.stanford.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I got the type message/rfc822 stuff working very well on the incoming side (Many thanks Mark, many things got cleaned up as a result). Now I'm having troubles going the other direction (building a multipart for sending which includes an rfc822 message). I don't know the recommended way to do this, so please don't flame if I've overlooked something obvious, or I'm doing something foolish. All I have to go on right now is from looking at Pine code and reading Internal.DOC. Anyway, I put together a new body part and fill in the envelope and type info such just as for any other attachment (which work fine). In this case I have (part->body)->contents.msg.text point at the actual message text (a complete message w/header). This appears to be what Pine does. Other than that, it's processed like any other attachment (which all work correctly). smtp_mail() is called on the top-level body, and any other parts are sent intact, while the rfc822 attachment always arrives devoid of contents. So, any clues as to what I've done wrong here? From pinedev@shivax2.cac.washington.edu Thu May 27 00:27:56 1993 -0700 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07720; Thu, 27 May 93 00:27:56 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20748; Thu, 27 May 93 00:26:46 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20742; Thu, 27 May 93 00:26:44 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.27.MRC ) id AA10036; Thu, 27 May 93 00:26:42 -0700 Date: Thu, 27 May 1993 00:08:22 -0700 (PDT) From: Mark Crispin Subject: re: message/rfc822 (the other direction) To: Mike_Macgirvin@CAMIS.Stanford.EDU Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Mike - The answer to your question is that the MESSAGE structure is used by the MIME parser only (note the comment to that effect in mail.h in the definition of the BODY structure at the contents union. In particular, body->contents.msg.text is something that is private to the imap2 driver and MUST NOT be used by main programs. The only things in the MESSAGE structure that you may look at are the env and body pointers (body->contents.msg.env and body->contents.msg.body). The text and offset members are private for various drivers (and I'll probably smash them together in a union too since both are never used simultaneously). In order to send a MESSAGE attachment, you have to put it on body- >contents.text like you would any other type of attachment. See the routine rfc822_encode_body() in rfc822.c for how this works. I will be the first to admit that this is ugly, hideous, and inconsistent and I'll probably be reincarnated as a banana slug for doing it that way, but it was easier to program that way, both in c-client and in the main programs. Probably I'll get reincarnated as a banana slug right next to a hungry garter snake (or a fellow with a salt shaker) for this, but Internal.DOC is way out of date (almost a year old). I don't think there are very many lies in it and certainly no egregious ones, but it is missing quite a bit that was added or changed in the past year. The only 100% reliable document right now is the c-client sources, so when in doubt you should refer to them. I'll probably update Internal.DOC sometime after updating the IMAP2 protocol specification, which is a looming Urgent Problem. -- Mark -- From pinedev@shivax2.cac.washington.edu Thu May 27 08:09:16 1993 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-