From pinedev@shivax2.cac.washington.edu Mon Aug 31 22:03:18 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19933; Mon, 31 Aug 92 22:03:18 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21680; Mon, 31 Aug 92 22:03:17 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21672; Mon, 31 Aug 92 22:03:16 -0700 Date: Mon, 31 Aug 1992 21:46:11 -0700 (PDT) From: Mark Crispin Subject: welcome to the IMAP interest list To: IMAP 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 IMAP interest list at the University of Washington. The purpose of this list is for discussion and announcements related to the IMAP2 protocol described by RFC-1176 and updated by the draft IMAP2bis document. 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: IMAP@CAC.Washington.EDU To request addition/deletions to the list, send mail to: IMAP-request@CAC.Washington.EDU Related mailing lists which may be of interest: c-client@CAC.Washington.EDU c-client e-mail software library 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 04:45:10 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26205; Tue, 1 Sep 92 04:45:10 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23603; Tue, 1 Sep 92 04:45:08 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23597; Tue, 1 Sep 92 04:45:03 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <19787-4@ppsw1.cam.ac.uk>; Tue, 1 Sep 1992 12:44:50 +0100 Date: Tue, 01 Sep 92 12:44:35 BST From: A Grant To: imap@cac.washington.edu Subject: IMAP2 futures? Message-Id: First, thank you to Mark Crispin for creating this list! I'd like to ask what work is under way, or planned, for the next version of IMAP2. In particular, are there plans for protocol support for: 1. access to the host's quota control mechanism, where one exists 2. password changing (for non-Kerberos sites) 3. forwarding (automatic, i.e. access to '.forward' file or equivalent) ... 4. simple X.500 interface 5. forwarding (user-initiated, i.e. in a session) 6. mail sending (in decreasing order of importance - gap indicates where 'really needed' changes to 'would be nice'). I can provide arguments for each of those on request, and could probably work out upwards-compatible protocol extensions, but I thought I'd check first to see if anyone else agrees. I realise not all servers will want to / be able to provide any of these functions, but many host systems can do, and it would be better to have standardised protocol extensions rather than everyone inventing their own. In particular, we see access to quota control (i.e. simply finding out what percentage of quota has been used) as essential for naive users, since the consequences of exceeding quotas can be utterly confusing. -- Alasdair Grant +44 223 334447 MVS Systems Group / Small Systems Integration Group University Computing Service, A.Grant@ucs.cam.ac.uk Pembroke St., Cambridge CB2 3QG, UK From pinedev@shivax2.cac.washington.edu Tue Sep 1 14:07:18 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA12245; Tue, 1 Sep 92 14:07:18 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29395; Tue, 1 Sep 92 14:07:14 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29389; Tue, 1 Sep 92 14:07:12 -0700 Date: Tue, 1 Sep 1992 13:38:30 -0700 (PDT) From: Mark Crispin Subject: re: IMAP2 futures? To: IMAP Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII You raise a number of interesting questions: > 1. access to the host's quota control mechanism, where one exists This is difficult to do in any sort of general way. One problem is that different implementations have different interpretations of quotas. On many systems, a quota is really some number of disk records (or clusters of disk records). Users often don't know their real quota; they are told some number of `bytes' or `blocks' but they discover -- to their confusion -- that they are out of quota even though the total number of `bytes' or `blocks' is considerably less. [Anecdote: A system I used 19 years ago gave users a `100 block' quota, saying this was 64,000 characters. However, it actually allocated (and charged!) in clusters of 5 blocks, so the actual limit was 20 files, and only if the files were less than 3200 characters each -- a 3201 character file was charged as 10 blocks.] I agree that some mechanism to give users a handle on their disk quota remotely is necessary. It is important that any mechanism picked *not* be biased towards on particular operating system's strategy, and that the data be useful for a user. Another issue is scoping; IMAP must not be allowed to get `everything but the kitchen sink' put in, or we'll end up with an unwieldy mess. This is one reason why only minimal management was put into IMAP2bis and why the more complex management issues were deferred to the Mail Management Protocol. So, let's put this on the table as a topic. Modern-day c-client does detect and clean up properly when quota problems hit. > 2. password changing (for non-Kerberos sites) I believe that this was going to be considered as part of the Mail Management Protocol developed by CMU. I'd like to hear comments from the CMU hackers on this. I think that an environment in which users do not log into the IMAP server as timesharing users will have to have the Mail Management Protocol layer; the IMAP-only environment is for the `simple' configurations. > 3. forwarding (automatic, i.e. access to '.forward' file or equivalent) This is also a Mail Management Protocol issue for the same reasons. CMU??? > 4. simple X.500 interface This is one of those things that everyone talks about a lot, but it isn't all that clear to me what it implies. X.500 is supposed to solve all our problems but then again X.400 was supposed to do so too. I don't think that `simple' and `X.anything' properly go together. We'll need to do something about this, but I'm taking a `wait and see' attitude until I understand the issues better. > 5. forwarding (user-initiated, i.e. in a session) Could you explain this? I don't quite understand what you mean. Do you mean forwarding a message or altering your mail forwarding or ?? > 6. mail sending This is a frequently asked request. The IETF-REMMAIL group seems to have sputtered out on this question, without achieving closure. There are strong arguments on both sides of the issue. Although I am an `anti', I am sympathetic to the problems the `pro' side faces; however, I have been totally unsuccessful in playing Devil's Advocate for the `pro' side. I suggest a review of the IETF-REMMAIL@UMich.EDU discussion to avoid rehashing the same points over again. It's an emotional topic; the `pro' side is defending what they consider to be the side of simplicity (of a sort) and authentication (again, of a sort), while the `anti' side defends simplicity (of a different sort) and models which are possible only if mail access and mail posting are not coupled. If possible, I would like to see the discussion of this topic take place on IETF-REMMAIL and not here. I am agreeable to letting IMAP follow the concensus of the IETF-REMMAIL group, should they achieve closure on the topic. -- Mark -- From pinedev@shivax2.cac.washington.edu Tue Sep 1 14:17:10 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA12683; Tue, 1 Sep 92 14:17:10 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29539; Tue, 1 Sep 92 14:17:07 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29533; Tue, 1 Sep 92 14:17:05 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <27372-0@ppsw1.cam.ac.uk>; Tue, 1 Sep 1992 22:17:00 +0100 Date: Tue, 01 Sep 92 22:16:45 BST From: A Grant To: imap@cac.washington.edu Subject: re: IMAP2 futures? Message-Id: In-Reply-To: > > 1. access to the host's quota control mechanism, where one exists > This is difficult to do in any sort of general way. One problem is that > different implementations have different interpretations of quotas. why not return percentage of quota used so far, according to the system (e.g. use the 'quota' command on SunOS) - if the system is inaccurate, that's too bad, but it may be accurate. > Modern-day c-client does detect and clean up properly when quota problems hit. Er, how? Do you mean the c-client in the Washington distribution has agreed a private protocol (e.g. a text in a BAD message) to pass this information on? > > 5. forwarding (user-initiated, i.e. in a session) > Could you explain this? I don't quite understand what you mean. Do you mean > forwarding a message or altering your mail forwarding or ?? I mean sending on a mail message at the server (i.e. in a mailbox) without having it delivered to the client and then sent back via SMTP. Apart from being more efficient, if the user gets a MIME message that breaks their client (e.g. by being humungously large), server-end forwarding might be the only means of passing the message on to the system administrator. Ideally it should accept an attached note, and encapsulate the original mail using MIME. But then you're half way to a 'send mail' function. > > 6. mail sending > I suggest a review of the IETF-REMMAIL@UMich.EDU discussion to avoid rehashing > the same points over again. It's an emotional topic; the `pro' side is > defending what they consider to be the side of simplicity (of a sort) and > authentication (again, of a sort) I guess 'draft message handling' would be more accurate. I wouldn't particularly mind if a client had to extract draft messages out of the IMAP2 server and then post them off using SMTP. What I am trying to get out of is a situation where a user is tied to one system because all their drafts are stored there. Our users want to treat mail like a telephone network - walk up to the nearest PC or Mac and there you are, complete with draft messages, user preferences etc. From pinedev@shivax2.cac.washington.edu Tue Sep 1 14:21:53 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA12855; Tue, 1 Sep 92 14:21:53 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29616; Tue, 1 Sep 92 14:21:48 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from PO5.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29608; Tue, 1 Sep 92 14:21:46 -0700 Received: by po5.andrew.cmu.edu (5.54/3.15) id for IMAP@cac.washington.edu; Tue, 1 Sep 92 17:21:43 EDT Received: via switchmail; Tue, 1 Sep 1992 17:21:42 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 1 Sep 1992 17:20:04 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 1 Sep 1992 17:19:49 -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; Tue, 1 Sep 1992 17:19:33 -0400 (EDT) Message-Id: Date: Tue, 1 Sep 1992 17:19:33 -0400 (EDT) From: John Gardiner Myers To: IMAP Interest List Subject: Re: IMAP2 futures? In-Reply-To: References: Beak: is Not Unfortunately, the CMU hackers have been too bogged down in issues like user surveys, requirements documents, and beginning-of-semester firefighting to get any real progress done on a mail management protocol. AMDS (the Andrew Message Delivery System) has the forwarding information in the "White Pages" user directory component. Users change their mail forwarding with the same mechanism they use to change their office phone number, though many client programs provide more direct support for changing the former than the latter. I tend to share Mark's reluctance about anything with a name starting with "X.". There is a directory service named "CSO/ph" or similar that seems simple. I haven't examined it in detail, but I believe it deserves looking into. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From pinedev@shivax2.cac.washington.edu Tue Sep 1 18:18:08 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19864; Tue, 1 Sep 92 18:18:08 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02265; Tue, 1 Sep 92 18:18:03 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02255; Tue, 1 Sep 92 18:17:53 -0700 Received: from scapa.cs.ualberta.ca by scapa.cs.ualberta.ca with UUCP id <42603-2>; Tue, 1 Sep 1992 19:17:28 -0600 Received: by isagate.edm.isac.ca (/\==/\ Smail3.1.25.1 #25.2) id ; Tue, 1 Sep 92 18:52 MDT Received: from isasun-3.edm.isac.ca by isasun-1.edm.isac.ca with smtp (Smail3.1.26.7 #1) id m0mPizY-000cuvC; Tue, 1 Sep 92 18:54 MDT Received: by isasun-3.edm.isac.ca (/\==/\ Smail3.1.20.1 #20.1) id ; Tue, 1 Sep 92 18:50 MDT Message-Id: From: steve@edm.isac.ca (Steve Hole) Subject: re: IMAP2 futures? To: imap@cac.washington.edu (IMAP Interest List) Date: Tue, 1 Sep 1992 18:50:29 -0600 X-Mailer: ELM [version 2.3 PL4] Oh boy, are you ready Mark? Joel King, Ken Bobey and I have been saving up for a long time. The ideas are just exploding from us ... so to speak :-). Some of this conversation spills over into the realm of the c-client, so I am also cross posting it to that list as well. > You raise a number of interesting questions: He sure did. > > 1. access to the host's quota control mechanism, where one exists This was explained quite well. It's not something we have worried about a lot, because our sites tend to be disk rich, and the c-client handled write failures due to space adequately. > > 2. password changing (for non-Kerberos sites) > > I believe that this was going to be considered as part of the Mail Management > Protocol developed by CMU. I'd like to hear comments from the CMU hackers on > this. I think that an environment in which users do not log into the IMAP > server as timesharing users will have to have the Mail Management Protocol > layer; the IMAP-only environment is for the `simple' configurations. I have been thinking about this a lot! The whole concept of authentication is becoming a real issue, but I don't think that it should be handled in something as application specific as the Message Management Protocol. The issue of remote server authentication obviously extends beyond MUAs. Any or all distributed applications require this type of authentication, and current host based authentication services will not cut it. The model that we have been working on for the last six months or so was to develop a true Internet MUA. IMAP and the c-client go a long way to realizing that, but do not address the general problem of authentication. That is OK, because they were not designed to do so. To my mind, it should be sufficient for a mail server to provide: 1. A message store that an MTA can deliver to. 2. A message store that can be accessed via a remote MUA. It should not be a requirement for a user to have an account on the mail host just to provide authentication or to identify the user to the MTA as a potential recipient in the local message store. Currently of course, this is not possible because: 1. The mailhost also performs authentication for the remote MUA applications using standard host-based authentication mechanisms. 2. The current run of MTA's depend on local authentication information (the password file) as the routing mechanism for delivery to the local message store. The ideal situation would be to (1) have a host independent repository for mail application authentication and routing information, and (2) to have a common interface for both MTAs and MUAs (and all other distributed applications for that matter) be able to access that host independent information. So the question is: where should the authentication and routing information come from? A good start for authentication would be to kerberize both the IMAPD server and the clients. We have talked about it here, but hadn't gotten to it yet. I had also heard a rumour that Mark has considered kerberizing the c-client - this is a very good idea Mark, and I will happily volunteer our group to perform this task if you would like. While kerberos will handle TCP channel authentication well, it does not appear to me that it is a general enough solution to be useful for routing to message stores and password management - I may be out to lunch on the last part of that statement. I am currently working on a secure access model based on the features of (watch Mark cringe here), the X.500 directory service - specifically the QUIPU X.500 implementation provide with the ISODE software. The Directory was designed to be a general mechanism for providing configuration and authentication information to users and applications. Authentication and security mechanisms comparable to kerberos are provided via the OSISEC (X.509) and the lightweight directory access protocols over TCP/IP. The nice thing about X.500 (and I really don't think that it is comparable to X.400) is that the authentication information about any user can be made available to any application in a host independent manner, but is completely secure from tampering (which cannot necessarily be said about the host based authentication mechanisms :-). There is still a fair amount of work to be done to create a practical application, but it can, and is being done. I expect that ecs will have to support a couple of different authentication mechanisms for now, but I expect that this will be the mechanism of choice in the future. I will be producing a paper that describes the concepts in detail for a conference in late October and will certainly make it available. > > 3. forwarding (automatic, i.e. access to '.forward' file or equivalent) > > This is also a Mail Management Protocol issue for the same reasons. CMU??? Agreed, these are absolutely management functions. Note that most MTAs perform this function quite well, but once again, make use of host based account information to do it. The thing that I am interested in is how the management protocol is going to work. We have been told that there is one in the works, but have heard virtually nothing about it. It occurred to us early on, that many of the management functions like asynchronous notification, automatic reply and forwarding and others (actually the X.400 spec has a good list) required participation by both the MTA and the MUA. We thought that the MTA should react to requested services like forwarding at delivery time (how could the MUA do it ???), but the MUA should control the service. That is, the user will request management functions through the MUA, but some of them will be acted upon by the MTA. In fact, if there was a concept of an active (rather than passive) message store in the Internet model, it should perform these functions. We have thought seriously about implementing an active message store, but have delayed because both the c-client (imapd) and the MTAs *kind of* implement active message store functions. Obviously we were getting into a rats nest. I don't think that the old BSD flat file message store is really a good modern solution to this problem though either. > > > 4. simple X.500 interface > > This is one of those things that everyone talks about a lot, but it isn't all > that clear to me what it implies. X.500 is supposed to solve all our problems > but then again X.400 was supposed to do so too. I don't think that `simple' > and `X.anything' properly go together. We'll need to do something about this, > but I'm taking a `wait and see' attitude until I understand the issues better. Well, I have already identified two uses - authentication and routing configuration information. The problem with X.500 is not that it is too complicated, it is just so powerful people seem to have a hard time figuring out how to use it all at once. The trick is not to use it all at once, just the applicable features. The features that we made use of in authentication and routing can be thought of in the same vein as Sun's NIS (yellow pages). In this case it is application configuration information that is being held and provided by the directory. There is little direct user involvement. There are several other uses that the directory can be put to for MUAs and MTAs as well. The most probable is a white pages service - we have been doing it for some time now. The idea here is to simply look for users, organizations, or applications (yes, applications - perhaps a fax server) that you want to send mail to. As soon as your network gets any size, it becomes impossible to remember what Joe in accountings mail address was. Using a whitepages directory user agent (DUA) inteface, you can very effectively look up an individual, and even get a digitized picture and voice sample along with the information. Our integration with the MUA at this level is simply to have the two applications communicate and exchange the relevant information. The mail address, full name, and title information for example can be copied directly into the address field of an outgoing message, or into a local address book for quick reference in the future. Another use for the directory is to hold mailing lists - both private and public. I guess there are those who will argu that the mailing list should be held by the local message store (or MTA I guess), but there is no capability in the message store to provide or restrict access to this information. All of these features are provided for naturally in the directory. The MTA and MUA just have to be designed to access the information - this is not difficult to do. In fact, routing information in general can be provided by the directory in exactly the same way as MX record info is provided to MTAs now from DNS. > > 5. forwarding (user-initiated, i.e. in a session) > > Could you explain this? I don't quite understand what you mean. Do you mean > forwarding a message or altering your mail forwarding or ?? I think he wants to forward the message to another address simply by issuing an IMAP primitive, not by resending through a local smtp MTA. This is intimately related to the next section, and should be good for a lengthy debate here. I am not sure how I feel about this, except to say that it involves the concept of an active message store entity once again. I think that there is some merit to this suggestion - as I said before there are certain things that really make sense this way. The thing to do maybe is to define all the things that we would like to be able to do INDEPENDENT OF THE PROCESS THAT PERFORMS THEM, then try to assign them to the different roles in a process model. For example, just say "we want ot be able to automatically forward mail to another address", then worry about whether the MUA, MTA or (if there is such a thing) MS actually performs the function. > > 6. mail sending > > If possible, I would like to see the discussion of this topic take place on > IETF-REMMAIL and not here. I am agreeable to letting IMAP follow the > concensus of the IETF-REMMAIL group, should they achieve closure on the topic. Hmm ... for new messages I can see no reason for submitting new messages through the message store, in fact, I can see reasons for not wanting to do it - and forwarding for that matter as well. The question merits discussion however, so I guess I should join this list. Do you have some information on how to get onto it. Cheers all. I hope that I have stimulated some good discussion, but have not offended. It was not my intention to do so. -- Steve Hole Director of Research and Communications ISA Corporation mail: steve@edm.isac.ca Edmonton, Alberta, Canada phone: (403) 420-8081 From pinedev@shivax2.cac.washington.edu Tue Sep 1 21:17:48 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22619; Tue, 1 Sep 92 21:17:48 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03337; Tue, 1 Sep 92 21:17:39 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from nttta.NTT.JP by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03329; Tue, 1 Sep 92 21:17:36 -0700 Received: by ntt-sh.ntt.jp (5.59/ntt-sh-04h) with TCP; Wed, 2 Sep 92 13:14:56 JST Received: by mecl-sh.ntt.jp (4.1/MECLSH01) with TCP; Wed, 2 Sep 92 13:17:41 JST Received: by nttmfs.ntt.jp (3.2/NTTcs01b) with TCP; Wed, 2 Sep 92 13:17:40 JST Received: by mahler.ntt.jp (4.1/NTTcs01b) with TCP; Wed, 2 Sep 92 13:17:39 JST Message-Id: <9209020417.AA14419@mahler.ntt.jp> To: imap@cac.washington.edu Subject: Internatinalization for IMAP2 (was: IMAP2 futures? ) Date: Wed, 02 Sep 92 13:17:39 JST From: hitoaki@mahler.ntt.jp What is the policy of internatinalization for IMAP2 ? I think the imprementation of the IMAP2 search facility considerablly affrects the internatinalization of IMAP2. If this facility is not well-designed , IMAP2 can't be multilingual. -hitoaki ------ 日本電信電話株式会社 交換システム研究所 伝達ソフトウェア研究部 電気通信大学 情報工学科 坂本仁明 (hitoaki@mahler.ntt.jp/hitoaki@cs.uec.ac.jp) From pinedev@shivax2.cac.washington.edu Tue Sep 1 22:57:30 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23992; Tue, 1 Sep 92 22:57:30 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03740; Tue, 1 Sep 92 22:57:26 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03732; Tue, 1 Sep 92 22:57:25 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02774; Tue, 1 Sep 92 22:57:22 -0700 Date: Tue, 1 Sep 1992 22:49:15 -0700 (PDT) From: Terry Gray Subject: Re: IMAP2 futures? To: John Gardiner Myers Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 1 Sep 1992, John Gardiner Myers wrote: > AMDS (the Andrew Message Delivery System) has the forwarding > information in the "White Pages" user directory component. Users > change their mail forwarding with the same mechanism they use to > change their office phone number, though many client programs provide > more direct support for changing the former than the latter. If delivery is to a pool of centrally-managed servers, why does the user need to worry about forwarding? Or is this to accommodate folks with departmental hosts? > I tend to share Mark's reluctance about anything with a name starting > with "X.". There is a directory service named "CSO/ph" or similar > that seems simple. I haven't examined it in detail, but I believe it > deserves looking into. I agree that ph should be evaluated before falling into the X. hole (though Michigan claims that X.500 over the new light-weight stack is working well for them), but my question is: why is this an IMAP issue? I would have guessed it was an MUA function. (Actually, pair of functions, as I'm interested in both the usual human-initiated W.P. search for someone's address, plus the ability for the MUA to *validate* addresses --at least local ones-- before sending the msg. It's always annoying to reply to a msg that has a bunch of addresses, one of which is a typo.) -teg From pinedev@shivax2.cac.washington.edu Wed Sep 2 04:23:07 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29023; Wed, 2 Sep 92 04:23:07 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA05310; Wed, 2 Sep 92 04:23:02 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA05304; Wed, 2 Sep 92 04:22:59 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <07217-0@ppsw1.cam.ac.uk>; Wed, 2 Sep 1992 12:22:54 +0100 Date: Wed, 02 Sep 92 12:22:36 BST From: A Grant To: imap@cac.washington.edu Subject: Re: IMAP2 futures? Message-Id: In-Reply-To: Terry Gray writes: > If delivery is to a pool of centrally-managed servers, why does the user > need to worry about forwarding? Or is this to accommodate folks with > departmental hosts? Partly. Also users doing spells at other places for the odd 6 months. > I agree that ph should be evaluated before falling into the X. hole > (though Michigan claims that X.500 over the new light-weight stack is > working well for them), but my question is: why is this an IMAP issue? Because IMAP2 _could_ be a way (because it's extensible, and because it already does one major component pretty well, i.e. mail retrieval) to provide advanced mail functions over IP to clients which don't have a full OSI stack. I think the difficulties of X.500 are being exaggerated (and many are fixed in X.500(92)). For example, some sites have _already_ converted their finger daemons to do X.500 lookup. This also provides some X.500 functionality to IP-based clients. However, there is no standard for X.500-over-finger, and it is not integrated with mail. > I would have guessed it was an MUA function. Not sure what you mean here. The MUA isn't going to have an OSI stack (if it was, we'd use P7 rather than IMAP2). So it would have to agree on a private X.500-over-IP protocol to talk to a relay that could do the DUA functions for it. There is no existing standard protocol (unless this Michigan thing is going to become one). If the new protocol has to fit in somewhere, IMAP2 seems as good a place as any, as there are benefits from integrating DUA with MUA, e.g. reverse lookup on addresses in received messages, and use of the Directory to store configuration information. From pinedev@shivax2.cac.washington.edu Wed Sep 2 22:53:01 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02056; Wed, 2 Sep 92 22:53:01 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA16882; Wed, 2 Sep 92 22:50:33 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA16876; Wed, 2 Sep 92 22:50:27 -0700 Date: Wed, 2 Sep 1992 22:33:50 -0700 (PDT) From: Mark Crispin Subject: re: IMAP2 futures? To: A Grant Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 01 Sep 92 22:16:45 BST, A Grant wrote: > why not return percentage of quota used so far The question is, what does that mean to the user? Telling me that I am using 45% of my quota tells me nothing about the question of whether or not copying this 50,000 character will will blow me away or not. Note too that other than remote COPY, there is very little that can be done in IMAP to *use* more quota. You can reduce your usage via IMAP, but I question whether telling someone `you are using 95% of your quota' is going to do anything to encourage him to use less. Remember, that statement can be interpreted to mean `you are only using 95% of what you are entitled to.' I think this needs more consideration and input from other individuals. I'm not sure if this is an IMAP issue or not. > > Modern-day c-client does detect and clean up properly when quota problems > > hit. > Er, how? Do you mean the c-client in the Washington distribution has > agreed a private protocol (e.g. a text in a BAD message) to pass this > information on? The /usr/spool/mail operations that could make the mail file larger are checked for a worst case expansion vs. quota and are rejected if it would run out of disk space. If a quota problem hits with COPY, the COPY is completely backed out of and the entire COPY command is rejected with a NO. Remember, the server does not run with privileges and so has to obey the kernel on quotas. > I mean sending on a mail message at the server (i.e. in a mailbox) without > having it delivered to the client and then sent back via SMTP. Apart from > being more efficient, if the user gets a MIME message that breaks their > client (e.g. by being humungously large), server-end forwarding might be > the only means of passing the message on to the system administrator. > Ideally it should accept an attached note, and encapsulate the original > mail using MIME. But then you're half way to a 'send mail' function. Most of us consider `mail forwarding' to mean encapsulating the message within another message. You would be putting user interface and sending within a message. `Remailing' in this fashion may be reasonable though. However, this is merely `for efficiency' since the same resulting function can be accomplished by existing mechanisms. This is a good reason to reject it; any function which by its fundamental nature is optional and exists only for `efficiency' tends not to get implemented widely. You can either end up with a lot of protocol baggage or recognize reality. Most modern protocol design does the latter. > I guess 'draft message handling' would be more accurate. I wouldn't > particularly mind if a client had to extract draft messages out of the > IMAP2 server and then post them off using SMTP. What I am trying to get > out of is a situation where a user is tied to one system because all > their drafts are stored there. Our users want to treat mail like a > telephone network - walk up to the nearest PC or Mac and there you are, > complete with draft messages, user preferences etc. Remote storage of mail drafts is an interesting suggestion and it is certainly something to bring up to the IETF-REMMAIL group. I would support an effort on this, but I don't think it belongs in IMAP under the `avoid too much baggage in IMAP' banner. Also, I'm not convinced drafts belong on the IMAP server as opposed to the `home directory' server. What if the IMAP server is overseas (this is a real world situation for me!)? Putting it in IMAP seems to be false `efficiency'. I think you have some really good ideas, just that you're seeking the wrong place to see them implemented. The stuff you suggest belongs in a distributed mail system just as IMAP does, but it does not (necessarily) belong in IMAP. Please consider bringing it up to the IETF-REMMAIL group. Regards, -- Mark -- From pinedev@shivax2.cac.washington.edu Wed Sep 2 23:02:13 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02172; Wed, 2 Sep 92 23:02:13 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA16924; Wed, 2 Sep 92 23:00:06 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA16915; Wed, 2 Sep 92 22:59:56 -0700 Date: Wed, 2 Sep 1992 22:51:47 -0700 (PDT) From: Mark Crispin Subject: re: Internatinalization for IMAP2 (was: IMAP2 futures? ) To: hitoaki@mahler.ntt.jp Cc: imap@cac.washington.edu In-Reply-To: <9209020417.AA14419@mahler.ntt.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 02 Sep 92 13:17:39 JST, hitoaki@mahler.ntt.jp wrote: > What is the policy of internatinalization for IMAP2 ? > > I think the imprementation of the IMAP2 search facility considerablly > affrects the internatinalization of IMAP2. If this facility is not > well-designed , IMAP2 can't be multilingual. Konnichi ha - I don't remember if you were at the meeting at NTT-ECL in Musashino with Nojima-san last July, but the upshot of this question was that IMAP2bis does not address any of the questions of expanding the search facility. I was not aware of the international character set problem until it was explained to me at this meeting; I now know and understand the problem quite well. You have my promise that any changes to the search facility in IMAP2 will definitely address this question. Changes to search will probably happen in the next wave of extensions to IMAP2 (IMAP2tres????). I think we'll be starting on that once we get our IMAP2bis implementations up to speed. I did request during the meeting, if NTT would experiment a bit so I can learn from NTT of NTT's experience of what would be a good mechanism for search of kanji. I think that the strings have to be labelled with the character sets (using the same name as the charsets for content-type TEXT), and that for the case of ISO-2022-JP the only comparison that makes sense is to convert both strings to Shift-JIS before comparison (otherwise the ESC codes will be troublesome). Also, you can't use case-independent matching with ISO-2022-JP. -- Mark -- From pinedev@shivax2.cac.washington.edu Thu Sep 3 05:05:05 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07604; Thu, 3 Sep 92 05:05:05 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA18599; Thu, 3 Sep 92 05:02:57 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA18593; Thu, 3 Sep 92 05:02:53 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <27507-0@ppsw1.cam.ac.uk>; Thu, 3 Sep 1992 13:02:24 +0100 Date: Thu, 03 Sep 92 13:02:13 BST From: A Grant To: imap@cac.washington.edu Subject: re: IMAP2 futures? Message-Id: > Most of us consider `mail forwarding' to mean encapsulating the message within > another message. You would be putting user interface and sending within a > message. `Remailing' in this fashion may be reasonable though. X.400 (which I honestly believe that everyone outside the USA will be using in 10, if not 2 years' time) allows optional added body parts for both kinds of what it calls `forwarding'. For auto-forwarding the text is supplied in a management operation, for manual forwarding a new message is submitted with a parameter referring to "a message that is already in the MS which is to be combined with the submitted message body". But I accept that it is possible to define a private protocol for auto-forwarding control, and to fetch and re-send a manually forwarded message. > I'm not convinced that draft messages belong on the IMAP server as opposed to > `home directory' server. What if the IMAP server is overseas (this is a real > world situation for me!)? Putting it in IMAP seems to be false `efficiency'. I wasn't really thinking of efficiency here. Even within a campus, a user may want to send mail from machines that have do not have a common file system, i.e. for which the only interconnectivity is IP. Having their draft messages in a common pool is _added function_; having the draft-message management functions integrated with other parts of the mail protocol simplifies things and may also add function. E.g. IMAP2's SEARCH and FETCH commands are mostly equally applicable to draft messages; it would be duplication of effort to have identical commands in a separate server. IMAP2 is already ideal for managing a message pool. All it needs is some way to insert and update the drafts. > Please consider bringing it up to the IETF-REMMAIL group. Ok. But I hope readers will forgive me for reminding the list that the effort in implementing mail these days is not in designing protocols, but in writing user-friendly Windows and Mac clients. The fact that the PC POP clients still haven't got IMAP2 support suggests that any wonderful new mail protocol from the IETF will be of little use to the average user for a long time yet, _unless_ it extends an existing protocol. And to me, IMAP2 seems the best candidate. (I think I've made my point - time for someone else to have a go!) -- Alasdair Grant A.Grant@ucs.cam.ac.uk MVS Systems Group / Small Systems Integration Group +44 223 334447 University Computing Service +44 223 334679 (fax) Pembroke St., Cambridge CB2 3QG, UK From pinedev@shivax2.cac.washington.edu Thu Sep 3 09:31:55 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA14662; Thu, 3 Sep 92 09:31:55 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA20814; Thu, 3 Sep 92 09:31:50 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from nexus.yorku.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA20804; Thu, 3 Sep 92 09:31:44 -0700 Received: from localhost ([127.0.0.1]) by nexus.yorku.ca with SMTP id <9222>; Thu, 3 Sep 1992 12:31:36 -0400 To: imap@cac.washington.edu Subject: Re: re IMAP2 futures? Date: Thu, 3 Sep 1992 12:31:25 -0400 From: davecb@nexus.yorku.ca Message-Id: <92Sep3.123136edt.9222@nexus.yorku.ca> In you write: [in part of a larger discussion on the server function-set] | However, this is merely `for efficiency' since the same resulting function can | be accomplished by existing mechanisms. This is a good reason to reject it; | any function which by its fundamental nature is optional and exists only for | `efficiency' tends not to get implemented widely. You can either end up with | a lot of protocol baggage or recognize reality. Most modern protocol design | does the latter. I too would argue that little of the added functionality belongs in the imap protocol. It is all too easy to discover you're specifying the transitive closure of all the states of all the subsystems, unless you try quite strongly for separation of concerns. Failing to do so ends up in exponential increase in complexity and implementability. Ie, an unused protocol. In concrete terms, it's a bad idea to add too many things to a protocol because you end up trying to add things which interact in wierd and wonderous ways. For examplem renaming a mailbox can result in the state of the MUA suddenly become inconsistant. If the MUA doen't knows the implications of the operations of the mailbox management system, it can trivially fail, to the detriment of the user. This is already possible in standard IMAP: the imap-using MailManager MUA reports the mysterious shrinking of a mailbox when someone inadvertantly uses /bin/mail. It deals with it reasonably, but has no knowlege of why it happened, and can only report the bare fact. To a non-technical user, this means that mail is unreliable: after all, it disappears without warning! As an example of good practice, ftp quite carefully uses separate streams for commands and data, too keep from having to contain its own multiplexor. If one wants a muliplexor, one uses the one at a lower level in the protocol stack. ( This becomes difficult when talking to very single-threaded machines like PCs and my old CP/M-80 box. If one has multitasking and slip, one has a multiplexor. If one has only uucp or kermit, one hasn't. I once did an application that multiplexed over kermit on a single-task cp/m-80 system. At the client end, the coding was horrid: it really had to be aware of too many things at once.) On a multi-tasking machine I would separate the applications as far as possible, and optionally provide a multiplexor and transport layer **if and only if** I couldn't get an adequate one elswhere. Kermit is pretty easy to multiplex, if you must know. Just don't try to do it on a z80 unless you really like pain. --dave From pinedev@shivax2.cac.washington.edu Thu Sep 3 10:58:12 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA17098; Thu, 3 Sep 92 10:58:12 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21814; Thu, 3 Sep 92 10:58:04 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21808; Thu, 3 Sep 92 10:58:02 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Thu, 3 Sep 92 13:57:56 EDT Received: via switchmail; Thu, 3 Sep 1992 13:57:54 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Thu, 3 Sep 1992 13:56:29 -0400 (EDT) Received: via niftymail; Thu, 3 Sep 1992 13:56:24 -0400 (EDT) Date: Thu, 3 Sep 1992 13:56:23 -0400 (EDT) From: Chris Newman Subject: re: IMAP2 futures? To: imap@cac.washington.edu In-Reply-To: References: Message-Id: <715542983.10477.0@nifty.andrew.cmu.edu> In message , A Grant writes: >I wasn't really thinking of efficiency here. Even within a campus, a user >may want to send mail from machines that have do not have a common file >system, i.e. for which the only interconnectivity is IP. Having their draft >messages in a common pool is _added function_; having the draft-message >management functions integrated with other parts of the mail protocol >simplifies things and may also add function. E.g. IMAP2's SEARCH and FETCH >commands are mostly equally applicable to draft messages; it would be >duplication of effort to have identical commands in a separate server. >IMAP2 is already ideal for managing a message pool. All it needs is some >way to insert and update the drafts. It seems to me that the IMAP2bis "APPEND" command could be used to do what you want. Using a convention that the folder called "drafts" holds draft messages, APPEND could be used to add new or updated drafts, and FETCH/PURGE could be used to get them and delete them. APPEND is completely unsuitable, however, for any sort of mail delivery, as it doesn't provide for an envelope. (I think mail delivery is outside the scope of IMAP2, as there are existing simple protocols to do what is necessary). - Chris Newman Computing Services, Carnegie Mellon University From pinedev@shivax2.cac.washington.edu Thu Sep 3 11:34:28 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA18419; Thu, 3 Sep 92 11:34:28 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22256; Thu, 3 Sep 92 11:34:19 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22250; Thu, 3 Sep 92 11:34:17 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <03515-0@ppsw1.cam.ac.uk>; Thu, 3 Sep 1992 19:34:04 +0100 Date: Thu, 03 Sep 92 19:33:52 BST From: A Grant To: imap@cac.washington.edu Subject: re: IMAP2 futures? Message-Id: In-Reply-To: <715542983.10477.0@nifty.andrew.cmu.edu> > It seems to me that the IMAP2bis "APPEND" command could be used to do > what you want. Using a convention that the folder called "drafts" > holds draft messages, APPEND could be used to add new or updated > drafts, and FETCH/PURGE could be used to get them and delete them. What APPEND command? Has IMAP2bis changed in the last few months? Where is the new draft, please? (I got it out of the imap distribution last time.) > APPEND is completely unsuitable, however, for any sort of mail > delivery, as it doesn't provide for an envelope. (I think mail > delivery is outside the scope of IMAP2, as there are existing simple > protocols to do what is necessary). Nobody is asking for mail delivery, just mail submission. Any system that handles draft messages ought to handle the envelope; a user should not have to set up the envelope each time. In other words, a managed draft message should be able to be "ready for sending". If APPEND is not suitable for mail submission, it will not be suitable for managing draft messages. From pinedev@shivax2.cac.washington.edu Thu Sep 3 12:35:40 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA20043; Thu, 3 Sep 92 12:35:40 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22949; Thu, 3 Sep 92 12:35:32 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from Ikkoku-Kan.Panda.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22943; Thu, 3 Sep 92 12:35: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 AA05011; Thu, 3 Sep 92 12:35:17 PDT Date: Thu, 3 Sep 1992 10:26:13 -0700 (PDT) From: Mark Crispin Subject: Re: re IMAP2 futures? To: IMAP Interest List In-Reply-To: <92Sep3.123136edt.9222@nexus.yorku.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dave makes some excellent points, and I suggest that everyone re-read his message. Separation of concerns is a vital part of engineering. If we don't keep it firmly in mind, we are very likely to end up with another fiasco like the late unlamented `IMAP3', or even worse, the ARPAnet `new FTP' protocol which was official, documented and unimplemented (as opposed to the real FTP protocol which was unofficial and undocumented except in folklore). I have been told that people where pounding the tables at screaming at each other in the FTP meetings... In the past, I followed a set of criteria when evaluating potential changes to IMAP2. I think these criteria are good and should be continued in future IMAP2 development. Loosely stated, these criteria are listed below. Exceptions and violations have existed; these criteria represent an ideal rather than necessarily reality. But, I think the strength of IMAP2 has been due to my having held to (and occasionally fought for) these ideals, and the weaknesses of IMAP have been when these ideals have been violated. 1) All proposed changes must demonstrate a reason for their existance: a) They must demonstrate that they are useful. b') They must demonstrate that they solve a problem that can not be solved by other means. OR b") The `efficiency' gained by the new functionality is such that the cost of requiring duplicate code in all implementations pales compared to the benefit gained. [This is nearly impossible to prove.] Examples: . A function to play a game of Pac-Man violates 1a. ;-) . A function to set newline conventions violates 1a and 1b (long-winded explanation about why this is a terrible idea available on request) and also 3 and 4 below. . A function to do a remote Finger violates 1b (a Finger protocol exists). . A function to transmit 8-bit data violates 1b (IMAP2bis supports MIME and BASE64 decoding on the fly is easy). It may not even be `efficient' to transmit binary, as those of us who compare FTP transfer speeds over V42bis links between binary and text know very well... 2) All proposed changes must demonstrate that they belong in IMAP as opposed to some other protocol; the function must fit within the scope of IMAP. This necessarily implies that a distributed mail system will use multiple protocols; only the most simple and minimal can expect to do everything it needs with one protocol. Example: . A function to change the user's password remotely belongs elsewhere. This is undeniably a useful function and IMAP *MUST* consider proper interaction with more advanced authentication mechanisms, but maintenance of the authentication system is outside the scope of IMAP. 3) All proposed changes must solve the problem they seek to solve, and not create new ones. The road to bad protocol designed is paved with kludges that solve one problem in one limited case. Example: . I believe that putting mail posting capability into a mail access protocol violates this rule (I acknowledge this is still a controversy). The arguments for this are efficiency and authentication. However, it is not efficient if the access server is in another continent (I use IMAP to Japan all the time!). Nor are access credentials equivalent to posting credentials; a number of cases exist where posting is permitted without access (mail hubs), and access without posting (read-only bboards). What is worse, by allowing posting in the mail access protocol, we create clients that only post using the access protocol (since they don't have enough memory to have multiple means of posting) and that closes a number of doors. UW already has a separate mail hub engine from the mail repository, and this would be precluded by such clients. 4) Multiple protocol states should be avoided, and silly states should be avoided like the plague. This is something that repeatedly comes up in protocol design working groups, as yet another group of inexperienced individuals pressures for modal switches and for mechanism to list the capabilities of an implementation. The archives of various working groups are filled with explanations as to why this is terrible design, and I will not belabor the issue here. Note that even a single mode switch or a version command has been well-toasted; MIME has a `version' setting of 1.0, and it highly likely there will never be any other value permitted. Silly states are something that have received a lot of attention recently due to my efforts. A silly state is one which obeys the protocol, but creates a silly situation. Humans generally avoid silly states in their interactions, but computers and bureaucracies create them all the time. An example of a silly state is that created by a server which answers a `what verbs do you support' by dumping its verb table, even though several of those verbs are served by an error message that says the verb is not implemented. In all cases the server is responding reasonably; it *does* know about the verb so it can say `not implemented' instead of `not recognized'. However, a client which makes decisions based upon its perception of what the server can or cannot do will be misled by the verb table dump. The key point to understand here is that no amount of legislation in the protocol specification is going to prevent silly states if the grammar of the protocol permits it. One of the biggest mistakes in MIME was the ban on recursive encoding (encoding of types MESSAGE and MULTIPART) instead of the use of syntax that would make the concept non-existant. The ban is there for excellent reasons -- I lobbied long and hard for it -- but the fact that the grammar permits it has come to haunt us with PEM. 5) Proposed new capabilities should be interoperable with the past. The base level capability of IMAP2 was defined in RFC-1176 (some say RFC-1064) and software implementing that base level is widely distributed. New capabilities should appear as extensions, and it should be clearly understood what should be done if the capability is not supported. The use of new capabilities should be completely under the client's control; a server should never thrust something unexpected upon an unprepared client. New capabilities should be small and have minimal interaction with other new capabilities; and where such interaction exists (e.g. between FIND and SUBSCRIBE) it should be well-documented. It is crucial that both the client and the server completely implement the enter base level, and that a client attempting to use capabilities beyond the base level is able to do so only with a willing server, and that no server should presume that the use of one extended capability by the client implies the existance of support in the client of another extended capability, and that no client should presume that a successful use of an extended capability with a server implies that the server supports another extended capability. 6) It should be reasonable to expect that any new (or existing supported) implementations will implement *ALL* capabilities, both base and extended; that the `optionality' of an extended capability refers to the fact that we don't have to change all the old implementations; and that any capability which is marginal enough that a new implementation would not want to include it should be rejected on those grounds. The fact that a capability, by not being in the base, is `optional' is not license to add a marginal capability on the grounds that it can be ignored. The penalty of disobeying this rule is a protocol filled with unnecessary and unused clutter. 7) Some amount of latitude is allowed when the benefits clearly outweigh the costs. For example, the new mail management capabilities in IMAP provide that service in the very simple case of a single repository. By design, they are completely inadequate for multiple distributed repositories; that is completely outside the scope of IMAP and belongs in a mail management protocol. 8) It is important that any protocol design recognize the realities of the underlying infrastructure. IMAP2 is a byte-stream protocol and as such runs on top of a reliable byte-stream protocol such as TCP. This imposes various constraints that aren't obvious to novices. It is important to recognize that `reliability' implies error correction and especially flow control, that although these seem to be transparent they do have implications in your higher level protocol design. The CCA Datacomputer protocol of ARPAnet days (R.I.P.) should be a textbook example of how failure to recognize flow control considerations can lead to deadlocks. No service on top of a flow-controlled protocol is truly `asynchronous'. The entire reason for UDP's existance is that it permits asynchronous protocols, albeit at the expense of lost reliability. Regards, -- Mark -- From pinedev@shivax2.cac.washington.edu Thu Sep 3 13:38:14 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21622; Thu, 3 Sep 92 13:38:14 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23537; Thu, 3 Sep 92 13:38:08 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from Ikkoku-Kan.Panda.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23531; Thu, 3 Sep 92 13:38:01 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NeXT-1.0 (From Sendmail 5.52)/UW-NDC/Panda Revision: 2.27.MRC ) id AA05032; Thu, 3 Sep 92 13:37:55 PDT Date: Thu, 3 Sep 1992 12:35:29 -0700 (PDT) From: Mark Crispin Subject: re: IMAP2 futures? To: A Grant Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi - I don't share your optimism about `everyone outside the USA using X.400 in 10, if not 2 years'. The market has clearly picked RFC mail over X.400, and that is where the interoperable infrastructure is. The X.400 community has cajoled, exhorted, and even threatened in the past 10 years that they are going to take over the world, and it hasn't happened yet. Some people have said that MIME was the final nail in X.400's coffin; I suspect it will occur when a few more PTT's (particularly Deutsche Bundespost) have their fangs pulled. As my boss is fond of pointing out, one must not limit his perspectives by the tools available to him. The present absence of suitable chisels doesn't mean that it is right to enshine screwdrivers as the tool to chisel. A common filesystem certainly does not exist today; but that does not mean that it may not exist tommorrow. More to the point: IMAP's scope *is* likely to expand, but I am not convinced that it should expand in areas where it currently has no presence. It is one thing to talk about expanding IMAP's distributed information retrieval capabilities to objects other than mail; it is quite another for it to become a distributed manager of user file or environment objects. In the former case, you are expanding the scope of objects under a general category and manipulation that currently exists; in the latter, you are creating new categories of objects and new forms of object manipulation. Your point about the delay in IMAP2 support is well-taken, but it suggests something totally different to me than it does to you. POP had an earlier presence, and it remains substantially simpler than IMAP. Both of these are immense benefits. The present interest in IMAP has come about due to an understanding of the limitations of the POP model. However, the more IMAP `goes off the deep end', the more the simplicity of POP remains the more attractive choice. My source files suggests that the cost of implementing IMAP is about twice that of implementing POP; more accurately, my IMAP server source file is about twice the length of my POP server (30K vs 15K). That's a price to bear, but perhaps not too much given the benefits. We don't want to make that ratio worse. As taxing authorities around the world have discovered, you can get a lot more out of people in small increments taken repeatedly over a long period of time than in massive whallops delivered at once... ;-) -- Mark -- From pinedev@shivax2.cac.washington.edu Fri Sep 4 04:30:36 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA10159; Fri, 4 Sep 92 04:30:36 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29183; Fri, 4 Sep 92 04:26:28 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29177; Fri, 4 Sep 92 04:26:24 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <16420-0@ppsw1.cam.ac.uk>; Fri, 4 Sep 1992 12:26:15 +0100 Date: Fri, 04 Sep 92 12:26:01 BST From: A Grant To: imap@cac.washington.edu Subject: re: IMAP2 futures? Message-Id: In-Reply-To: <715550469.10477.0@nifty.andrew.cmu.edu> Chris Newman @ CMU writes: > IMAP2 is a protocol for remote mailstore access (from what I > understand). Anything which isn't "remote mailstore access" should be > placed in a separate protocol. The idea of placing a message in a > mailstore to be "picked up for delivery" seems like a very backwards > way to do mail submission -- why not contact the transport agent > directly with an appropriate simple protocol (e.g. SMTP)? I'm not suggesting that IMAP2 take over the role of SMTP, just that it provide facilities to (at least) submit the draft messages it manages. If it doesn't have draft message management, there is less reason to support submission. However, integrating retrieval and submission may open the way for extra functions in the future, e.g. marking messages as 'replied-to'. It's what I'd call an 'enabling step' if I was asking my boss to fund it. A lot of people think that 'remote mailstore access' these days means far more than just retrieval. X.400 P7 is IMHO a good _model_ (and believe me, I have read the standards), even if details of the implementation are still flawed. (Half the problem seems to be that people don't understand ASN.1, which is strange, as it is used in a number of Internet protocols.) > I'm used to MUAs that generate the envelope from the headers > automatically Fine. If an IMAP2-managed draft message is 'ready for sending', without user intervention, it makes even less sense to _require_ the MUA to fetch it and submit it. > But then a mailstore isn't suitable for storing of an envelope -- > only for storage of RFC-822 and MIME messages. Why Internet only? My 'mailstore' contains messages from X.400, BITNET, Internet and Greybook hosts. The fact that they are all converted to one format (Greybook) is something that I, as a user, don't need to be aware of. Concrete example: we are looking at providing IMAP2 access to an X.400 message store. I think at least one non-contentious point has come out of this discussion though: that (a) central draft message management is often necessary, and (b) IMAP2, with its SEARCH and FETCH commands and mailbox management, is ideal for draft message management. Would it be possible to have 'DRAFT' and 'SENT' system flags, to be modified only by the IMAP2 server? From pinedev@shivax2.cac.washington.edu Fri Sep 4 09:58:06 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA17975; Fri, 4 Sep 92 09:58:06 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA01819; Fri, 4 Sep 92 09:58:00 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from PO5.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA01813; Fri, 4 Sep 92 09:57:58 -0700 Received: by po5.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Fri, 4 Sep 92 12:57:44 EDT Received: via switchmail; Fri, 4 Sep 1992 12:57:42 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Fri, 4 Sep 1992 12:56:09 -0400 (EDT) Received: via niftymail; Fri, 4 Sep 1992 12:56:05 -0400 (EDT) Date: Fri, 4 Sep 1992 12:56:02 -0400 (EDT) From: Chris Newman Subject: re: IMAP2 futures? To: A Grant , imap@cac.washington.edu In-Reply-To: References: Message-Id: <715625762.1430.0@nifty.andrew.cmu.edu> In message , A Grant writes: >Chris Newman @ CMU writes: >I'm not suggesting that IMAP2 take over the role of SMTP, just that it >provide facilities to (at least) submit the draft messages it manages. Ok, suppose I actually wanted to implement some sort of submission via IMAP. There are a few ways to do this: 1) Put part or all of the mail transport agent (MTA) in the IMAP server. This is clearly a *bad thing* as it makes IMAP many times more complex, and makes it less portable (particularly to places where "standard" mail transport systems aren't used). 2) Have the IMAP server contact the MTA and submit the message itself. This causes the IMAP server to have an external dependancy on another machine/service. At CMU, we've found this to be a *very bad thing*. Our system has so many inter-dependancies that if one thing goes down, it usually takes the whole system with it. Our current design goal for replacement systems it to have each service as independant as possible. 3) Have the MTA pick up the message directly from the mailstore. This requires the MTA to understand the mailstore format(s) and to run on the IMAP server. So this is a *bad thing* as it makes the MTA more complex (and less portable), and makes the IMAP server harder to manage and maintain (particularly at large sites with multiple servers). 4) Have the MTA pick up the messages via IMAP. This requires the MTA to understand IMAP protocol, have a dependancy on the IMAP server, and is probably less efficient than sending the message directly to the MTA from the client. So this is also a *bad thing*. I can't think of any other ways to implement submission via IMAP, and all of these are bad solutions. Since the client needs to understand whatever mail submission protocol (e.g. SMTP) is used anyway, it's best to keep the server simple (as Mark advocates). The tiny cost of fetching a draft message from the server for submission by the client is nothing compared to the damage that adding submission to the IMAP server would cause the protocol's simplicity, portability, and manageability. >If it doesn't have draft message management, there is less reason to support >submission. However, integrating retrieval and submission may open the way >for extra functions in the future, e.g. marking messages as 'replied-to'. >It's what I'd call an 'enabling step' if I was asking my boss to fund it. IMAP already has facilities for flag management in a mailstore. A client which wants such bells and whistles merely needs to set the flags in the server after it submits the mail. There's no need to "integrate" retrieval and submission to get such features. >I think at least one non-contentious point has come out of this discussion >though: that (a) central draft message management is often necessary, and >(b) IMAP2, with its SEARCH and FETCH commands and mailbox management, is >ideal for draft message management. Would it be possible to have 'DRAFT' >and 'SENT' system flags, to be modified only by the IMAP2 server? I would classify draft management as a "nice" feature. Something worth doing only if the implementation is trivial. If draft management can be done using APPEND (and perhaps the existing IMAP flag support), it's worth doing, otherwise I'd prefer keeping the server simple. - Chris Computing Services, Carnegie Mellon University From pinedev@shivax2.cac.washington.edu Fri Sep 4 10:43:26 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19412; Fri, 4 Sep 92 10:43:26 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02429; Fri, 4 Sep 92 10:43:22 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02419; Fri, 4 Sep 92 10:43:20 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <21785-2@ppsw1.cam.ac.uk>; Fri, 4 Sep 1992 18:42:35 +0100 Date: Fri, 04 Sep 92 18:42:25 BST From: A Grant To: imap@cac.washington.edu Subject: Draft messages etc. (was IMAP2 futures) Message-Id: In-Reply-To: <715625762.1430.0@nifty.andrew.cmu.edu> > The tiny cost of > fetching a draft message from the server for submission by the client > is nothing compared to the damage that adding submission to the IMAP > server would cause the protocol's simplicity, portability, and > manageability. As an Australian working in the UK I know that data traffic does not come for free. I can see myself doing IMAP2 from Oz and wanting to forward the messages in my inbox to UK colleagues, based on contents of header fields. Retrieving 10Mb MIME video messages from half way round the world and sending them back again would be gross! I am not convinced the 'damage' is significant. Good application-layer protocols are extensible and modular. If IMAP2 is so hairy that adding an optional submission 'subset' to it involves major surgery, I'm not sure it has a future. Thankfully, I think it _is_ able to be extended nicely. I see that you (implicitly) accept that there may be a need for IMAP2 to manage draft messages. We can't be the only potential IMAP2 users who see transparent distributed file systems as a long way off. Maybe I'm overestimating the problem. I'd really appreciate it if anyone who's using IMAP2 in a large-scale heterogenous environment could share their experiences. From pinedev@shivax2.cac.washington.edu Fri Sep 4 10:51:45 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19637; Fri, 4 Sep 92 10:51:45 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02533; Fri, 4 Sep 92 10:51:41 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from nexus.yorku.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02527; Fri, 4 Sep 92 10:51:39 -0700 Received: from localhost ([127.0.0.1]) by nexus.yorku.ca with SMTP id <9217>; Fri, 4 Sep 1992 13:51:27 -0400 To: A Grant To: imap@cac.washington.edu Subject: Re: Draft messages etc. (was IMAP2 futures) In-Reply-To: Your message of "Fri, 04 Sep 92 13:42:25 EDT." Date: Fri, 4 Sep 1992 13:51:19 -0400 From: davecb@nexus.yorku.ca Message-Id: <92Sep4.135127edt.9217@nexus.yorku.ca> **Any** protocol get hairy when it tries to deal with any two distinct kind of things. SMTP has a serious problem because of the different time-behavior of HELO/RCPT/MAIL/VRFY versus DATA: DATA takes variable and unbounded time. The others take fixed and mutually-predictable times. As a result even simple things get arbitrarily hard easily. (My hack is to read the data part line by line, with timeouts, and make sure every message uses a **separate process**. Otherwise I can lock up all of mail waiting for a single ill-structured message) --dave From pinedev@shivax2.cac.washington.edu Fri Sep 4 12:20:06 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22019; Fri, 4 Sep 92 12:20:06 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03396; Fri, 4 Sep 92 12:19:55 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from Ikkoku-Kan.Panda.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03390; Fri, 4 Sep 92 12:19:48 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NeXT-1.0 (From Sendmail 5.52)/UW-NDC/Panda Revision: 2.27.MRC ) id AA00915; Fri, 4 Sep 92 12:19:42 PDT Date: Fri, 4 Sep 1992 11:57:59 -0700 (PDT) From: Mark Crispin Subject: re: Draft messages etc. (was IMAP2 futures) To: A Grant Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I probably have more experience with international IMAP (and IMAP over slow speed links -- I'm on a SLIP line from my NeXT at home right now) than anyone else. I certainly don't want my drafts sent over the SLIP link to the IMAP server. I have a perfectly good local filesystem for my drafts. Nor do I even want my outgoing mail going to the IMAP server. I have a perfectly good mailer daemon on my machine that can do this pain and suffering in the background. I especially don't want my outgoing mail making two international hops when I am sending domestic mail, just because I happen to be talking to a foreign IMAP server. I'd undoubtably feel differently if my primary machine was my Mac (or a PC) instead of my NeXT. I trust the Mac filesystem much less than the NeXT, and background mailers on a Mac are still more fantasy than reality. Yet, even on the Mac, some of these principles apply. I want my outgoing mail going to a domestic machine regardless of whether or not I am talking to a foreign IMAP server. That's part of the problem -- different individuals in different environments have different needs. How do we solve the needs of one group without causing trouble to other individuals? The problem with adding an `optional submission subset' to IMAP is: . it will make IMAP hairy -- we seek to avoid this . it will create applications which *only* use the `optional' submission mechanism. This is a REAL threat -- the POP world is already filled with POP applications which DO NOT WORK unless the POP server supports the unofficial and undocumented `optional' submission mechanism of Berkeley popper. The bottom line is: `simple solutions' usually create new problems. We're not telling you "no, you can't do what you want"; we're telling you "no, your proposed solution is not the right one." We agree with all your stated needs completely. It just doesn't belong in IMAP. On the other hand, it is undoubtably related to IMAP, and belongs as part of a sister protocol to IMAP. We have already identified Mail Management as one sister protocol. I think that authenticated transport is probably going to be part of a different sister. Let's start thinking about these siblings and not allow IMAP's focus to be blurred. By the way, I think that a good deal of the problem with the 10MB MIME video message forwarding can be solved by appropriate use of external-data in MIME. It seems that people have realized that sending a 1000 person mailing list a 10MB video image, as opposed to a pointer, doesn't scale too well... ;-) So I don't think that example will come up in reality. From pinedev@shivax2.cac.washington.edu Fri Sep 4 14:01:46 1992 -0700 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA24763; Fri, 4 Sep 92 14:01:46 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04449; Fri, 4 Sep 92 14:01:37 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04443; Fri, 4 Sep 92 14:01:34 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <23562-0@ppsw1.cam.ac.uk>; Fri, 4 Sep 1992 22:01:27 +0100 Date: Fri, 04 Sep 92 22:01:14 BST From: A Grant To: imap@cac.washington.edu Subject: re: Draft messages etc. (was IMAP2 futures) Message-Id: In-Reply-To: > I especially don't want my outgoing mail making two international hops > when I am sending domestic mail, just because I happen to be talking to > a foreign IMAP server. Indeed not. But how can you guarantee that the client isn't configured to send its SMTP mail to a relay host in another continent? With some POP-based clients, users are encouraged to carry around a floppy disk (created at their home base) with their draft messages and other user environment, including the address of the SMTP relay host. So there is nothing to prevent redundant international hops even with the SMTP-submission method. Surely, what we should be aiming at is sufficient common sense, in both client and server, to send data from _where it is_, to _the nearest SMTP relay_, _without an intervening hop_. This must include the case where the data is at the server, i.e. when it is a draft message managed by the server. > I'd undoubtably feel differently if my primary machine was my Mac (or a PC) > instead of my NeXT. I think it's this word 'my' that's causing the trouble! Many users will not have a machine which they can call their own. Many people will use computers for little, perhaps nothing, else besides mail. We see mail as a universal resource, like telephones. It must not become merely another luxury for the computer-owning, computer-literate minority. IMAP2, by delegating function to a central server, and reducing whichever computer the user happens to have walked up to to the status of a (rather intelligent) dumb terminal, helps to achieve that goal. But, by requiring the user to know about file systems to manage their draft messages, it does not go the whole way. Please understand that I am not asking (yet) for data-at-the-client to be sent by any other means than ordinary SMTP. (Though there is scope for some interaction with the IMAP2 server, e.g. notifying it that a message in its store has been replied to.) > The problem with adding an `optional submission subset' to IMAP is: > . it will make IMAP hairy -- we seek to avoid this > . it will create applications which *only* use the `optional' submission > mechanism. This is a REAL threat -- the POP world is already filled with > POP applications which DO NOT WORK unless the POP server supports the > unofficial and undocumented `optional' submission mechanism of Berkeley > popper. If clients create unnecessary traffic by forwarding all messages via the server, they deserve to be rejected. But clients which use IMAP2 for draft message management can reasonably expect draft messages at the server to be submitted without having to retrieve them to the (perhaps intercontinental) client. Maybe I should have talked about the `optional draft message management subset' and made it clear that submission from the draft message store is an integral and necessary part of that subset. > On the other hand, it is undoubtably related to IMAP, and belongs as part of a > sister protocol to IMAP. We have already identified Mail Management as one > sister protocol. I think that authenticated transport is probably going to be > part of a different sister. Let's start thinking about these siblings and not > allow IMAP's focus to be blurred. I hope these protocols become a reality. But the closer they are to IMAP2, the better the chance of them being integrated into IMAP2 clients. Is there any chance that these protocols could use the same syntax as IMAP2, as far as possible? For example, if draft message management is a part of these protocols, it would be silly to have analogues of SEARCH and FETCH with different syntaxes. (I am dubious about the value of creating dozens of protocols. Multiplexing two protocol subsets over a single TCP connection is not fundamentally different from using two TCP connections. Relying on an optional subset of one service is not different from relying on an optional service itself. I assume that the 'Mail Management' protocol will talk to the IMAP2 server in some way, so what is gained by separation?) From pinedev@shivax2.cac.washington.edu Fri Sep 25 11:30:23 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19747; Fri, 25 Sep 92 11:30:23 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA17967; Fri, 25 Sep 92 11:30:12 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA17961; Fri, 25 Sep 92 11:30:01 -0700 Received: from scapa.cs.ualberta.ca by scapa.cs.ualberta.ca with UUCP id <42587-1>; Fri, 25 Sep 1992 12:29:30 -0600 Received: by isagate.edm.isac.ca (/¥==/¥ Smail3.1.25.1 #25.2) id ; Fri, 25 Sep 92 11:31 MDT Received: from isasun-3.edm.isac.ca by isasun-1.edm.isac.ca with smtp (Smail3.1.26.7 #1) id m0mYJYt-000cuxC; Fri, 25 Sep 92 11:34 MDT Received: by isasun-3.edm.isac.ca (/¥==/¥ Smail3.1.20.1 #20.1) id ; Fri, 25 Sep 92 11:29 MDT Date: Fri, 25 Sep 1992 11:05:56 -0600 From: Steve Hole Subject: Some general mail message issues To: imap@cac.washington.edu, pine-info@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII None of these are really IMAP or pine issues themselves, but are related - they are general questions concerning the handling of mail messages. 1. Is there a mailing list for the discussion of the MIME message format? I am interested in discussing the howtos on including PEM key information in MIME messages, and want to make sure to ask the *right* people. 2. Who is responsible for the development of the message management protocol? Is there a mailing list for this? What is the status of this effort? This is becoming a real issue for us. The ability to get and configure services like delivery acknowledgement, read acknowledgments, and automatic reply are a high priority for many of our clients - especially when packages like Microsoft mail are able to do it. I know that the architecture is much simpler and not very good for MS Mail - but that is what the users still see. The issue needs to be addressed presently or we are going to find ourselves swamped with proprietary file system based mail systems in user workgroups. 3. Is there a list of "management services" or whatever you want to call them available. The X.400 spec has a list that seems comprehensive enough (watch me burn on that one :-) to use as a base point. Is there an equivalent for Internet mail services? 4. Is there an agreement or description of where services like automatic reply should be provided - in the MTA or the MUA? X.400 specifies the message store (which makes sense), but there is no equivalent in the Internet architecture (I think there should be). 5. There was some mention on work being done to implement lightwieght directory access protocols for getting X.500 information quickly. Could someone point me to these individuals again? This is very important to us as a mechanism for distributing public keys for PEM. ... and specifically for Mark ... 6. Is there a todo list for the c-client? What are the current priorities for the c-client? Thanks all. Cheers. -- Steve Hole Director of Research and Communications ISA Corporation mail: steve@edm.isac.ca Edmonton, Alberta, Canada phone: (403) 420-8081 From pinedev@shivax2.cac.washington.edu Sun Sep 27 14:21:20 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19897; Sun, 27 Sep 92 14:21:20 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA01295; Sun, 27 Sep 92 14:21:07 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from PO5.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA01289; Sun, 27 Sep 92 14:21:03 -0700 Received: by po5.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Sun, 27 Sep 92 17:20:19 EDT Received: via switchmail; Sun, 27 Sep 1992 17:20:17 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Sun, 27 Sep 1992 17:19:58 -0400 (EDT) Received: via niftymail; Sun, 27 Sep 1992 17:19:50 -0400 (EDT) Date: Sun, 27 Sep 1992 17:19:49 -0400 (EDT) From: Chris Newman Subject: Re: Some general mail message issues To: Steve Hole , imap@cac.washington.edu In-Reply-To: References: Message-Id: <717628789.15646.0@nifty.andrew.cmu.edu> Steve Hole writes: >2. Who is responsible for the development of the message management >protocol? Is there a mailing list for this? What is the status of >this effort? The CMU team (John Myers and myself) have agreed to spearhead the design of this protocol. We have just finished our survey of user requirements on campus, and have a final functional requirements document for the mail system we will need here (and a draft design document). I expect us to start design of the protocol in a month or so, and you _might_ see an implementation in a year. The protocol is likely to be very similar to IMAP2bis (probably with some of the same commands for subscriptions & such). > This is becoming a real issue for us. The ability to get and >configure services like delivery acknowledgement, read >acknowledgments, and automatic reply are a high priority for many of >our clients - especially when packages like Microsoft mail are able to >do it. Delivery acknowledgements are useless (the message will bounce if not delivered). Read acknowledgements, and reply are client issues. If by "automatic reply" you mean something like the unix vacation service, we have that rated as "NICE" meaning we'll consider it if we get time (I think putting support for it in either the management protocol or the user directory protocol is reasonable). >4. Is there an agreement or description of where services like >automatic reply should be provided - in the MTA or the MUA? X.400 >specifies the message store (which makes sense), but there is no >equivalent in the Internet architecture (I think there should be). Anything that can go in the MUA should, IMHO. Keeping the MTA & mailstore simple and easy to maintain is very important. Things like vacation replies, and automatic filing of incoming mail will probably be put at the mailstore end of the MTA. >5. There was some mention on work being done to implement >lightwieght directory access protocols for getting X.500 information >quickly. Could someone point me to these individuals again? This is >very important to us as a mechanism for distributing public keys for >PEM. There's a protocol called CSO/ph which we're going to look into. If it's not good enough, we'll design & write our own. - Chris Newman Carnegie Mellon University Computing Services From pinedev@shivax2.cac.washington.edu Mon Sep 28 00:34:47 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25738; Mon, 28 Sep 92 00:34:47 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03437; Mon, 28 Sep 92 00:34:42 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03431; Mon, 28 Sep 92 00:34:38 -0700 Return-Path: Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA04375; Mon, 28 Sep 92 00:34:27 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA01527; Mon, 28 Sep 92 00:34:21 -0700 Date: Mon, 28 Sep 1992 00:23:08 -0700 (PDT) From: Mark Crispin Subject: re: Some general mail message issues To: Steve Hole Cc: IMAP Interest List , pine-info@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 25 Sep 1992 11:05:56 -0600, Steve Hole wrote: > 1. Is there a mailing list for the discussion of the MIME message format? The mailing list for MIME is IETF-822@dimacs.Rutgers.EDU. The issue of integration of PEM with MIME is right now being discussed within an `internal group' of MIME/PEM folks. You can check with Marshall Rose or Einar Stefferud to get a current status. Presently, PEM in MIME is not formally defined yet, so you should not be doing any implementations unless you're prepared to be one of the pioneers with arrows in their backs. I hope that Chris Newman answered questions 2-6 to your satisfaction. > 6. Is there a todo list for the c-client? Yes. It's much longer than I would like it to be. > What are the current priorities for the c-client? The current focus is to get acceptable DOS/Mac clients going and in particular to get PC Pine ready for prime time. I just finished the code to allow local file MIME parsing in DOS without requiring you to have the entire message in memory. We have a DOS local file format driver; pretty much the mail.txt format. None of us are very happy with it; I think we need more of an mh style format, while my boss wants a /usr/spool/mail format. Fortunately, c- client allows you to write as many drivers as you want. I hope to be able to get back to development (I don't consider DOS ports `development') and in particular getting IMAP2bis fully implemented in c- client Real Soon Now. From pinedev@shivax2.cac.washington.edu Mon Sep 28 07:43:50 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA00738; Mon, 28 Sep 92 07:43:50 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA05536; Mon, 28 Sep 92 07:43:43 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA05530; Mon, 28 Sep 92 07:43:41 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03546; Mon, 28 Sep 92 07:43:35 -0700 Date: Mon, 28 Sep 1992 07:37:13 -0700 (PDT) From: Terry Gray Subject: re: Some general mail message issues To: Mark Crispin Cc: Steve Hole , IMAP Interest List , pine-info@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I think we need more of an mh style format, while my boss wants a > /usr/spool/mail format. For the record: what I think I heard your boss say :) is that he wants a Bky format driver for compatibility --so that existing "foreign" mailboxes could be copied and successfully read-- in *addition* to whatever the "driver of choice" turns out to be for PCs. -teg From pinedev@shivax2.cac.washington.edu Mon Sep 28 10:45:05 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04525; Mon, 28 Sep 92 10:45:05 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07909; Mon, 28 Sep 92 10:44:59 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from eco.twg.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07903; Mon, 28 Sep 92 10:44:45 -0700 Received: from LOCAL.eco.twg.com by eco.twg.com (5.65/ECO.m-$Revision: 2.16 $) id AA23537; Mon, 28 Sep 92 13:43:39 -0400 Message-Id: <9209281743.AA23537@eco.twg.com> Received: from navajo.twg.com by apache.twg.com id <18954-0@apache.twg.com>; Mon, 28 Sep 1992 10:31:32 -0700 From: "David Herron" Subject: Re: Re: Some general mail message issues To: Chris Newman Cc: Steve Hole , imap@cac.washington.edu Date: Mon, 28 Sep 92 10:34:43 PDT In-Reply-To: Your message of Sun, 27 Sep 1992 17:19:49 -0400 (EDT).<717628789.15646.0@nifty.andrew.cmu.edu> Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 43 TEXT , 4 TEXT >> This is becoming a real issue for us. The ability to get and >>configure services like delivery acknowledgement, read >>acknowledgments, and automatic reply are a high priority for many of >>our clients - especially when packages like Microsoft mail are able to >>do it. >Delivery acknowledgements are useless (the message will bounce if not >delivered). Read acknowledgements, and reply are client issues. If >by "automatic reply" you mean something like the unix vacation >service, we have that rated as "NICE" meaning we'll consider it if we >get time (I think putting support for it in either the management >protocol or the user directory protocol is reasonable). Delivery acknowledgements are not useless. It is an unfortunately true fact that not all the MTAs on the Internet are robust. This is much less true than in the past, but is still true. If you are sending messages to someone and do not have confidence that they're being delivered (and are getting no response from the recipient), you're in a very frustrating situation. You do not know why s/he isn't responding and may get mad at them when it isn't their fault. With delivery acknowledgements you know when to get mad at them ;-). Is the way these message-store-ish things are implemented an issue? In our product the UA fiddles directly with a PP-style ".mailfilter" file (our MTA is based on PP) in order to configure these kind of services. >>5. There was some mention on work being done to implement >>lightwieght directory access protocols for getting X.500 information >>quickly. Could someone point me to these individuals again? This is >>very important to us as a mechanism for distributing public keys for >>PEM. >There's a protocol called CSO/ph which we're going to look into. If >it's not good enough, we'll design & write our own. There are others, but I don't remember any RFC numbers. In our product we're using one of these protocols and it's nice to be able to pull in addresses from the directory with few hassles. But we're not satisfied with the kinds of requests we can make from the directory, this protocol is heavily geared towards finding *people* and we're wanting to build other products based on the X.500 directory. GREPing through RFC-INDEX.TXT is recommended. The only name which comes to mind is "DIXIE". <- 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 Mon Sep 28 11:01:14 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04932; Mon, 28 Sep 92 11:01:14 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA08159; Mon, 28 Sep 92 11:01:05 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from olive.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA08153; Mon, 28 Sep 92 11:01:04 -0700 Received: by olive.cac.washington.edu (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.21 ) id AA11249; Mon, 28 Sep 92 10:56:25 PDT Date: Mon, 28 Sep 1992 10:47:25 -0700 (PDT) From: Laurence Lundblade Reply-To: Laurence Lundblade Subject: Re: Re: Some general mail message issues To: David Herron Cc: Chris Newman , Steve Hole , imap@cac.washington.edu In-Reply-To: <9209281743.AA23537@eco.twg.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII There was a mailing list to discuss the delivery acknowledgements: ietf-ack@ics.uci.edu. I think it's inactive now, but things got pretty sticky when trying to make it work across all the different things connected on the "greater Internet" (BITNET, VAXMail, MCI Mail, gateways to Microsoft mail....). It seems very possible that with such a system often the mail would arrive, but it's arrival would very often not be acknowledged. At least until there was a standard that we all agreed on. Microsoft mail and such have an advantage (disadvantage as well of course) in that they're closed systems. Right now sendmail has a "Return-Receipt-To:" header that will do this, but no guarantees it will work with anything else! Laurence Lundblade 206-543-5617 lgl@cac.washington.edu Computing and Communications, University of Washington, Seattle On Mon, 28 Sep 1992, David Herron wrote: > Date: Mon, 28 Sep 92 10:34:43 PDT > From: David Herron > To: Chris Newman > Cc: Steve Hole , imap@cac.washington.edu > Subject: Re: Re: Some general mail message issues > > >> This is becoming a real issue for us. The ability to get and > >>configure services like delivery acknowledgement, read > >>acknowledgments, and automatic reply are a high priority for many of > >>our clients - especially when packages like Microsoft mail are able to > >>do it. > >Delivery acknowledgements are useless (the message will bounce if not > >delivered). Read acknowledgements, and reply are client issues. If > >by "automatic reply" you mean something like the unix vacation > >service, we have that rated as "NICE" meaning we'll consider it if we > >get time (I think putting support for it in either the management > >protocol or the user directory protocol is reasonable). > > Delivery acknowledgements are not useless. It is an unfortunately > true fact that not all the MTAs on the Internet are robust. This is > much less true than in the past, but is still true. If you are sending > messages to someone and do not have confidence that they're being > delivered (and are getting no response from the recipient), you're > in a very frustrating situation. You do not know why s/he isn't responding > and may get mad at them when it isn't their fault. With delivery > acknowledgements you know when to get mad at them ;-). > > Is the way these message-store-ish things are implemented an issue? In our > product the UA fiddles directly with a PP-style ".mailfilter" file (our > MTA is based on PP) in order to configure these kind of services. > From pinedev@shivax2.cac.washington.edu Mon Sep 28 12:24:02 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA06890; Mon, 28 Sep 92 12:24:02 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA09315; Mon, 28 Sep 92 12:23:53 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA09309; Mon, 28 Sep 92 12:23:47 -0700 Received: from scapa.cs.ualberta.ca by scapa.cs.ualberta.ca with UUCP id <42394-2>; Mon, 28 Sep 1992 13:23:27 -0600 Received: by isagate.edm.isac.ca (/¥==/¥ Smail3.1.25.1 #25.2) id ; Mon, 28 Sep 92 12:01 MDT Received: from isasun-3.edm.isac.ca by isasun-1.edm.isac.ca with smtp (Smail3.1.26.7 #1) id m0mZPTe-000cuxC; Mon, 28 Sep 92 12:05 MDT Received: by isasun-3.edm.isac.ca (/¥==/¥ Smail3.1.20.1 #20.1) id ; Mon, 28 Sep 92 12:00 MDT Date: Mon, 28 Sep 1992 11:07:51 -0600 From: Steve Hole Subject: Re: Some general mail message issues To: imap@cac.washington.edu In-Reply-To: <717628789.15646.0@nifty.andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 27 Sep 1992, Chris Newman wrote: > Steve Hole writes: > >2. Who is responsible for the development of the message management > >protocol? Is there a mailing list for this? What is the status of > >this effort? > The CMU team (John Myers and myself) have agreed to spearhead the > design of this protocol. We have just finished our survey of user > requirements on campus, and have a final functional requirements > document for the mail system we will need here (and a draft design > document). Would it be possible to have a look at this document? I would be very interested in comparing the requirements of your organization to the requirements of the business and government organizations we do work for. Also, is there a mailing list for discussing these issues - or is the IMAP list a good enough forum? Can I suggest that it would be worthwhile to create or designate a list for such discussions. > I expect us to start design of the protocol in a month or so, and you > _might_ see an implementation in a year. The protocol is likely to be > very similar to IMAP2bis (probably with some of the same commands for > subscriptions & such). Very good! This is pretty much as we expected - it should integrate nicely into the user interfaces. > Delivery acknowledgements are useless (the message will bounce if not > delivered). I used to think so. In fact they would be IF all the MTA's in the world handled bouncing mail correctly. Unfortunately, many MTA's make a habit of returning badly addressed mail to the postmaster (actually MAILER-DAEMON) at the originating site, rather than to the originating user - especially if the mail originated outside the organizational domain. The result of this is that mail often ends up in a postmaster queue that only infrequently gets checked. Now, I understand that the role of the postmaster should be monitored and managed correctly, but the reality for us is that it often is not. In some of networks, we have 50+ departmental workgroups, each with their own mail servers and assigned domain. This is a very nice solution for large hierarchical organizations, but we do find that administrative functions tend to slip. For executive class messages (Very Important Messages VIM :-), even a 15 minute delay on getting the message back if improperly addressed is enough for the executive to complain. I agree that the MTA's should deal with this correctly, and I continue to lobby for policy change within the various development groups (smail, zmail, sendmail), and do enforce it locally. The bottom line is, that delivery acknowledgement would still be beneficial for us, especially when dealing with external organizations. > Read acknowledgements, and reply are client issues. If by "automatic > reply" you mean something like the unix vacation service, we have that > rated as "NICE" meaning we'll consider it if we get time (I think > putting support for it in either the management protocol or the user > directory protocol is reasonable). I agree. > >4. Is there an agreement or description of where services like > >automatic reply should be provided - in the MTA or the MUA? X.400 > >specifies the message store (which makes sense), but there is no > >equivalent in the Internet architecture (I think there should be). > Anything that can go in the MUA should, IMHO. Keeping the MTA & > mailstore simple and easy to maintain is very important. Things like > vacation replies, and automatic filing of incoming mail will probably > be put at the mailstore end of the MTA. That is pretty much how I thought it would go. We have already done some experimentation with smail 3.x drivers to handle automatic reply, and new mail notification - it already handles forwarding. > >5. There was some mention on work being done to implement > >lightwieght directory access protocols for getting X.500 information > >quickly. Could someone point me to these individuals again? This is > >very important to us as a mechanism for distributing public keys for > >PEM. > There's a protocol called CSO/ph which we're going to look into. If > it's not good enough, we'll design & write our own. Is CSO/ph an OSI compliant protocol, or some new creation for an Internet only Directory service? I know that Andrew has its own directory service which appears to be quite serviceable - is this what you are talking about? 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 Mon Sep 28 12:24:14 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA06905; Mon, 28 Sep 92 12:24:14 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA09333; Mon, 28 Sep 92 12:24:10 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA09319; Mon, 28 Sep 92 12:24:03 -0700 Received: from scapa.cs.ualberta.ca by scapa.cs.ualberta.ca with UUCP id <42397-2>; Mon, 28 Sep 1992 13:23:31 -0600 Received: by isagate.edm.isac.ca (/¥==/¥ Smail3.1.25.1 #25.2) id ; Mon, 28 Sep 92 13:06 MDT Received: from isasun-3.edm.isac.ca by isasun-1.edm.isac.ca with smtp (Smail3.1.26.7 #1) id m0mZQUl-000cuxC; Mon, 28 Sep 92 13:10 MDT Received: by isasun-3.edm.isac.ca (/¥==/¥ Smail3.1.20.1 #20.1) id ; Mon, 28 Sep 92 13:06 MDT Date: Mon, 28 Sep 1992 12:40:44 -0600 From: Steve Hole Subject: Re: Re: Some general mail message issues To: David Herron Cc: imap@cac.washington.edu In-Reply-To: <9209281743.AA23537@eco.twg.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 28 Sep 1992, David Herron wrote: > Is the way these message-store-ish things are implemented an issue? In our > product the UA fiddles directly with a PP-style ".mailfilter" file (our > MTA is based on PP) in order to configure these kind of services. It may be depending on how and what the scope and mandate of the "mail management protocol" is. One thing that I do not like about the current run of MTA's and MUA's is that they all depend on host based authentication and configuration. I don't think that it should be necessary for a user to have an account on the host that the message store resides on to hold configuration information for the MUA or MTA. Would it not be far better for this type of information to be held either in the message store, or (better) a distributed network service? Actually, this raises some more interesting questions. 1. What types of things will the mail management protocol manage? What will be its mandate? To me it (1) must be able to manage folders (manage the message store), and (2) configure message services like those that we have talked about. Is this correct - is there more? 2. Where will the static user configuration information reside? In some sort of directory service? -- 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 Mon Sep 28 12:49:25 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07377; Mon, 28 Sep 92 12:49:25 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA09591; Mon, 28 Sep 92 12:49:17 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA09585; Mon, 28 Sep 92 12:49:11 -0700 Return-Path: Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA04671; Mon, 28 Sep 92 12:48:54 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA01242; Mon, 28 Sep 92 12:48:44 -0700 Date: Mon, 28 Sep 1992 12:21:48 -0700 (PDT) From: Mark Crispin Subject: Re: Re: Some general mail message issues To: David Herron Cc: Chris Newman , Steve Hole , imap@cac.washington.edu In-Reply-To: <9209281743.AA23537@eco.twg.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Delivery acknowledgements and read acknowledgements are, as has been exhibited, a very emotional issue. They question generates a lot of heat but very little light. Extreme views proliferate, with very little moderation in between. One such extreme view -- which I subscribe to -- is that the privacy violation of this sort of function is of greater concern than the benefits. I do not necessarily want to acknowledge certain messages, much less tell someone if and when I read it. One frightening thought is the prospect of service of legal process through e-mail. The possibility also exists of covert channels; remember, you can get more information out of an acknowledgement than just the fact that the message was received. Delivery acknowledgements aren't as serious in their violation of privacy, but they don't verify that the user read the message. A lot can happen to a message between the time that the MTA delivers it and it is displayed on a screen. There is a privacy violation question as well; it makes it more difficult for a user to ignore mail and pretend it never reached him. My personal viewpoint is that the only acceptable solution is a client-based read acknowledgement, *under the control of the user*. That is, a slightly more automated mechanism than the message with a first line saying `please acknowledge receipt immediately.' Some cookie in the message triggers this in the client, and the user is asked whether or not he wants an acknowledgement sent. Of course, what an organization does in its INTERNAL mail infrastructure is its own business, and it is reasonable for e-mail implementors to provide this facility for internal usage. External usage is another matter. As frustrating as it may be for Joe Mooch at Foobar Corporation not to know if Nancy Nebbish at Garply Industries has received his message, ultimately, it is up to Nancy (and Garply) to decide if an acknowledgement -- or a reply -- should be made, and software should not subvert this. From pinedev@shivax2.cac.washington.edu Mon Sep 28 13:15:47 1992 -0700 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA08031; Mon, 28 Sep 92 13:15:47 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA09887; Mon, 28 Sep 92 13:15:42 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA09881; Mon, 28 Sep 92 13:15:40 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Mon, 28 Sep 92 16:04:10 EDT Received: via switchmail; Mon, 28 Sep 1992 16:04:09 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 28 Sep 1992 16:03:12 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 28 Sep 1992 16:03:05 -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, 28 Sep 1992 16:03:05 -0400 (EDT) Message-Id: Date: Mon, 28 Sep 1992 16:03:05 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: CMU functional requirements document In-Reply-To: References: Beak: is Not For those interested, this is the functional requirements document that CMU has for our next-generation mail system. Some of the features listed herein are inside the domain of IMAP, some are not. ------------------------------ Andrew II Mail Functional Requirements Sep 15, 1992 * Introduction This document describes the functional requirements of the Andrew II Electronic Mail project. The purpose of the project is to provide an electronic mail system for users who use the Andrew system and any other organizational computing facility on campus that desires to use it. Our experience with the Andrew Mail System has shown a number of problems with its design, leading to problems with performance and difficulty in administration. This project will attempt to implement a replacement mail system which corrects many of these problems. The Andrew Mail System has many useful features not found in other mail systems. Some of these features are important to the user community, others are of dubious value. Determining which features of the Andrew Mail System are important and reimplementing them in the new mail system is an important part of this project. * Organization The remainder of this document contains three sections, requirements for functions to be provided to users, requirements for functions to be provided to administrators, and design constraints. Each listed feature is given a priority. Design, resource, and performance constraints will most likely prohibit implementation of all features. The priorities are: Required - The Andrew II mail system must have this feature Highly desired - The mail system should have this feature unless it would be overly expensive to implement. Nice - The mail system should have this feature if it is easy to implement. Low priority - No real effort will be put into providing this feature * User requirements It is REQUIRED that there exist at least one user client for each of the X based workstation, Unix terminal, Mac, and PC environments. For all of them to have the same or similar user interface is HIGHLY DESIRED. Subject to the constraint that they be consistent across platforms, user clients should conform to the user interface guidelines of their respective platforms. (Our users span the various platforms. Several of them move from platform to platform. Consistency across platforms will improve training.) Ability to manage folders is REQUIRED. (Many users depend on ability to classify messages). The ability to optionally store folders on local media is HIGHLY DESIRED. Some form of subscription/"master update" service is REQUIRED. The ability for the service to maintain the read/unread state for each message in a folder is HIGHLY DESIRED. (system needs to keep track of which bboards the user is interested in. "master update" service tells which of user's subscribed folders have new messages--is necessary in order to keep performance acceptable. While AMS' "quit here" line is sufficient for recording what messages in a folder a user has read, keeping read/unread state per message allows users to read the messages in a bboard in a more presentable order. For example, they could read all messages with a given subject before moving to messages with a different subject.) The ability to search within a folder by subject and/or sender is REQUIRED. The ability to do other searches would be NICE. For searches by subject, sender, etc to search the entire field (instead of truncating to a fixed number of characters) is HIGHLY DESIRED. The ability to send and receive files as enclosures is REQUIRED. Full, generalized multimedia support would be NICE. If provided, multimedia support should be done through the MIME standard. Support for local and/or remote printing of messages is REQUIRED. The system is REQUIRED to not drop mail, short of hardware failures. (Once submitted, mail must either be delivered to the recipient(s) or, if that is not possible, returned back to the sender. Losing data for frivolous reasons (network outage, resource shortages, server unavailability) is unacceptable.) Authenticated delivery of local mail is REQUIRED. This is a feature of AMDS that is expected by users. Not only does it protect against users being mislead by forged mail, it allows mail-based services like EzFax and restricted-posting bboards to work. (If mail system cannot be assured that mail claiming to be sent from a local user was in fact sent from that account, it must indicate it as such. The delivery system is allowed to lose this assurance under adverse conditions.) A directory service of users which supports "fuzzy matching" name lookups is REQUIRED. Users are used to the features of the White Pages facility of AMDS and some equivalent is necessary. Some User-settable forwarding address facility is REQUIRED. The ability for changes to take effect immediately is HIGHLY DESIRED. In order to support beta-testing and a smooth transition from AMS/AMDS, a per-user "Leap of Faith" style phase-in mechanism is REQUIRED. (Users must be able to specify that they wish to use the new mail system instead of AMS. This transition need not be reversible. At some point, this transition may be forced upon users.) The "integrated Mail and Bboards" concept is HIGHLY DESIRED. A method for notification of new mail for a user is HIGHLY DESIRED. Zephyr is the most likely notification mechanism. (Users like to know when new mail arrives.) The ability to keep copies of all outgoing messages is HIGHLY DESIRED. The ability to perform well for mail-only users is HIGHLY DESIRED. If user doesn't read bboards, they shouldn't take any performance hit imposed by the bboard system. (There is a large number of users who only use mail) The ability to do archival and/or compression of old messages is HIGHLY DESIRED. A uniform bboard addressing scheme (for example, being able to post to any bboard by addressing mail to "bb+nameofbboard") is HIGHLY DESIRED. The .MS.DirectPost facility of AMS has proven to be confusing to users. Per-user mail aliases (address books) are HIGHLY DESIRED. The user's address book should be available regardless of the location or platform being used. Support for user-created/maintained distribution lists is HIGHLY DESIRED. The ability to have restricted-sending distribution lists would be NICE. Support for a user-defined portion of the address namespace (userid+whatever) is HIGHLY DESIRED. (This is an invaluable aid to users who do automated filing of incoming mail.) Some form of automatic filing mechanism for user's mail is HIGHLY DESIRED. Duplicate delivery elimination (by examining the message-id header) is HIGHLY DESIRED. Sometimes a message from an external system is delivered twice. AMDS currently avoids delivering the excess copies. The ability to eliminate the multiple presentation of messages that have been crossposted (by tracking the message-id field) would be NICE. (When a message is crossposted, it should only be presented to the user once.) Support for threading would be NICE. (Threaded readers group messages that are replies to the same post together, allowing users to read all messages in the same conversation together) Support for "kill files" would be NICE. (Kill files allow users to specify that they want to ignore messages on a bboard with, for example, a given subject or from a specific poster. They are an aid to reading large volume bboards.) Support for subscription invitations would be NICE. (These are messages that cause the client to be prompted to subscribe to a given folder.) An equivalent to the standard Unix "vacation" facility would be NICE. (User can configure their account to inform users that send them mail that they are unavailable for a certain time.) Support for direct delivery to folders would be NICE. (One mechanism for supporting private bboards) Support for requesting a return receipt would be NICE. (A return receipt is an automatically generated message that notifies the sender of a piece of mail that the mail was successfully delivered to the recipient.) Explicit support for delivery of mail to a user's workstation is LOW PRIORITY. There are problems administrating a system which relies on components that the computing facility has no administrative control over. It is extremely difficult to make such a system reliable. Equivalents to AMDS' dir-insert, fs-members, and file-append features are LOW PRIORITY. (These features are infrequently used.) Direct support of X.400 is LOW PRIORITY. The address syntax is unwieldy and there are several technical show-stoppers, such as the fact that an X.400 Message Transport Agent is allowed to silently discard messages due to "congestion". The ability to support "votes" is LOW PRIORITY. (This is a feature of dubious value.) * Administrative requirements Enforcement of disk space quotas is REQUIRED. (Administrators need to have control over resources and be able to avoid abuse of the mail system as additional storage.) Support for global mail aliases and mailing lists is REQUIRED. (Mail aliases and published mailing lists are frequently used.) The ability to efficiently handle large, frequently read bboards is REQUIRED. (We have several such bboards.) The ability to have bboards with restricted reading is REQUIRED. (Organizations use bboards for internal discussions which they do not want to be available to outside users.) Some form of BBoard filing mechanism is REQUIRED. (This is necessary in order to have bboards.) The ability for the bboard filing mechanism to enforce restricted posting to bboards is REQUIRED. The ability for it to be general enough to handle special setups, such as advisor, is HIGHLY DESIRED. (Enforcement of restricted-posting bboards is necessary in order to support "official" and other moderated-style forums. If the filing mechanism isn't general enough to handle such setups as advisor, special-purpose programs to handle this can be written.) A mechanism to handle administration of bboards (manipulate ACLs, create, delete, etc.) is REQUIRED. The ability for parts of this administration to be distributed to outside groups is HIGHLY DESIRED. (The bboard system needs to be maintained in some manner. If this maintenance can be distributed, this reduces the load on the central maintainers and allows outside groups to be given greater flexibility within their own part of the bboard system.) The ability to distribute the bboards across servers is REQUIRED. (The client must therefore have some mechanism for finding the server(s) for a given bboard. Distribution of bboards is necessary in order to handle a large load.) The ability to distribute users across servers is REQUIRED. (This is necessary in order to handle large numbers of users) The ability to move users and bboard trees between servers (in order to load-balance) is REQUIRED. The ability to purge bboards at administratively defined rates is REQUIRED. (Old messages have to be removed at some point. The rates at which bboards are purged need to be adjustable in order to allow for variations in resource usage and importance.) Monitoring of centrally maintained resources is REQUIRED. Usage and resource monitoring of other parts of the mail system is HIGHLY DESIRED. (Administrators need to do resource planning, budget justification, detection and diagnosis of problems.) The ability to "Short Circuit" local delivery of mail, to both andrew.cmu.edu and to CMU.EDU is HIGHLY DESIRED. This is expected to increase the performance and reliability of the delivery system significantly. (For example, both Andrew and CS