From fair@apple.com Mon Feb 6 13:27:49 1989 Received: by CHARON.MIT.EDU (5.45/4.7) id AA08834; Mon, 6 Feb 89 13:27:44 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA22491; Mon, 6 Feb 89 13:27:39 EST Received: by apple.com (5.59/25-eef) id AA23402; Mon, 6 Feb 89 10:27:08 PST From: "Erik E. Fair" (Your Friendly Postmaster) Subject: Re: TCP/IP & Mail systems on Macs. In-Reply-To: <8902061717.AA08452@CHARON.MIT.EDU> To: srz@ATHENA.MIT.EDU X-Return-Path: srz@athena.MIT.EDU Date: Mon, 06 Feb 89 10:27:07 -0800 Message-Id: <23399.602792827@apple.com> Sender: fair@apple.com Status: RO No, but I think it's available to developers. It's called MacTCP, and it is a driver that drops into your system folder. The contact on this end is John Veizades . Erik E. Fair apple!fair fair@apple.com From maas@jessica.Stanford.EDU Mon Feb 6 14:29:12 1989 Received: by CHARON.MIT.EDU (5.45/4.7) id AA09273; Mon, 6 Feb 89 14:29:08 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA24129; Mon, 6 Feb 89 14:25:48 EST Message-Id: <8902061925.AA24129@ATHENA.MIT.EDU> Received: by jessica.Stanford.EDU; Mon, 6 Feb 89 11:25:07 PST Date: 6 Feb 1989 1125-PST (Monday) From: andy maas To: srz@ATHENA.MIT.EDU Cc: Subject: Re: SLIP In-Reply-To: Msg from srz@athena.MIT.EDU dated Mon, 6 Feb 89 12:10:21 EST. <8902061710.AA08398@CHARON.MIT.EDU> Status: RO Oops, sorry. I just TARed CProjects/Custom dir that has SLIP and put it in anonymous FTP Ahwahnee.stanford.edu:pub/macip/custom.tar. "dir" and "ls" won't show you anything but the file is actually there. Andy From henry@GARP.MIT.EDU Wed Jul 19 17:20:10 1989 Received: from ATHENA.MIT.EDU by CHARON.MIT.EDU with SMTP id AA09631; Wed, 19 Jul 89 17:20:04 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA20789; Wed, 19 Jul 89 17:19:47 EDT Received: by GARP.MIT.EDU with sendmail-5.61/4.7 id ; Wed, 19 Jul 89 17:19:40 -0400 Date: Wed, 19 Jul 89 17:19:40 -0400 From: henry@GARP.MIT.EDU (Henry Mensch) Message-Id: <8907192119.AA00958@GARP.MIT.EDU> To: srz@ATHENA.MIT.EDU Cc: hoffmann@ATHENA.MIT.EDU Subject: mac hypercard pop client Reply-To: henry@GARP.MIT.EDU Status: RO "In addition, a POP client based on HyperCard for the Macintosh is being developed at the University of Michigan; currently their software is in a test stage. More information can be had from: Farhad Anklesaria Microcomputer and Workstation Networks Research Group Universiity of Minnesota Minneapolis, MN USA fxa@@berlin.acss.umn.edu From hoffmann@EAGLE.MIT.EDU Wed Aug 16 19:35:37 1989 Received: from EAGLE.MIT.EDU by CHARON.MIT.EDU with SMTP id AA02285; Wed, 16 Aug 89 19:35:30 EDT Received: from NET-MAC-1.MIT.EDU by EAGLE.MIT.EDU with SMTP id AA02199; Wed, 16 Aug 89 19:35:09 EDT Date: Wed, 16 Aug 89 19:35:09 EDT From: hoffmann@EAGLE.MIT.EDU (Ron M. Hoffmann) Message-Id: <8908162335.AA02199@EAGLE.MIT.EDU> To: srz@CHARON.MIT.EDU Subject: Another TechMail bug, refiling Cc: hoffmann@EAGLE.MIT.EDU Status: RO Sequence: Read a message, delete it but don't close the summary window. Now refile the message which you just marked for deletion to another mail file; I used the inbox. Now try to delete the refiled copy. It can't be removed. It has the grayed out appearance in the new mail file summary but won't go away after closing the window. Reopening it show the message still there. -Ron From srz@EAGLE.MIT.EDU Mon Aug 7 23:27:42 1989 Received: from EAGLE.MIT.EDU by CHARON.MIT.EDU with SMTP id AA04797; Mon, 7 Aug 89 23:27:37 EDT Received: from RING4.MIT.EDU by EAGLE.MIT.EDU with SMTP id AA20387; Mon, 7 Aug 89 23:27:19 EDT Date: Mon, 7 Aug 89 23:27:19 EDT Message-Id: <8908080327.AA20387@EAGLE.MIT.EDU> From: srz@EAGLE.MIT.EDU To: hoffmann@EAGLE.MIT.EDU, mlc@EAGLE.MIT.EDU Subject: Questions to be resolved about TechMail Cc: srz@EAGLE.MIT.EDU, srz@CHARON.MIT.EDU Status: RO I've come up with a list of features that need to be added to Techmail for the August 24th deadline. In the process, I have identified some questions/issues that need to be resolved. Presumably the specs that Mark has given Ron will help, but I just want to mention the ones that I've thought about. 1) Customization. What will the customization screen look like? What parameters will users allow to change? The more detail I get the getter. 2) Help file. I am assuming a simple text window, with a scroll bar. Will users be allowed to edit (add/cut/paste/clear) things from this window? Where will the name of the help file be? What folder will it be. 3) How do you want header lines to work on the "New msg" window? (for lines that wrap). 4) What will the Hold button do in the "New msg" window? 5) What will the address book look like? (I don't think it's fully spec'd out yet, although Mark's written proposal is a good start). 6) Inserting file: If the file is too large, we will simply "attach" it to the message. Are multiple "attach"'s allowed? Will the order be maintained? Will attach's be displayed somehow? Editted? 7) How do users change fonts in the different windows? Well, that's it for now. -stan P.S. (This message sent via TechMail). From srz Mon Aug 21 23:11:17 1989 Received: by CHARON.MIT.EDU id AA21469; Mon, 21 Aug 89 23:11:06 EDT Date: Mon, 21 Aug 89 23:11:06 EDT From: srz@CHARON.MIT.EDU (Stanley R Zanarotti) Message-Id: <8908220311.AA21469@CHARON.MIT.EDU> To: hoffmann@CHARON.MIT.EDU Subject: Preferences screens Cc: srz@CHARON.MIT.EDU Status: RO The stuff looks good, but I think there are some choices that are missing. Things to think about: Fcc & Bcc appearing automatically when sending messages. Replying behavior. Reply all recipients, or only From. Fill column? Or do we just fill to the window width, like we are doing now? Long headers versus short headers. Font size preference. 9pt vs 12pt. I think the username should be the top field in the dialog (it's not optional, while Real Name is). Also, do we want a Back... button to go from the second to the first dialog? -stan From hoffmann@BITSY.MIT.EDU Thu Jul 27 20:45:09 1989 Received: from ATHENA.MIT.EDU by CHARON.MIT.EDU with SMTP id AA09983; Thu, 27 Jul 89 20:45:01 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA26259; Thu, 27 Jul 89 20:44:53 EDT Received: from PADDINGTON.MIT.EDU by BITSY.MIT.EDU with SMTP id AA01509; Thu, 27 Jul 89 19:44:48 EST From: hoffmann@BITSY.MIT.EDU (Ron M. Hoffmann) Received: by PADDINGTON.MIT.EDU (5.61/4.7) id AA03620; Thu, 27 Jul 89 20:44:42 -0400 Date: Thu, 27 Jul 89 20:44:42 -0400 Message-Id: <8907280044.AA03620@PADDINGTON.MIT.EDU> To: srz@ATHENA.MIT.EDU, cec@DELPHI.MIT.EDU, mlc@EAGLE.MIT.EDU Subject: [fxa@BOOMBOX.MICRO.UMN.EDU: Re: HyperCard POP client] Status: RO The following received in response to a query from me: Date: Thu, 27 Jul 89 18:22:26 CDT From: Farhad Anklesaria Subject: Re: HyperCard POP client > Hello, I work at MIT in the Network Group. We have been > doing some Macintosh development work of network client > software on top of MacTCP. > > We are currently being frustrated by the unavailability of > the MacTCP HyperCard toolkit which according to it's developer > is supposed to be available now. So much for networking > within Apple! > > I wonder what info you can give me on the work you are doing > and how you are talking IP (if you are...) from HyperCard. > Hi Ron: Sorry for not replying earlier. Yes we are talking to IP. Yes we are doing it from HyperCard. We just released it. No we do not have the MacTCP HyperCard toolkit. The posting we made to usenet follows.... Hope this helps.... E-mail me for further questions... F. ------- We recently finished developing and testing a HyperCard stack that acts as a POP (Post Office Protocol) e-mail client for the Macintosh. The stack is called POPmail and uses Apple's MacTCP drivers to send and recieve SMTP e-mail by talking to a POP2 server. With the POPmail stack, Macintosh users connected to an Ethernet network (either directly or via a fastpath or gatorbox) can send and recieve E-mail from people elsewhere on the Internet. The POPmail stack hides the complexity of standard mainframe environment so non-technical users are comforatable using SMTP mail. In fact, we are using POPmail to provide e-mail access for the top 50 administrators (deans, provost, vice presidents, president) at the University of Minnesota. The idea behind POP is that a machine which is running all the time and is well connected (such as a Unix host) can act as a post office for people with accounts on the machine. The POP server holds mail until a user connects to the POP server. When the user connects to the server, he fetches his mail and then reads it on his machine. Because the POP client need only connect to the POP server for a few seconds to fetch his mail, POP does not consume a lot of resources on the POP server, so it is very possible to use a small Unix workstation as a server for 50 - 100 users. To run the basic POPmail stack you need a 1MB Mac. If you wish to be notified when new mail arrives at the mail server, you will need enough memory to run HyperCard under MultiFinder (ie more than 1MB). The POPmail HyperCard stack works with standard POP2 servers as well as an extended POP2 server we developed. We weren't happy with the standard POP2 server because when it validates a user, the user's name and password are sent over the network in cleartext. We added DES encryption of the username and password. So... users of the POPmail stack don't ever have their usernames and passwords sent over the net in the clear. We are currently running this extended POP2 server daemon on our SUN workstations, a NeXT computer, and on Mac IIs running Apple's A/UX implementation of Unix. While the software is done, we are still working on the manual... a preliminary manual is available now with the software. The final version of the manual will be done sometime next week. If you are interested in the POPmail HyperCard stack for the Macintosh or the extended POP2 server daemon, you can retrieve them by anonymous ftp from the directory pub/POPmail on boombox.micro.umn.edu [128.101.95.95]. Our site license does not permit us to distribute Apple's MacTCP drivers outside of the University of Minnesota. Consequently, you will have to obtain the drivers yourself to run the POPmail stack. Apple will be happy to set you up with a site license. You can get a single user copy of the MacTCP drivers from APDA. George Gonzalez grg@boombox.micro.umn.edu Farhad Anklesaria fxa@boombox.micro.umn.edu Mark McCahill mpm@boombox.micro.umn.edu Microcomputer & Workstation Networks Center University of Minnesota From WADE@EAGLE.MIT.EDU Tue Aug 22 11:02:03 1989 Received: from ATHENA.MIT.EDU by CHARON.MIT.EDU with SMTP id AA23419; Tue, 22 Aug 89 11:01:56 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA01379; Tue, 22 Aug 89 11:01:58 EDT Received: from ISVP-5.MIT.EDU by EAGLE.MIT.EDU with SMTP id AA04743; Tue, 22 Aug 89 11:01:42 EDT Date: Tue, 22 Aug 89 11:01:42 EDT From: WADE@EAGLE.MIT.EDU (S. Wade Neiterman) Message-Id: <8908221501.AA04743@EAGLE.MIT.EDU> To: SRZ@ATHENA.MIT.EDU Cc: Subject: Status: RO Hello Stan, About a month ago, you gave me a copy of NET_STUFF.C (with finger and E-mail) test applications. I have used the routines in NET_STUFF.C and it seems to be working well after I switched from using THINKC to MPW. I have two questions: 1. I can not get the name resolution to work. I don't know if it has something to do with the MacTCP configuration, the hosts file, or something I am not doing in my application. I get a return error from name_resolver of 23044. 2. I have ended up evaluating each byte read from the socket to determine when the end of the sending stream has occured. It seems that the mac client does not read the same number of bytes sent by the BSD4.3 server. Does this sound strange? I know that you are close to completion on TECH mail. If you have made enhancements to NET_STUFF.C that would effect my application (which uses tcp open, send and get routines), maybee I could pick up a new version. Thanks for you help, Steven Neiterman AST E32-133 3-3955 WADE@EAGLE From hoffmann@BITSY.MIT.EDU Thu Aug 24 10:38:47 1989 Received: from BITSY.MIT.EDU by CHARON.MIT.EDU with SMTP id AA02491; Thu, 24 Aug 89 10:38:40 EDT Received: from PADDINGTON.MIT.EDU by BITSY.MIT.EDU with SMTP id AA02553; Thu, 24 Aug 89 09:38:35 EST From: hoffmann@BITSY.MIT.EDU (Ron M. Hoffmann) Received: by PADDINGTON.MIT.EDU (5.61/4.7) id AA21033; Thu, 24 Aug 89 10:38:29 -0400 Date: Thu, 24 Aug 89 10:38:29 -0400 Message-Id: <8908241438.AA21033@PADDINGTON.MIT.EDU> To: srz@CHARON.MIT.EDU Subject: [mlc@EAGLE.MIT.EDU: Apple development info available via FTP] Status: RO FYI... -Ron =================== Date: Thu, 24 Aug 89 10:27:13 EDT From: mlc@EAGLE.MIT.EDU (Mark Curby) To: netserv@MIT.EDU Cc: Subject: Apple development info available via FTP fyi - mark -----Forwarded message----- Date: Thu, 24 Aug 89 09:42:45 EDT From: caia@EAGLE.MIT.EDU Message-Id: <8908241342.AA09352@EAGLE.MIT.EDU> To: caia@EAGLE.MIT.EDU, jackson@EAGLE.MIT.EDU, jwl@EAGLE.MIT.EDU, mlc@EAGLE.MIT.EDU, mlwiese@EAGLE.MIT.EDU Cc: Subject: Apple Developer Technical Support -- excerpt from Info-Mac Digest Date: Thu, 13 Jul 89 06:27:03 PDT From: Mark B. Johnson Subject: Apple FTP Now Available Apple Developer Technical Support is proud to offer a new service to the Apple II and Macintosh development communities: Anonymous FTP to an Apple Internet host loaded with the most up-to-date DTS tools and documentation available. FTP is the user interface to the ARPANET standard File Transfer Protocol, and it allows you to transfer files to and from a remote network site. To access and retrieve files from the Apple archive, you should FTP to apple.apple.com (130.43.2.2) using account:anonymous and password:guest. Once you logon, change directories to pub/dts/ (cd pub/dts/) and get the README file (get README) which explains the archive content and structure. If you are unfamiliar with FTP or do not know if you site supports it, use your on-line help or check with your local site administrator. You will always find the most current Technical Notes and Sample Code posted in the dts/ directory, as well as other documents or materials relevant to development on an Apple platform. Look in the help/ directory for a current list of all the archived files (dir-yy-mm-dd) and a list of the most recent additions (recent-yy-mm-dd). The following is a basic outline of the directory structure and the contents of the archive: README - General info about content and structure aii - Apple II information tn - Apple II Technical Notes ftn - Apple II File Type Notes sc - Apple II Sample Code help - Helpful info about these directories dir-YY-MM-DD - Directory of all files in the dts/ directory recent-YY-MM-DD - Directory of all files added within 14 days mac - Macintosh information docs - Macintosh Technical Documentation hacks - Useful, unsupported hacks mpw - Current MPW Interface files q+a - Macintosh Q & A Stack sc - Macintosh Sample Code sys.soft - System Software information tn - Macintosh Technical Notes press - Apple Press Releases Tools and utilities sold by APDA (e.g., ResEdit, etc.) are not available from this archive due to licensing restrictions. In the future, if we can make these sorts of tools available and still please our attorneys, we will. This service is long overdue, and we thank the many volunteers on the networks who maintain other archives and make Apple's tools and documentation available to the masses. If you normally get your files from these other sites, you should be able to continue doing so, as we are working with these people to make sure that their files are updated on a much more timely basis than in the past. This archive site is just a small effort in Apple's attempts to provide our developers with the best tools and developer technical support in the industry, and we are very interested in your feedback. Please send comments and suggestions to us at one of the addresses listed below. Thanks for your suggestions and patience in making this archive site reality. Special thanks to Erik Fair of Apple Engineering Computer Operations; Lance Nakata, Bill Lipa, and Jon Pugh of Info-Mac and SUMEX; and Werner Uhrig of the University of Texas. Mark B. Johnson Developer Technical Support domain: mjohnson@apple.com UUCP: {amdahl,decwrl,sun,unisoft}!apple!mjohnson AppleLink: mjohnson USMail: Developer Technical Support Apple Computer, Inc. 20525 Mariani Avenue, M/S 75-3A Cupertino, CA 95014 [Note: we intend to provide a shadow of everything "important" in the apple.com archive. In fact, that's where everything in the apple directory comes from. "Important" means Macintosh technical stuff, like tns, sample code, etc.] ------------------------------ From hoffmann@BITSY.MIT.EDU Tue Aug 22 23:50:48 1989 Received: from ATHENA.MIT.EDU by CHARON.MIT.EDU with SMTP id AA25884; Tue, 22 Aug 89 23:50:42 EDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA12114; Tue, 22 Aug 89 23:50:46 EDT Received: from PADDINGTON.MIT.EDU by BITSY.MIT.EDU with SMTP id AA00374; Tue, 22 Aug 89 22:50:31 EST From: hoffmann@BITSY.MIT.EDU (Ron M. Hoffmann) Received: by PADDINGTON.MIT.EDU (5.61/4.7) id AA15219; Tue, 22 Aug 89 23:50:26 -0400 Date: Tue, 22 Aug 89 23:50:26 -0400 Message-Id: <8908230350.AA15219@PADDINGTON.MIT.EDU> To: srz@ATHENA.MIT.EDU Cc: hoffmann@BITSY.MIT.EDU In-Reply-To: Stanley R Zanarotti's message of Mon, 21 Aug 89 23:11:06 EDT <8908220311.AA21469@CHARON.MIT.EDU> Subject: Preferences screens Status: RO Date: Mon, 21 Aug 89 23:11:06 EDT From: srz@ATHENA.MIT.EDU (Stanley R Zanarotti) The stuff looks good, but I think there are some choices that are missing. Things to think about: Fcc & Bcc appearing automatically when sending messages. Fcc is a choice, Bcc to appear always. User can ignore. Replying behavior. Reply all recipients, or only From. Added this to second screen. Fill column? Or do we just fill to the window width, like we are doing now? I'll settle for the way we're doing it now. Stanford does it the same way really; they just let you specify how wide explicitly. Then the window comes up narrower or wider. Long headers versus short headers. Added. Font size preference. 9pt vs 12pt. Added I think the username should be the top field in the dialog (it's not optional, while Real Name is). Agreed, done. Also, do we want a Back... button to go from the second to the first dialog? The multilevel menus I've seen require you to pop the stack. Doing "OK" in second window takes you back to first window then doing "OK" there exits you. We probably want a "SAVE" button on first screen so doing "OK" just changes is in core and "SAVE" sends it to the config on disk. -stan I am torn betwen allowing the user LOTS of things to diddle and limiting the number of things to deal with. Perhaps a careful choice of defaults will insulate most users from the meriad of configuration options. Things are sufficiently crowded that I almost want three screens now! I'd add configrability of individual header fields (like the Bcc and more custom headers) and explicit setting of window width but I think the two dialogs are pretty crowded now! Your thoughts? -Ron ps. I'd like to see the summary window (h listing) open up as wide as the new message window so that one has a chance of reading most of the subject field. We also need to think about how to ensure that windows that open up on top of others are slightly offset so one can grab at the one below. -rmh From mlc@EAGLE.MIT.EDU Wed Apr 25 12:22:58 1990 Received: from ATHENA.MIT.EDU by CHARON.MIT.EDU with SMTP id AA26403; Wed, 25 Apr 90 12:22:47 EDT Received: from EAGLE.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA25534; Wed, 25 Apr 90 12:22:36 EDT Received: from SLIP-HOST-4.MIT.EDU by EAGLE.MIT.EDU with SMTP id AA00620; Wed, 25 Apr 90 12:22:14 EDT Message-Id: <9004251622.AA00620@EAGLE.MIT.EDU> Date: Wed, 25 Apr 90 12:26:05 From: mlc@EAGLE.MIT.EDU (Mark Curby) To: srz@ATHENA.MIT.EDU (Stan Zanarotti), hoffmann@BITSY.MIT.EDU (Ron Hoffmann), pgalt@EAGLE.MIT.EDU (Phyllis Galt) Subject: Proposed design for TechMail 2.0 (long) Cc: mlc@MIT.EDU (Mark Curby) Status: RO I have reviewed all the comments and bug reports sent to comment-techmail, bug-techmail, and info-techmail. From these I recommend we make the following improvements to TechMail. At the bottom I have listed additional changes users have suggested which I think we should consider for later versions. Proposed changes to be made to TechMail v1.0 to generate v2.0. Note during development and testing intermediate version should be numbered 2.0a1, 2.0a2, 2.0a3,... Line rapping on reply w/text or forward - Width of Reply w/ Text and Forward windows should be set to avoid rapping of lines. Allow the user to resize a outgoing message window without restriction if the option key is held down. Also (optionally) auto-resize the window to avoid wrapping in these two cases, reply w/ text and forward. I.e. when the user selects reply w/ text or forward, create a window just wide enough not to rap the text. Auto-select search field on finger and directory - When directory is selected from the menu, the contents of the name field (if any) should be selected (highlighted), similar to the behavior of find. This allows the user to search for people by just selecting directory and typing a name without having to always double click in the name field before proceeding. Likewise when finger is selected the username field should be selected. "New Mail file" in refile dialog box - In the refile dialog box "New Mail file" should say "New Mail box" instead. Refile dialog - Typing after entering the refile dialog box should select among the existing mailboxes (as it does in the open box dialog box) rather than enter text into the new mail file field. If the user wants to create a new mailbox they should have to click once in the new mail file field to activate a text cursor in that field and to activate (un-gray) the "new" button. Clicking in the new mail file field should deselect all existing mailboxes and deactivate (grey out) the "save" button. Selecting an existing mailbox should deactivate the text cursor and deactivate the new button. Thus only one of the buttons "new" and "save" should be active at any time, the other should be grayed out. Enclosing big files - When the user chooses insert file, if the file is so large that it can not be displayed then a dialog box should come up saying something like "file too big to insert, would you like it to be appended to the message when sent?" and give two option buttons, cancel and append. It would be nice, but not necessary to allow the user to append multiple big files. Reply all change - Add two menu choices to the local menu, reply all and reply all w/text. Remove the reply all option from the preferences dialog. Cleverer custom header field - The handling of the custom header field should be more clever. Only add a ":" to the end of the field if there is no ":" already in the field. Also support longer custom header fields, e.g. up to 100 characters. No account on SMPT server - If the user has no account on the SMPT server she should be able to force replies to a particular POP server by use of the custom header field. Either by putting "From: user@popserver" or "Reply-To: user@popserver" in the field. (note requires "Cleverer custom header field" above) To field in scan listing - Many users want the To: field included in the scan listings. This is clearly desirable in the user's savebox, but it is also generally desirable for all boxes, e.g. to see which letters were addressed to a mailing list. The problem is screen real estate. I recommend we try adding an option in the preferences dialog to turn on display of the to field. If selected we display the to field (as much as fits) between the from and size fields. To make some space we tighten up the distance between the other fields and move the subject a little to the right. Note, adding the to field to the scan listings has implications for the find command, I assume find would now search the To: field also. Print rapping - Line rapping on printing should match line rapping on display for up to 80 character long lines, on both for laser and ImageWriter printers. If the display window is set wider than 80 characters rap at the first word break before the 81st character. Window length preference - Add an option to the preferences to allow the user to select the default length to open windows. Regardless of the user's preference selection, incoming messages should not open longer than the message length. Username on printout - The users real name should be added to the header on printed output. Modify the page number field to show real name, p.#. E.g. "Mark Curby, p.1". Modify for printout of box listings too. Expand in edit address - It would be useful if expand could be made to work while editing addresses, though I can imagine this could cause nasty looping errors. Send message zoom box - Add a zoom box to the send message window. Bcc myself on outgoing messages - Change preferences option from "Cc myself on all outgoing messages" to "Bcc myself on all outgoing messages". Delete mailbox - To provide a way for the user to delete a mailbox from within TechMail, when an empty mailbox is displayed (i.e. the scan listing window) the 'delete' button should switch to a 'delete box' button. Cleverer reply all - The reply all algorithm should be cleverer. If the sender CCed herself then reply all should not generate a message addressed to the sender and also CCed to the sender. Consistent tabs in display and printing - Tabs should be interpreted in the same way in displaying and printing incoming messages. In both cases, while the tab character should be preserved in the saved message, on the screen and when printed the character should be replaced with the "right" number of space characters. Arrow keys in scan listings - Up and down arrow keys should work in scan listings to move up and down. Shift-arrow should select multiple contiguous messages. Find scrolling - When find scrolls window to display found text it should scroll enough that the found text is displayed near the middle of the window, not the button as it does now. Hide X messages - Add a item to the File menu after "User Preferences ...". This item would toggle between two values: "Hide X messages" and "Show X messages". Selecting it would cause messages which are marked for deletion to be displayed or not displayed in the box listing windows. The default would be hide X messages, i.e. messages marked for deletion would be displayed as in v1.0. Messages still would not actually be deleted until the box is closed or TechMail quit. Improve parsing speed - Could parsing be improved? By doing less of it or doing it faster? Could first part of box be opened and rest parsed in background. Ignore case of alias - Alias matching in address expansion should not be case sensitive. More command keys - Add more command key equivalents. Cmd-D for Directory, cmd-E for Expand Address, the delete key to work the same as the delete button, cmd-shift-R for reply w/ text, cmd-opt-R for reply all, and cmd-shift-opt-R for reply all with text. I am against providing a command key equivalent for any irreversible command such as send or send outbox. That leaves refile and forward without command key equivalents, so be it. Note, B, H, J, K, L, T, U, and Y are the keys which remain unused. ==== Bug Fixes ===== Recognizing unformatted disk - Presently, if an unformatted disk is inserted when TechMail is running it ignores it. It should ask if you want to format it. Address list changes not saved - If the user quits TechMail without first closing the address edit window changes made during that edit session are lost. Moving icons - TechMail changes the position of TechMail file icons within the TechMail folder on the user's Mac disk. This bothers users who have organized their files in a particular way. Big files - Not a known bug, but we should be sure to carefully check TechMail's handling of big files, receiving and sending. Particularly right around the 32K limit. Other - I have 11 bug reports which should be reviewed to see if they indicate additional bugs. === Other changes to consider for this or later release === Send mail in background - Make send mail and send outbox run in the background under multifinder. Non-modal responses - Modal dialog boxes are considered undesirable by some users. In particular the no mail dialog boxes. New Message under file - Some think the new message menu option should go in the file menu rather than the local menu. Sorting - Many desire some options for sorting messages within a mailbox. Most want to sort by date, but maybe there are other useful criteria. Some also would like to be able to sort their address lists. Multiple Address books - Offices which provide a standard address book or books would like TechMail to be able to access multiple address books. Time in scan listing - Display time as well as date in scan listings. Close all - Add a close all command. (I think typing cmd-w lots of times is sufficient) Message in scan listing - Display first N characters of the message in the scan listing after the subject. And display the subject in bold to distinguish them. And you got to add a horizontal scroll bar to the box listing window. N should equal about 512 - 1024. Horizontal scroll bar in box window - Add a horizontal scroll bar to the box listing window. Purge option - Add a menu choice to purge files marked for deletion. I think "Hide X messages" above is a better solution. Envelope icon option - Provide option in preferences to display no envelope icon for read (opened) mail. Capitalize Document names - Capitalize the names of documents, e.g. Inbox rather than inbox? What does Apple recommend? Signature file - Provide preferences option to specify a signature file to be appended to the end of all outgoing messages. Move window to back - Add a command to move window to back of the stack of windows. KCHR resource - Include KCHR-resource in TechMail to support use with foreign keyboards. Reply all & reply all w/ text buttons - Add reply all & reply all w/ text buttons to message window. Extended keyboard keys - Empower the six keys above the arrows on the extended keyboard. I.e. help, delete forward, home (top of file), end (bottom of file), page up, page down. Undo - Empower undo in some cases, e.g. after deleting text. Type to select address - Typing the first few letters should move the selection in the select address dialog box, like in the open box dialog. Delete Address book - TechMail won't let user delete entire address book. Should it? Display window size - When resizing a window the size of the window should be displayed (nxn characters). Refile v. File - Some users find the command name "refile" confusing and suggest it be changed to file or move. I'm against it. Draftbox - We may also want to review how Drafts are handled. Should refiling to draft auto-close the window? - Mark ------------ Mark Curby MIT E32-130A (617) 253-7725 77 Mass. Ave. mlc@eagle.mit.edu Cambridge, MA 02139 From mlc@EAGLE.MIT.EDU Fri Jul 20 11:44:21 1990 Received: from ATHENA.MIT.EDU by charon.MIT.EDU with SMTP id AA27209; Fri, 20 Jul 90 11:44:17 EDT Received: from EAGLE.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA15746; Fri, 20 Jul 90 11:44:13 EDT Received: from NETSERVA-MAC-26.MIT.EDU by EAGLE.MIT.EDU with SMTP id AA15285; Fri, 20 Jul 90 11:44:08 EDT Message-Id: <9007201544.AA15285@EAGLE.MIT.EDU> Date: Fri, 20 Jul 90 11:45:04 From: mlc@EAGLE.MIT.EDU (Mark Curby) To: srz@ATHENA.MIT.EDU (Stan Zanarotti), hoffmann@MIT.EDU (Ron Hoffmann) Subject: Proposed specifications for enclosures in TM2.0 Cc: mlc@MIT.EDU (Mark Curby), pgalt@EAGLE.MIT.EDU (Phyllis Galt) Status: RO Ron and Stan - Here are my recommendations for how enclosures should work in TechMail 2.0. Comments? - Mark ---- cut here ------ Proposed specifications for enclosing large files and binary files in TechMail v2.0 Mark Curby 20Jul90 TechMail 2.0 should allow users to send/receive a large text file (>32K) or a binary file with an email message. The ability to enclose multiple files, while desirable, is not essential in this version. The file enclosure system should work fairly transparently for TechMail 2.0 users sending and receiving files, e.g. all the BinHexing details should be hidden from them. The system should also work acceptably for non-TechMail 2.0 users receiving messages with enclosures from TechMail 2.0 users. Sending messages containing enclosures: An "Enclose File" command is added to the local menu below the "Insert File" menu item. It's command key equivalent is cmd-opt-I. Like Insert File, this item is only active when the active window is an outgoing message. Note this item alternates with "Retrieve Enclosure", see "Retrieving messages containing enclosures" below. Selecting Enclose File opens a dialog box, similar to the insert file dialog box, to pick a file to enclose. The header in this dialog box says "File to enclose with message when sent". Selecting a file does not display the file in the outgoing message window, but does display the message "-- Contains Enclosure --" at the bottom of the outgoing message window in the horizontal scroll bar area. Note, anytime before the message is sent the user can check what file is enclosed, remove the enclosure, or select an alternative enclosure via the Enclose File command. When the active window is an outgoing message which contains an enclosure and the Enclose File command is selected the pick file dialog box opens with the present enclosure highlighted, thus reminding the user what file is enclosed. The user may click in a blank area to deselect the file, thus removing any enclosure from the message. Or the user may click on another file, thus substituting this enclosure for the previously selected enclosure. When the message is sent the enclosure, if not a text file, is BinHexed and appended at the bottom of the message. Some text such as "Enclosure follows, use BinHex 4.0 to retrieve" should precede the enclosure to clue in users who receive the message with some email system other than TechMail 2.0. Also a header field may be added to the message so TechMail 2.0 can recognize messages which contain enclosures and do the right thing. Note, enclosures go to all addressees, including Cc, Bcc and Fcc. An alternative would be to include a set of 3 check boxes in the enclose file dialog box. These would control whether the enclosure was included in the copies to Cc, Bcc, and Fcc. The default would be all checked (enclosures sent to all). User's selections would be preserved between sessions in the config file. Receiving messages containing enclosures: Messages containing enclosures are indicated in the scan listing by a small plus sign next to the envelope icon. When an incoming message containing an enclosure is opened the message "-- Contains Enclosure --" is displayed at the bottom of the window in the horizontal scroll bar area. The "Enclose File" menu item changes to "Retrieve Enclosure" and become active. Selecting Retrieve Enclosure brings up a save file dialog box. The file name is pre-set but still editable by the user, in case she wants to save the file by a name other than it originally had. The save dialog box has an additional button: "Delete Enclosure". Selecting this brings up an "are you sure" dialog box. If the user confirms then the enclosure is deleted from the message and not saved on the hard disk. This might be done for example if the user suspected the enclosure contained a virus. The save dialog box also has a "Leave a copy of enclosure in mail message" check box, which by default is not checked. Thus, normally when a user retrieves an enclosure the enclosure is removed from the mail message. This saves disk space and is consistent with the TechMail model that electronic mail messages are similar to paper mail messages in that the default action is move rather than copy (e.g. when mail is picked up from the PO server). Note, the icon in the box listing, the enclosure message at the bottom of the window, and the deactivation of the Retrieve Enclosure menu item must all be updated to accurately reflect the fact that this message no longer contains an enclosure. If a message has an enclosure at the time the user selects to forward the message then the enclosure is included in the forwarded message. Note of course that the user can remove the enclosure or substitute another enclosure for it in the usual manner before sending the forwarded message. Enclosures are never automatically attached to replies. -- end ----- From mlc@EAGLE.MIT.EDU Fri Jul 20 12:19:50 1990 Received: from ATHENA.MIT.EDU by charon.MIT.EDU with SMTP id AA27291; Fri, 20 Jul 90 12:19:42 EDT Received: from EAGLE.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA16801; Fri, 20 Jul 90 12:19:38 EDT Received: from NETSERVA-MAC-26.MIT.EDU by EAGLE.MIT.EDU with SMTP id AA15434; Fri, 20 Jul 90 12:19:29 EDT Message-Id: <9007201619.AA15434@EAGLE.MIT.EDU> Date: Fri, 20 Jul 90 12:20:22 From: mlc@EAGLE.MIT.EDU (Mark Curby) To: srz@ATHENA.MIT.EDU (Stan Zanarotti) Subject: Specifications for TechMail v2.0 - Revised 20 Jul 90 Cc: hoffmann@MIT.EDU (Ron Hoffmann), mlc@MIT.EDU (Mark Curby), pgalt@EAGLE.MIT.EDU (Phyllis Galt) Status: RO Stan - Here are the specifications for TechMail 2.0 as of 20 Jul 90. - Mark --- cut here --- Specifications for TechMail v2.0 Revised July 20, 1990 - Mark Curby Note during development and testing intermediate version should be numbered 2.0a1, 2.0a2, 2.0a3,... Line wrapping on reply w/text or forward - Width of Reply w/ Text and Forward windows should be set to avoid wrapping lines. Auto-resize the window to avoid wrapping in these two cases. I.e. when the user selects reply w/ text or forward, create a window just wide enough not to wrap the text. Also allow the user to resize an outgoing message window without restriction if the option key is held down. Auto-select search field on finger and directory - When directory is selected from the menu, the contents of the name field (if any) should be selected (highlighted), similar to the behavior of find. This allows the user to search for people by just selecting directory and typing a name without having to always double click in the name field before proceeding. Likewise when finger is selected the username field should be selected. "New Mail file" in refile dialog box - In the refile dialog box "New Mail file" should say "New Mail box" instead. Refile dialog - Typing after entering the refile dialog box should select among the existing mailboxes (as it does in the open box dialog box) rather than enter text into the new mail file field. Implementation option 1: Divide the refile dialog box into two dialog boxes. The first would be very similar to the present one, but would have a button which says "create new mailbox". Selecting this option would bring up another dialog box which would allow the user to create and new mailbox and store the message(s) there. Implementation option 2: If the user wants to create a new mailbox they should have to click once in the new mail file field to activate a text cursor in that field and to activate (un-gray) the "new" button. Clicking in the new mail file field should deselect all existing mailboxes and deactivate (gray out) the "save" button. Selecting an existing mailbox should deactivate the text cursor and deactivate the new button. Thus only one of the buttons "new" and "save" should be active at any time, the other should be grayed out. Enclosing big & binary files - TechMail 2.0 should allow users to send/receive a large text file (>32K) or a binary file with an email message. The ability to enclose multiple files, while desirable, is not essential in this version. See "Proposed specifications for enclosures in TM2.0" -mlc@EAGLE.MIT.EDU (Mark Curby), 20 Jul 90. Reply all change - Add two menu choices to the local menu, reply all and reply all w/text. Remove the reply all option from the preferences dialog. Cleverer custom header field - The handling of the custom header field should be more clever. Only add a ":" to the end of the field if there is no ":" already in the field. Also support longer custom header fields, up to 100 characters if possible. No account on SMTP server - If the user has no account on the SMTP server she should be able to force replies to a particular POP server by use of the custom header field. Either by putting "From: user@popserver" or "Reply-To: user@popserver" in the field. (note requires "Cleverer custom header field" above) To field in scan listing - Many users want the To: field included in the scan listings. This is clearly desirable in the user's savebox, but it is also generally desirable for all boxes, e.g. to see which letters were addressed to a mailing list. Add an option in the preferences dialog to turn on display of the to field. If selected we display the to field (as much as fits) between the from and size fields. To make some space we tighten up the distance between the other fields and move the subject a little to the right. Note, needs to work with 12pt font too. Note, adding the to field to the scan listings has implications for the find command, I assume find would now search the To: field also. Print wrapping - Line wrapping on printing should match line wrapping on display for up to 80 character long lines, on both for laser and ImageWriter printers. If the display window is set wider than 80 characters rap at the first word break before the 81st character. Window length preference - Either add an option to the preferences to allow the user to select the default length to open windows or improve the algorithm for choosing length, e.g. based on monitoring past user behavior or based on screen size. Regardless of the the method, incoming messages should not open longer than the message length. Username on printout - The users real name should be added to the header on printed output. Modify the page number field to show real name, p.#. E.g. "Mark Curby, p.1". Modify for printout of box listings too. Send message zoom box - Add a zoom box to the send message window. Zooming should honor width restriction. Bcc myself on outgoing messages - Change preferences option from "Cc myself on all outgoing messages" to "Bcc myself on all outgoing messages". Delete mailbox - To provide a way for the user to delete a mailbox from within TechMail, when an empty mailbox is displayed (i.e. the scan listing window) the 'delete' button should switch to a 'delete box' button. Cleverer reply all - The reply all algorithm should be cleverer. If the sender CCed herself then reply all should not generate a message addressed to the sender and also CCed to the sender. Consistent tabs in display and printing - Tabs should be interpreted in the same way in displaying and printing incoming messages. In both cases, while the tab character should be preserved in the saved message, on the screen and when printed the character should be replaced with the "right" number of space characters (assume tab stops every 8 characters). If the user modifies a received message and says 'yes' to the 'do you want to save changes' query, then the tabs may be converted to spaces in the saved version. Arrow keys in scan listings - Up and down arrow keys should work in scan listings to move up and down. Shift-arrow should select multiple contiguous messages. Find scrolling - When find scrolls the window to display found text it should scroll enough that the found text is displayed near the middle of the window, not the button as it does now. Hide X messages - Add an item to the File menu after "User Preferences ...". This item would toggle between two values: "Hide X messages" and "Show X messages". Selecting it would cause messages which are marked for deletion to be displayed or not displayed in the box listing windows. The default would be hide X messages, i.e. messages marked for deletion would be displayed as in v1.0. Messages still would not actually be deleted until the box is closed or TechMail quit. The users preference should be recorded in the config file so that their preference is preserved from session to session. Note, toggling between show and hide X messages should update the display, i.e. the user should not have to close the scan listing window and reopen it as this would cause marked messages to be deleted. Improve parsing speed - Try to improve parsing speed, e.g by doing less of it or doing it faster -- If this can be done with out reducing reliability. Ignore case of alias - Alias matching in address expansion should not be case sensitive. More command keys - Add more command key equivalents. Cmd-D for Directory, cmd-E for Expand Address, the delete key to work the same as the delete button, cmd-K for Check Mail, cmd-L for Select Addresses, cmd-opt-W for close all windows, cmd-shift-R for reply w/ text, cmd-opt-R for reply all, and cmd-shift-opt-R for reply all with text. I am against providing a command key equivalent for any irreversible command such as send or send outbox. That leaves refile and forward without command key equivalents, so be it. Note, B, H, J, T, U, and Y are the keys which remain unused. Also, if it is possible with out a lot of work cmd-leftarrow and cmd-rightarrow for move forward and move back one word. Search direction - Searches should run from most recent to least recent rather than the reverse as they do now in v1.0. Having this be an option in the search dialog box, with the default newest to oldest, would be great. Forward multiple messages - Make the forward menu item work like the print menu item, i.e. selecting multiple messages in a box listing and choosing "Forward" would generate a new message with each of the selected messages included. Kerberos and Hesiod - Add support for Kerberos and Hesiod. Use of these should be optional, selected in User Preferences. The default should be not to use Kerberos and Hesiod. ==== Bug Fixes ===== Recognizing unformatted disk - Presently, if an unformatted disk is inserted when TechMail is running it ignores it. It should ask if you want to format it. Address list changes not saved - If the user quits TechMail without first closing the address edit window changes made during that edit session are lost. High bit characters - TechMail should strip or map high bit characters when editing, composing messages and inserting text. Messages sent with TechMail should look the same to the sender and the recipient. Out of memory - Repeatedly making minor edits to an alias file consumes increasingly larger amounts of memory until TechMail dies with "out of memory" alert. Repeatedly expanding a group address also exhibits this bug. Refile to diskette - If you refile a message to a new mailbox on a diskette (i.e. select refile, use 'drive' button to select the diskette, type in new file name, and select 'new' button) the box is created in the root directory of the system disk rather than on the diskette. The message is properly filed in this box. Note, the case of refiling into an existing mailbox on a diskette works fine. Inbox/inbox - Make "Inbox" and "Outbox" consistent throughout TechMail so as to avoid causing problems for AUFS. Outbox listing update - If you store a message in the outbox (via the outbox button) when the outbox scan listing window is open the message is not immediately displayed in the outbox. Closing and re-opening the outbox causes the display to be properly updated. Time zone - Try to improve TechMail so that dates include time zone info in compliance with RFC822. Moving icons - TechMail changes the position of TechMail file icons within the TechMail folder on the user's Mac disk. This bothers users who have organized their files in a particular way. Fix if possible. Big files - Not a known bug, but we should be sure to carefully check TechMail's handling of big files, receiving and sending. Particularly right around the 32K limit. Check also TechMail's handling or very large messages (>200-300K). Some users have noted problems with such files. === Other changes to consider for this or later release === Undo - Empower undo in some cases, e.g. after deleting text. Envelope icon option - Either provide option in preferences to: display no envelope icon for read (opened) mail, or to use Jim Bruce's set of icons, or to chose icons for each of the 3 cases. Type to select address - Typing the first few letters should move the selection in the select address dialog box, like in the open box dialog. Send mail in background - Make send mail and send outbox run in the background under multifinder. Non-modal responses - Modal dialog boxes are considered undesirable by some users. In particular the no mail dialog boxes. New Message under file - Some think the new message menu option should go in the file menu rather than the local menu. Sorting - Many desire some options for sorting messages within a mailbox. Most want to sort by date, but maybe there are other useful criteria. Some also would like to be able to sort their address lists. Multiple Address books - Offices which provide a standard address book or books would like TechMail to be able to access multiple address books. Time in scan listing - Display time as well as date in scan listings. Message in scan listing - Display first N characters of the message in the scan listing after the subject. And display the subject in bold to distinguish them. And you got to add a horizontal scroll bar to the box listing window. N should equal about 512 - 1024. Horizontal scroll bar in box window - Add a horizontal scroll bar to the box listing window. Purge option - Add a menu choice to purge files marked for deletion. I think "Hide X messages" above is a better solution. Capitalize Document names - Capitalize the names of documents, e.g. Inbox rather than inbox? What does Apple recommend? Signature file - Provide preferences option to specify a signature file to be appended to the end of all outgoing messages. Move window to back - Add a command to move window to back of the stack of windows. KCHR resource - Include KCHR-resource in TechMail to support use with foreign keyboards. Reply all & reply all w/ text buttons - Add reply all & reply all w/ text buttons to message window. Extended keyboard keys - Empower the six keys above the arrows on the extended keyboard. I.e. help, delete forward, home (top of file), end (bottom of file), page up, page down. Delete Address book - TechMail won't let user delete entire address book. Should it? Display window size - When resizing a window the size of the window should be displayed (nxn characters). Refile v. File - Some users find the command name "refile" confusing and suggest it be changed to file or move. I'm against it. Draftbox - We may also want to review how Drafts are handled. Should refiling to draft auto-close the window? --- end ----- From gettens@EAGLE.MIT.EDU Mon Mar 11 21:59:12 1991 Received: from MIT.MIT.EDU by charon.MIT.EDU with SMTP id AA21813; Mon, 11 Mar 91 21:59:06 EST Received: from EAGLE.MIT.EDU by MIT.EDU with SMTP id AA09785; Mon, 11 Mar 91 21:59:02 EST Received: from ATHENA-MAC-5.MIT.EDU by EAGLE.MIT.EDU with SMTP id AA27697; Mon, 11 Mar 91 21:58:58 EST Message-Id: <9103120258.AA27697@EAGLE.MIT.EDU> Date: Mon, 11 Mar 91 22:01:42 From: gettens@EAGLE.MIT.EDU (jack gettens) To: srz@MIT.EDU Subject: Techmail-s Settings Status: RO Stan, Here is the diff for custom.c to search the sytem folder for the settings file using MPW C 3.1. There's probably a better way to do it, but this is the easiest that I could think of. If you see that is flawed, please let me know. Mark Curby doesn't want to risk this change at this point in the distribution -- but wants it to search the system folder & run properly on the IIci family. The only option is to re-build with MPW C 3.0 (or to convince Mark that the change is ok). I really don't want to change my system over to 3.0 for one build. If you're near your source could you please generate a Techmail-S 1.1d2? If so, let me know. If you're not going to be around I'll do it. thanks, Jack ---------------------- 435c435,437 < char buf[40]; --- > char buf[256]; > char vol_name[32]; > short vol_ref_num; 453c455 < custom_fp = fopen(buf, "w"); --- > custom_fp = fopen(buf, "r+"); 454a457,464 > GetVol(vol_name,&vol_ref_num); > p2cstr(vol_name); > strcpy(buf,vol_name); > strcat(buf,":system folder:"); > strcat(buf,custom_name); > custom_fp = fopen(buf,"w"); > if(custom_fp == NULL) > { 456a467,468 > } > 571a584,585 > char path_name[256]; > char vol_name[32]; 572a587 > short vol_ref_num; 586c601,610 < return(NOT_RMAIL); --- > { > GetVol(vol_name,&vol_ref_num); > p2cstr(vol_name); > strcpy(path_name,vol_name); > strcat(path_name,":system folder:"); > strcat(path_name,name); > custom_fp = fopen(path_name,"r"); > if(custom_fp == NULL) > return(NOT_RMAIL); > } From srz@charon.MIT.EDU Tue Mar 19 23:21:57 1991 Received: from MIT.MIT.EDU by charon.MIT.EDU with SMTP id AA01867; Tue, 19 Mar 91 23:21:53 EST Received: from CHARON.MIT.EDU by MIT.EDU with SMTP id AA21430; Tue, 19 Mar 91 23:21:10 EST Received: by charon.MIT.EDU id AA01859; Tue, 19 Mar 91 23:21:04 EST Date: Tue, 19 Mar 91 23:21:04 EST From: srz@charon.MIT.EDU (Stan Zanarotti) Message-Id: <9103200421.AA01859@charon.MIT.EDU> To: macdev@MIT.EDU Subject: macathena locker Status: RO I have spent some time thinking about the current organization of the macathena locker, and I believe it is lacking in a few respects. The argument that the current organization is based upon the MPW distribution, and therefore is a standard, does not hold water with me. First of all, except for some Include files and some Examples, the MPW distribution does not come with any source. Organization of sources is venturing into new territory, and does not qualify as a "standard". Also, the MPW distribution puts a great emphasis on language. Many of the directory names are preceded by a language identifier: "CIncludes", or "PIncludes". This makes sense for MPW because each language is a different product, separately managed and in fact unbundled from each other. From this point of view, splitting the distribution up like this makes a lot of sense. But from the MIT point of view, separating out different projects on the basis of language, which is what the current organization implies, would be a mistake. If I wrote a TechFoo application, and happened to write it in Pascal for some strange reason, does this mean that the development tree for this application would be put under a directory called "PAppSources" (or is that "PAppsources")? Would include files be placed under "PIncludes"? Would other developers, looking for the sources, have to know a priori what language it was developed in? I don't feel that language is an important enough attribute for a Macathena project to be used to organize the tree. The MPW names imply this. An objection I've already made to the names is the use of mixed-case directory names. Unfortunately, UNIX doesn't have add names, and using symbolic links is not quite the same thing. And asking individual developers to make symbolic links in their own homedirs is not the best solution when the original directories could be kept in lowercase with little loss of aesthetic value. The current macathena locker has directories CAppsources & CLibsources both at the top-level and under the MIT directory. What is the MIT directory used for? Most of the locker is MIT stuff, so what does this extra layer give us? Does this imply that things found elsewhere are not MIT? I'd believe this in relation to the top-level CAP folder, but the other directories are definitely MIT. Perhaps the name "macsrc" would be a better name, although there is probably an even more applicable name once we decide what the directory should be used for. I would argue that there is an existing "standard" that could be used for organizing the locker. This is the standard used by Athena development projects, such as Kerberos and Zephyr. Since MacAthena by definition deals with Athena, the current and future developers will have had some exposure to this organization. The top-level organization of Athena development is that of projects. The Zephyr project is separated from the Kerberos project by the existence of different lockers. This facilitates different management of these projects by different groups. Each locker is organized along a similar line, mostly by major function (src, doc, various target platforms). This is what I was referring to when I said I preferred to see programs and related libraries closer together. The kerberos locker contains both the sources to the Kerberos libraries and the various kerberos specific client programs (i.e. test programs and utilities like kinit). This is as opposed to the current organization of the macathena locker, where the krb and des libraries are intermingled with the bsd, testtrack, and other libraries. If we were developing similar kerberos client programs for the Mac, they would be further away from the libraries than in the Kerberos locker. Of course, what I've been referring to up to now is development -- where to put the sources for ongoing projects. In order to share libraries and include files, we need a method of distributing them without forcing people to pick up the entire source distribution -- i.e. libraries in object form, include files in an easy way to use. This implies an installation process, where these libraries and include files are put into a common place for people to pick up. I equate this to the way include files and libraries are handled on Athena. There is a "krb.h" include file in the Kerberos library, which is where development occurs. Once it is stable, it gets installed into "/usr/include" (via rel-eng) for use by other client programs. Distribution outside MIT is an open question. How do we package things up for easy distribution? A lot of what I've been talking about cannot be decided by a single person -- we need to arrive at a group consensus as to what we want to do. Unfortunately, it's hard to attain consensus with people who work in different places and in different organizations. Hopefully the new reorg and accompanying moves will help this process. I think we should set up a Discuss meeting, at least for a mail archive. Until there is a "MacDiscuss(TM?)", it might not be feasible to use the Discuss meeting directly. -stan From mlc@EAGLE.MIT.EDU Wed Oct 31 09:36:36 1990 Received: from ATHENA.MIT.EDU by charon.MIT.EDU with SMTP id AA27474; Wed, 31 Oct 90 09:36:30 EST Received: from EAGLE.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA25044; Wed, 31 Oct 90 09:36:25 EST Received: from NETSERVA-MAC-14.MIT.EDU by EAGLE.MIT.EDU with SMTP id AA02120; Wed, 31 Oct 90 09:36:18 EST Message-Id: <9010311436.AA02120@EAGLE.MIT.EDU> Date: Wed, 31 Oct 90 09:35:43 From: mlc@EAGLE.MIT.EDU (Mark Curby) To: srz@ATHENA.MIT.EDU (Stan Zanarotti) Subject: review of TechMail 2.0a0 Cc: hoffmann@MIT.EDU (Ron Hoffmann), mlc@MIT.EDU (Mark Curby), pgalt@EAGLE.MIT.EDU (Phyllis Galt) Status: RO Stan - I have extensively tested and reviewed TechMail 2.0a0. Overall I am very impressed with this version. I think the user community will be very pleased with the changes and improvements. I'm really enjoying using it. The following are changes, bug fixes and additions I would like to see made to TechMail 2.0a0. These are based on comparisons of 2.0a0 to the 20 Jul 90 TechMail 2.0 specifications, bugs found in testing 2.0a0 and requests from TechMail users since 20 Jul 90. Please let me know if you have any questions, comments, suggestions, etc. for any of these. - Mark ------------ Mark Curby MIT E32-130A (617) 253-7725 77 Mass. Ave. mlc@eagle.mit.edu Cambridge, MA 02139 --- cut here --- Reply all - - Real names should not be stripped from the CCed addresses. - Display the keyboard equivalents in the menu for Reply with Text, Reply All, and Reply All with Text. See MS Word menus , e.g. Go Back, and Plain Text, for examples. Custom headers - - Support cut and paste in editing custom header fields. - Make 2 text entry boxes for custom header fields: "One editable custom header field:" and "Additional, non-editable custom header fields:" To field in scan listing - - Turning From/To on and off should work like switching between 9pt and 12pt type, i.e. turn it on and when you next open a mailbox all the messages are displayed with From/To fields, turn it off and when you next open a mailbox all messages are displayed with just the from field. - The header of scan listing should change between "From" and "From/To" to reflect present state. - If mail message is to multiple people, show the first person in the list, not the last. - If mail message is to multiple people, put either "," or "..." after the To name to indicate that the message was addressed to multiple individuals. - When available, always present real name, not email address, in the To field. Username on printout - - Username needs to also be included on printout of box listings. Send Message zoom box - - Zooming send window should maintain present width of window at the time it is zoomed. I.e. zooming should only change the length of the window, even if the user has widened window beyond default via option resize. Bcc myself - Bcc myself should Bcc: user@popserver rather than just Bcc: user. Note, this is key if SMTP server is different from pop server. Clever reply all - Fix so that it does not leave a spurious "," in the case that the sender included herself first in a list of Ccs. For example we receive a message To: foo and Cc: foo, mlc. When we reply all we get a message To: foo and Cc: , mlc. We should get a message To: foo and Cc: mlc. Tabs - - When one saves a message which contains tabs to a text file, the tabs should remain tabs and not be converted to spaces. - When one forwards a message which contains tabs, the tabs should remain tabs and not be converted to spaces. Command keys - - Add Cmd-opt-I for Enclose Binhex and display key board equivalent in menu. - The delete key on the keyboard should work the same as delete button and delete menu item. Forward multiple messages - - Forwarded messages should not be concatenated. Messages should be separated by : ------- End of Forwarded Message ------- Forwarded Message Even nicer would be if multiple forwarded messages were numbered: ------- Forwarded Message #1 blah blah blah ------- End of Forwarded Message #1 ------- Forwarded Message #2 blah blah blah ------- End of Forwarded Message #2 Kerberos and Hesiod - - Kerberos and Hesiod did not seem to work in version 2.0a0. Inbox/inbox - - Check that "Inbox", "Outbox", "TechMail Addresses", etc. are capitalized consistently throughout TechMail 2.0 Outbox listing update - - Fix outbox listing update bug so that if user stores a message in the outbox when the outbox window is open the window is immediately updated. Envelope icon option - - Reposition the X (deleted mail icon) or the bullet (unread mail icon) slightly so that they line up vertically better. Enclosing binary files - - When a file is extracted from a mail message it should not be placed in the folder on top of an existing file, so that it obscures it. - Fix enclosing files so that enclosing files from other drives (volumes) works properly. - Change message string inserted ahead of enclosures to: (Binhex enclosure follows. Use BinHex 4.0 to convert) Put a blank line before and after this string. - Indicate in the scan listing of a mailbox which messages contain enclosures, e.g. by a small plus sign (+) next to the envelope icon. - Add "Delete Enclosure" button to the extract binhex dialog box. Selecting this should present an 'are you sure' dialog box before removing the enclosure. - Extracting an enclosure should, by default, remove the enclosure from the message. Add to the extract binhex dialog box a "Keep copy of enclosure with message" check box. By default this box is not checked. The status of this option should be preserved between sessions in the config file. When unchecked, the act of saving an enclosure removes the enclosure from the incoming message. When checked, saving an enclosure does not remove the enclosure from the message. - Forwarding a message with an enclosure should forward the enclosure too. TechMail 2.0a0 Bug Fixes -- Close inbox - A few times when closing the inbox or in Get Mail I've gotten a "Cannot delete old mail file" message. The result is two inboxes: inbox and inbox~, and sometimes two inbox windows open. Send Mail error 31 - Once when sending mail I got "Error 31", but the mail was sent OK. Get Mail error 31 - Once when getting mail I got "Error 31" and the Get Mail failed. Restarting TM cleared the problem. Find, search whole mail file - Find, when searching the whole mail file is broken. - Seems to search oldest first regardless of state of search direction check box. - Search fails even when the find string exists in messages. - If it does manage to find one occurrence, it never finds a second. Find "Mail File" - In the Find dialog box, change "search whole mail file" to "search whole mailbox". TechMail Settings file - TM 2.0a0 seems to corrupt the TM settings file for TM 1.0. Running TM 2.0 using a settings file generated by 1.0, and then running 1.0 again causes all settings to be lost for both 1.0 and 2.0. Refile modified message - When a user refiles an incoming message which has been modified, TM should present a "do you want to save changes" dialog box, as is done when a user closes the window of a modified incoming message. Handling NUL characters in messages - If one inserts or cuts&pastes Mac text which contains ASCII NUL characters into a TechMail message, the NUL characters should be stripped or replace with ASCII space, rather than interpreted as end of line. Cut-paste bug - If one clicks and drags from the middle of the first screen to the bottom of a multi-screen incoming message and then does cut or delete -- the whole message is deleted. Doing a paste then brings back only a portion of the deleted text. See bug-techmail posting from mlc 31 aug 90 for more info. Additions to TechMail 2.0 -- Refile deleted message - Change TechMail so that refiling a deleted message moves it to the new mailbox and leaves it there undeleted. Move buttons - Move buttons on all windows about 1/2 inch right. This will reduce accidental activation of Send and Delete when closeing a box. Bigger refile dialog box - Make refile dialog box longer so that it shows 12 or 13 mailboxes, rather than 9. Incoming mail zoom box - Change action of incoming mail zoom box so that it zooms length to full screen length, but zooms width just wide enough to show widest line of message. Shift-Tab in header - Shift-Tab should move one up through the header fields, just as tab moves one down. Pop port - Change TechMail 2.0 to use proper POP3 port number, i.e. use 110 rather than 109. Eagle should support POP3 on both ports. Send Outbox menu - Grey out the Send Outbox menu item when the outbox is empty or nonexistent. Send/Get mail - Add a command to send outbox and get mail in one connection. Holding down the option key when selecting the Server menu would cause "Send Outbox/Get Mail" to be displayed instead of "Send Outbox". Undo - Add support for one level of undo (cmd-Z) for cut, paste, typing and delete. See MacTutor Vol 3, p261 for sample code. Type to select address - Modify the select address dialog box so that typing the first few letters moves the selection like in the open dialog box. Also support arrow keys to move up and down. --- end --- From moon@cambridge.apple.com Tue Dec 18 18:30:53 1990 Received: from apple.com by charon.MIT.EDU with SMTP id AA04889; Tue, 18 Dec 90 18:30:46 EST Received: from [90.1.0.10] by apple.com with SMTP (5.61/25-eef) id AA13072; Tue, 18 Dec 90 15:30:37 -0800 for srz@charon.MIT.EDU Received: from cambridge.apple.com (ministry.cambridge.apple.com) by goofy.apple.com with SMTP (5.61/25-eef) id AA29643; Tue, 18 Dec 90 15:30:31 -0800 for srz@charon.MIT.EDU Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef) id AA17318; Tue, 18 Dec 90 18:24:06 -0500 Message-Id: <9012182324.AA17318@cambridge.apple.com> Date: Tue, 18 Dec 90 18:28:38 From: moon@cambridge.apple.com (David A. Moon) To: hoffmann@MIT.EDU (Ron Hoffman), mlc@EAGLE.MIT.EDU (Mark Curby), srz@charon.MIT.EDU (Stan Zanarotti) Subject: TechMail feature wish list Cc: Moon@cambridge.apple.com Status: RO Here's the feature wish list you invited me to send. I hope you can do the most important of these in 2.0. It's divided into categories and the highest priority item within each category is listed first. However, the first category listed is not the highest priority, the order of categories is random (perhaps the order is ease of implementation). These feature requests are relative to version 1.0; I haven't switched to 1.1.1 yet but I will very soon. **Cosmetic: Reply with Text should remove all header fields except From and Date from the text of the replied-to message that it inserts. Reply with Text always uses "> " for the indent prefix of the text it inserts. I'd prefer " "; can this be made a user preference? Note: to cope with the plethora of preferences, using multiple preference screens is good. I don't mind having a "power user preferences" screen that is harder to get to. It would also be convenient when composing or reading a message to select some text and change its indentation (i.e. insert or remove a prefix in front of each line within the selection). This is because mail often contains other material "quotated" by indenting it; the other material might be another message, or part of a program, or anything. Moving the scroll thumb to the bottom of the vertical scroll bar should put the last line of the message at the bottom of the window. Currently it puts it just above the top of the window, which makes the scroll thumb not very useful to tell how far through the message you are, since there is a whole window worth of blank lines after the real end of the message. Can the Open Box and Refile dialog be made taller? There isn't enough room for all my boxes. In fact there is only room for five boxes plus the three builtin ones, which doesn't seem like enough for hardly anybody. I figured out how to use ResEdit to make Refile taller in my copy, but I think the default has no reason to be that small. I'd make it about 20 boxes high, if that fits on the smallest Macintosh screen. Also I couldn't find where the Open Box dialog's height is controlled so I couldn't make it taller. Ideally the height of these dialogs would be based on their contents, of course, but I guess that's too hard to do on the Macintosh. All windows should have their width and height chosen based on their contents. Obviously this should be subject to an asthetic minimum, and a maximum based on how much screen space is available given the position of the top-left corner. This was partially in the 2.0 feature list you mailed me and partially discussed in my earlier mail, but I haven't seen it stated this succinctly. Get Mail should scroll the inbox so the new messages are visible. Specifically, if the first and last new messages are not already visible, then the last new message should be scrolled to the bottom line, unless that would scroll the first new message off the top, in which case the first new message should be scrolled to the top line. While editing a draft pulled up from the Draftbox, the Save Draft button puts another copy of it into the Draftbox. It would be better if it updated the existing copy. Correctly blank out the horizontal scroll bar when a message window is made shorter. In TechMail 1.0 a residue of old text is often left there. Perhaps there should be a feature where one or more mailbox files can be opened automatically when TechMail starts up. Or maybe there should be an option to save the set of open boxes when quitting and open all of them the next time TechMail is started. I wish new windows were positioned more intelligently so they don't obscure existing windows. I find I am unable to articulate an algorithm for this, so I made it lowest priority. If you don't do anything about it I won't complain. ***Get/Check Mail: It feels wrong that when Check Mail tells me I have new mail, there isn't a button in that dialog to go ahead and get the new mail. It feels wrong that Get Mail writes out a bunch of stuff even if there isn't any new mail. It seems less than optimal that Get Mail parses all the messages in the inbox, rather than only parsing the ones that it just appended to the inbox. **Outbox: I find it very hard to remember whether I have left unsent messages in the outbox. I can't even check by pulling down the Server menu and checking whether Send Outbox is disabled. Actually I'd like to see an Outbox menu with Send and Open commands; when the outbox was empty the entire menu would be disabled, so a glance at the menu bar would reveal whether anything is in the outbox. When TechMail started up it would have to check the outbox file, after that it would of course know whether it was empty or not by whether it had put anything into it since the last time the outbox was sent. This would save me from thinking I sent a message and then discovering hours later that it's still in the outbox. **Headers: The reply commands should generate an In-Reply-To header like almost all other mail programs. I didn't figure out the custom header facility but I don't think it can do this. It would probably be a good idea for TechMail to generate a Message-ID header, since some other mail programs work more reliably if that header is present so they don't have to fake an ID from the From and Date fields. **Message organization features: Editing the subject line of an incoming message doesn't change the subject shown in the "scan window" (or "mailbox window") containing the message. I edit subject lines a lot when people send me mail with no subject or a subject that I don't find adequately descriptive of the message, so I can find it later. The only way to organize messages is by putting them into different boxes, which is fine except the small size of the menu of boxes (noted above) inhibits the use of a lot of different boxes, since it's a pain to keep scrolling through them. It would be nice if there was also a feature for putting keywords on messages as in many other mail readers. The keywords would be chosen from a menu, with the ability to add and remove menu items. The keywords would be displayed in a scan window. The easiest way to display the keywords is to prefix something like "{keyword1,keyword2}" in front of the subject, rather than making a new column. The keywords should be stored in messages in plain text so that editing the keyword menu won't mess them up. There is no way to gain quick access to a set of related messages. This can get very hairy, but some simple things would be useful. One is to find all messages that are related by In-Reply-To and References header lines (two names for the same thing) to the selected message(s). There are standards for the format of those header lines. Another is to find all messages with a given keyword. A third is to find all messages whose subject contains a given string. A fourth is to find all messages to or from a given person (best to ignore the host field, it often varies). Finally, find all messages whose header and/or text contains a given string (ignoring case). The first thing I mentioned is the hardest to implement, since it involves a bunch of parsing, but none of these are terribly hard. They don't have to be particularly fast, either. The scope of the search should be the currently selected scan window, with an option to search all open scan windows and another option to search all boxes, open or not. What do you do with a bunch of messages once you've found them? They could just be selected, and then another command could do something with them such as reply or refile. Of course the scan window should be scrolled to make the first and last selected message visible, if possible, otherwise to make the first selected message visible; also when searching all boxes any that contain selected messages should be opened. Another possibility, instead of selecting all the messages, would be to create a new scan window and put them all in it. But I wouldn't like it if this scan window corresponded to a box, i.e. an automatic refile. If I want them refiled I'll do it myself. Thus this would require a new feature, "virtual mailboxes" and a message can be in multiple virtual mailboxes in addition to one real mailbox. That's probably too complicated. HyperTalk-like scripts. It's probably best if you don't take this suggestion seriously. Think about it again when you have AppleScript as a substrate to build upon. From mlc@EAGLE.MIT.EDU Thu Feb 21 13:22:41 1991 Received: from ATHENA.MIT.EDU by charon.MIT.EDU with SMTP id AA12935; Thu, 21 Feb 91 13:22:37 EST Received: from EAGLE.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA08775; Thu, 21 Feb 91 13:22:33 EST Received: from NETSERVA-MAC-25.MIT.EDU by EAGLE.MIT.EDU with SMTP id AA22127; Thu, 21 Feb 91 13:22:24 EST Message-Id: <9102211822.AA22127@EAGLE.MIT.EDU> Date: Thu, 21 Feb 91 13:22:22 EST From: mlc@EAGLE.MIT.EDU (Mark Curby) To: hoffmann@MIT.EDU (Ron Hoffmann), srz@ATHENA.MIT.EDU (Stan Zanarotti) Subject: TM-S 2.0 Cc: mlc@MIT.EDU (Mark Curby) Status: RO Now that TM 2.0 is stabilizing the time has come to start thinking about TM-S 2.0. I think Kerberos is the only issue, i.e. the only place where TM 2.0 and TM-S 2.0 may need to differ. Do you agree? I suggest the following plan for Kerberos in TM-S 2.0: - store password on the local machine - Re-authenticate w/ each connection - if Kerberos fails due to Mac time being off then put up a message like: "Kerberos authentication failed because the Mac's clock is off. Reset your Mac's clock to the correct time and try again. (In the Boston area you can call 637-1234 for time.)" What do you think? - mark ------------ Mark Curby MIT Network Services MIT Room E32-130A (617) 253-7725 77 Massachusetts Ave. mlc@eagle.mit.edu Cambridge, MA 02139 From mlc@EAGLE.MIT.EDU Tue Mar 12 14:56:25 1991 Received: from MIT.MIT.EDU by charon.MIT.EDU with SMTP id AA25283; Tue, 12 Mar 91 14:56:17 EST Received: from EAGLE.MIT.EDU by MIT.EDU with SMTP id AA13232; Tue, 12 Mar 91 14:55:50 EST Received: from NETSERVA-MAC-14.MIT.EDU by EAGLE.MIT.EDU with SMTP id AA06247; Tue, 12 Mar 91 14:55:34 EST Message-Id: <9103121955.AA06247@EAGLE.MIT.EDU> Date: Tue, 12 Mar 91 14:55:32 EST From: mlc@EAGLE.MIT.EDU (Mark Curby) To: hoffmann@MIT.EDU (Ron Hoffmann), srz@athena.mit.edu (Stan Zanarotti), pgalt@EAGLE.MIT.EDU (Phyllis Galt), jsolof@MIT.EDU (Jeff Solof), mibsr@mitvma.mit.edu (Marion Bagley), gettens@EAGLE.MIT.EDU (Jack Gettens), jafar@mitvma.mit.edu (Jafar Hosseinzadeh) Subject: TM-S 1.1 plan Cc: tjm@EAGLE.MIT.EDU (Tim McGovern), jon@MIT.EDU (Jon Rochlis), cec@EAGLE.MIT.EDU (Cecilia d'Oliveira), cavan@mitvma.mit.edu (Jeanne Cavanaugh), mlc@MIT.EDU (Mark Curby), comment-techmail@MIT.EDU, fizz@mitvma.mit.edu (Robyn Fizz) Status: RO For your information -- here is the plan for release of the new version of TechMail-S, v1.1. Please send me comments, questions, complaints, ideas, etc., etc. (see below for some background info) An article will appear in the April issue of the i/s newsletter announcing the new version of TechMail-S (v1.1), briefly describing the bug it fixes, and saying it will be available by May 1 as packets in the MCC, on the MCC server, and on Net-Dist. Right after TM-S 1.1 is released a letter will go out (via campus mail) to everyone with an email account on eagle, giving the same info. Drafts of the letter and article are available from pgalt@eagle.mit.edu (Phyllis Galt) by request. Steps: test TM-S 1.1d2 Stan builds TechMail-S 1.1 & installs TM font. Delivers to mlc. Stan installs complete source for TM-S 1.1 on MacAthena test TM-S 1.1 Jack verifies TM-S 1.1 source MLC builds TM-S 1.1 master distribution disk MLC provides Ron w/ copy of TM-S 1.1 master distribution to install on net-dist MLC provides MCC w/ copy of TM-S 1.1 master distribution to install on MCC server MLC arranges for duplication and packaging of 50 copies of TM-S 1.1 packets MLC delivers 50 copies of TM-S 1.1 packets to MCC Letter sent to people w/ eagle email accounts Background: TechMail-S 1.0 has a bug which causes it to work poorly on Mac IIci, IIsi, LC and FX models. It often hangs when sending or getting mail. This has made TM-S virtually unusable on these machines. A week or so ago we found the cause of the problem and developed TM-S 1.1d1 which fixed the problem. We tested TM-S 1.1d1 on a number of machines and found that it had a new bug, it did not look in the system folder for the configuration file. So we build TM-S 1.1d2 which fixes that problem. While the original bug is most evident on the Mac IIci, IIsi, LC and FX it may cause problems on any Mac model. We will recommend that all TM-S users upgrade to TM-S 1.1. - Mark ------------ Mark Curby MIT Network Services MIT Room E32-130A (617) 253-7725 77 Massachusetts Ave. mlc@eagle.mit.edu Cambridge, MA 02139 From mlc@EAGLE.MIT.EDU Wed Mar 13 21:23:48 1991 Received: from ATHENA.MIT.EDU by charon.MIT.EDU with SMTP id AA02275; Wed, 13 Mar 91 21:23:41 EST Received: from EAGLE.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA14930; Wed, 13 Mar 91 21:23:27 EST Received: from NETSERVA-MAC-14.MIT.EDU by EAGLE.MIT.EDU with SMTP id AA23244; Wed, 13 Mar 91 21:23:20 EST Message-Id: <9103140223.AA23244@EAGLE.MIT.EDU> Date: Wed, 13 Mar 91 21:23:22 EST From: mlc@EAGLE.MIT.EDU (Mark Curby) To: srz@ATHENA.MIT.EDU (Stan Zanarotti), hoffmann@MIT.EDU (Ron Hoffmann), pgalt@EAGLE.MIT.EDU (Phyllis Galt), mlc@MIT.EDU (Mark Curby), jon@MIT.EDU (Jon Rochlis) Subject: TM/TM-S 2.0 plan -- update -- Cc: tjm@EAGLE.MIT.EDU (Tim McGovern), cec@EAGLE.MIT.EDU (Cecilia d'Oliveira), thorne@ATHENA.MIT.EDU (Scott Thorne), kkkken@ATHENA.MIT.EDU (Ken Duda), gettens@EAGLE.MIT.EDU (Jack Gettens) Status: RO Here is what (I think) we decided in our TM/TM-S 2.0 meeting today. (Send corrections to mlc@mit.edu) > ==== List of things left to do as of 12 Mar 91: ===== no one had additions to this list > - rebuild TM 2.0a w/ new TestTracker library > - Stan should review TT library > - if username changes call TT w/ arg = true to > force TT re-registration approved > - what is plan for version server in released 2.0 A simple version of the version server client will be in TM 2.0. It will be a resource which can be deleted. It will only try one time in six - on average. When it tries it will wait 5 sec to hear something. we need to test to ensure that version server will not cause trouble for users on Fastpath-2s (packet size/fragmenting issue) > - what is time server plan? > what should kerberos time error message say? While we need a real solution someday... For TM2.0 we will contact the time server each time and calculate an expedient gmt-offset to use for this one session Configuration of kerberos servers and timed servers will be in a resource and hence configurable via resedit, not TM user preferences. > - TM-S 2.0a > - build it > - re-kerberos w/ each connection > - define kerberos time error message > - incorporate TM-S 1.1 fix TM-S 2.0 raises a number of issues. Our plan is not to plan to release TM 2.0 and TM-S 2.0 at the same time. We will worry about TM-S 2.0 after we have TM 2.0 stable. However, we will modify TM-S 1.1 (hello TM-S 1.1d3) to more gracefully handle reading TM2.0 settings files. (right now feeding a TM2.0 settings file to TM-S 1.0 or TM 1.x causes memory to be corrupted.) > - kerberize eagle user accounts Agreed that this must be completed before TM2.0 beta begins Ron will oversee making it happen > - support (non-kerberos) POP3 on both port 109 & 110 on eagle Agreed that this must be completed before TM2.0 beta begins Ron will oversee making it happen > - support in-reply-to field in TM2.0a ? nope, leave it for a future version > - fix remaining bugs (see below) yup, Stan will have all these fixed by 20 Mar 91 > - put in TM font of course > - alpha test not explicitly discussed > - update documentation: user guide & getting started guide Agreed that this must be completed before TM2.0 beta begins Phyllis will oversee making it happen > - beta test our present target date to begin beta test is 15 May 91 > - document instructions on upgrading to new version of TM should be part of the getting started guide -- maybe maybe the distribution should have separate folders for update v. new install Agreed that this must be completed before TM2.0 beta begins Phyllis will oversee > - document instructions on getting alpha/beta test versions from > test FTP this is needed for alpha test Phyllis will oversee > - decide TM2.0 source licence plan we all seem to be leaning towards an Athena/X-window model source licence mlc will send around some sample copyright paragraphs as options for review we should register our copyright > ===== Bugs remaining in TM 2.0a8 as of 7 Mar 91: ====== > - auto scroll incoming message window will be fixed > - can't access DAs on FX w/ sys 7.0b1 will be fixed - if not already > - local address list > - provide error msg, not bomb on 34th address > - handle too long addresses w/ msg not program error the limits have been raised but the behavior will remain poor if the limits are exceeded > - handle kerberos tickets expired politely - see hoffmann 7 Mar 91 > - i.e. ask for password again will be fixed > - add cancel button to "can not write mailfile' dbox will be fixed > - Tm2.0a8 dies at start on Mac FX w/ sys 7 will be fixed - if reproducible > - fix phyllis's new mailbox bug will be fixed > - fix mlc refile bugs (7mar91, TM2.0a8) will be fixed > - fix searching in listing (mlc 7mar91) will be fixed (note - fix will slow searches) > - change hesiod/pop server configuration in user preferences will be fixed ============ other ======== Our target date for beginning beta test is 15 May 91 Agreed we should invite David Moon to participate in our alpha test - Mark ------------ Mark Curby MIT Network Services MIT Room E32-130A (617) 253-7725 77 Massachusetts Ave. mlc@eagle.mit.edu Cambridge, MA 02139 From mlc@eagle.mit.edu Mon Apr 29 10:34:18 1991 Received: from ATHENA.MIT.EDU by charon.MIT.EDU with SMTP id AA02002; Mon, 29 Apr 91 10:34:14 EDT Received: from EAGLE.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA07877; Mon, 29 Apr 91 10:34:04 EDT Received: from NETSERVA-MAC-3.MIT.EDU by eagle.mit.edu with SMTP id AA00807; Mon, 29 Apr 91 10:33:44 EDT Message-Id: <9104291433.AA00807@eagle.mit.edu> Date: Mon, 29 Apr 91 10:33:41 EST From: mlc@eagle.mit.edu (Mark Curby) To: hoffmann@mit.edu (Ron Hoffmann), pgalt@eagle.mit.edu (Phyllis Galt), srz@ATHENA.MIT.EDU (Stan Zanarotti), tjm@eagle.mit.edu (Tim McGovern), jon@mit.edu (Jon Rochlis) Subject: TechMail 2.0 alpha test plan - 29Apr91 draft Cc: mlc@mit.edu (Mark Curby) Status: RO Below is an updated plan for the TechMail 2.0 alpha test. Please review it and let me know if you have any changes, additions, comments, suggestions, criticisms, etc. Particularly please let me know if I have overlooked anything. Thanks, Mark ------------ Mark Curby MIT Network Services MIT Room E32-130A (617) 253-7725 77 Massachusetts Ave. mlc@eagle.mit.edu Cambridge, MA 02139 ============================================== TechMail 2.0 alpha test plan as of 29 Apr 91 Things to do before open alpha test begins: - check TestTracker is logging properly (mlc) - check VersionServer will send messages properly (mlc) - check Kerberos (Ron) - when mac time is off - when tickets expire - complete document - how to get alpha versions from net-dist (Phyllis) - complete letter of invite (mlc) - complete alpha test plan (mlc) - get OK to proceed w/ alpha test from Tim & Jon (mlc) The above are expected to take about two weeks. Target schedule: 1 May 91 to 15 May 91. TechMail 2.0 alpha test plan: Audience: Volunteer. All of IS and Athena will be invited to participate via email message. TestTracker will be used to track who participates, how much they use TM2.0 and on what platforms. We will have to do some explicit recruiting or testing ourselves to insure TM2.0 is tested on all platforms. Distribution: Distribution will be via anonymous ftp from a "hidden" directory on net-dist. The Version Server system will be used to inform test users when updated test versions are available. Duration: The alpha test will continue until we have a version with no known bugs (i.e. no bugs appear in a two week test). My best guess from past experience is that there will be about 5 revisions during the alpha test. Each revision cycle takes about 3 weeks to confirm the bugs, fix them, and reissue a new version. Intermittent bugs can cause much longer revision cycles. The alpha test is expected to last 3.5 months. Target schedule: 15 May - 1 Sept 91. Responsibilities: Programming: Stan Zanarotti Reviewing and confirming bug reports: Mark Curby & Stan Zanarotti Reviewing and replying to comments: Mark Curby & Ron Hoffmann Monitoring alpha test usage and platforms: Mark Curby Distribution: Stan Zanarotti & Mark Curby Things to do during TM2.0 alpha test in prep for TM2.0 beta test: - select beta testers (mlc) - kerberize all eagle user accounts (Ron) - support pop3 on both ports 109 and 110 on eagle (Ron) - complete TM2.0 docs, including how to update to new version (Phyllis) - source licence plan (mlc) - complete beta test plan (mlc) - get OK to proceed w/ beta test from Tim & Jon (mlc) From mlc@eagle.mit.edu Mon Apr 29 11:44:49 1991 Received: from ATHENA.MIT.EDU by charon.MIT.EDU with SMTP id AA02079; Mon, 29 Apr 91 11:44:46 EDT Received: from EAGLE.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA11669; Mon, 29 Apr 91 11:44:38 EDT Received: from NETSERVA-MAC-3.MIT.EDU by eagle.mit.edu with SMTP id AA02046; Mon, 29 Apr 91 11:44:30 EDT Message-Id: <9104291544.AA02046@eagle.mit.edu> Date: Mon, 29 Apr 91 11:44:27 EST From: mlc@eagle.mit.edu (Mark Curby) To: srz@ATHENA.MIT.EDU (Stan Zanarotti), hoffmann@mit.edu (Ron Hoffmann) Subject: TM-S 2.0 plans Cc: tjm@eagle.mit.edu (Tim McGovern), jon@mit.edu (Jon Rochlis), pgalt@eagle.mit.edu (Phyllis Galt), mlc@mit.edu (Mark Curby) Status: RO Stan & Ron - Now that TechMail 2.0a seems relatively stable I would like us to begin moving TechMail-S 2.0 forward. I see the following four steps in the the initial development phase of TechMail-S 2.0. 1) define TM-S 2.0 2) develop TM-S 2.0d0 3) test and revise TM-S 2.0d versions 4) develop TM-S 2.0 alpha test plan The first step is to define the specifications for TM-S 2.0. I propose the following definition of TM-S 2.0: - TM-S 2.0 will support all the features of TM 2.0. - TM-S 2.0 will include the bug fixes from TM-S 1.1 - Kerberos: The Kerberos password will be stored on the Mac during the session. TM-S 2.0 will get new tickets with each transaction. - GMT time for Kerberos: Like TM 2.0, TM-S 2.0 will check the real GMT time and calculate an expedient offset from mac local time at the beginning of the first transaction of a session. The offset will be preserved for the remainder of the session. - TestTracker: Like TM 2.0, TM-S 2.0 will support TestTracker during testing. It will send info during it's first transaction. - Version Server: TM-S 2.0 will support version server similarly to TM 2.0. Does this definition of TM-S 2.0 seem right and reasonable to you both? Have I forgotten or overlooked anything? Are there any other differences between TM 2.0 and TM-S 2.0? Stan, How soon do you think we could have TechMail-S 2.0d0 (i.e. the first version will all design specs included)? Thanks, Mark ------------ Mark Curby MIT Network Services MIT Room E32-130A (617) 253-7725 77 Massachusetts Ave. mlc@eagle.mit.edu Cambridge, MA 02139 From mlc@eagle.mit.edu Tue May 7 13:01:44 1991 Received: from ATHENA.MIT.EDU by charon.MIT.EDU with SMTP id AA24014; Tue, 7 May 91 13:01:39 EDT Received: from EAGLE.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA18809; Tue, 7 May 91 13:01:32 EDT Received: from NETSERVA-MAC-25.MIT.EDU by eagle.mit.edu with SMTP id AA23433; Tue, 7 May 91 13:00:52 EDT Message-Id: <9105071700.AA23433@eagle.mit.edu> Date: Tue, 07 May 91 13:00:47 EST From: mlc@eagle.mit.edu (Mark Curby) To: hoffmann@mit.edu (Ron Hoffmann), pgalt@eagle.mit.edu (Phyllis Galt), srz@ATHENA.MIT.EDU (Stan Zanarotti), jon@mit.edu (Jon Rochlis) Subject: TM2.0 source license - options Cc: tjm@eagle.mit.edu (Tim McGovern), mlc@mit.edu (Mark Curby) Status: RO TechMail team - As we discussed at our meeting 13Mar91 we would like to make the source code for TechMail available starting w/ version 2.0. We were in general agreement that a system which allowed the software to be distributed freely via anonymous ftp was most desirable. This would be similar to how Athena has distributed their stuff. The idea would be to come up with a copywrite/permitted use paragraph which could be tacked on each source file, documentation, etc. As promised, I have collected a few examples (see below) as options for us to chose from. Please look over the alternatives and send me you comments, suggestions, worries, issues, etc. My vote is for the "mlc 7may91 option", modified ala the "MIT des option" where needed. I suspect that this discussion will need to expand beyond just the TechMail team finding a solution for TM2.0 source -- but, lets start it here. - Mark ------------ Mark Curby MIT Network Services MIT Room E32-130A (617) 253-7725 77 Massachusetts Ave. mlc@eagle.mit.edu Cambridge, MA 02139 =============================================================== mlc 7may91 option --------------------------------------------------------------- Copyright (C) 1991 by the Massachusetts Institute of Technology Permission to use, copy, modify, and distribute this software (source and binary) and its documentation for any purpose and without fee is hereby granted, provided that this permission notice and the above copyright notice appear in all copies, derivatives, and related documentation, and that the name of M.I.T. not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. M.I.T. makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. --------------------------------------------------------------- =============================================================== mlc 31jan91 option --------------------------------------------------------------- Copyright (C) 1991 by the Massachusetts Institute of Technology Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that this permission notice and the above copyright notice appear in all copies and related documentation, and that the name of M.I.T. not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. M.I.T. makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. --------------------------------------------------------------- =============================================================== MIT 12sep88 option --------------------------------------------------------------- Copyright 1987, 1988 by the Massachusetts Institute of Technology Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of M.I.T. not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. M.I.T. makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. --------------------------------------------------------------- =============================================================== MIT des option --------------------------------------------------------------- Copyright (C) 1989 by the Massachusetts Institute of Technology Export of this software from the United States of America is assumed to require a specific license from the United States Government. It is the responsibility of any person or organization contemplating export to obtain such a license before exporting. WITHIN THAT CONSTRAINT, permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of M.I.T. not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. M.I.T. makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. --------------------------------------------------------------- =============================================================== UC option --------------------------------------------------------------- Copyright (c) 1983 Regents of the University of California. All rights reserved. Redistribution and use in source and binary forms are permitted provided that the above copyright notice and this paragraph are duplicated in all such forms and that any documentation, advertising materials, and other materials related to such distribution and use acknowledge that the software was developed by the University of California, Berkeley. The name of the University may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. --------------------------------------------------------------- From mlc@MIT.EDU Tue Oct 8 17:40:59 1991 Received: from MIT.MIT.EDU by charon.MIT.EDU with SMTP id AA23323; Tue, 8 Oct 91 17:40:54 EDT Received: from WINDWARD.MIT.EDU by MIT.EDU with SMTP id AA09367; Tue, 8 Oct 91 17:40:44 EDT Message-Id: <9110082140.AA09367@MIT.EDU> Date: Tue, 08 Oct 91 17:40:45 EST From: mlc@MIT.EDU (Mark Curby) To: srz@charon.MIT.EDU (Stan Zanarotti) Subject: Re: tm 1.1.1 sources Cc: oreilly@netcom.ubc.ca (Dennis O'Reilly), tjm@eagle.mit.edu (Tim McGovern), mlc@MIT.EDU (Mark Curby), par@eagle.mit.edu (Peter Richards) Status: RO Stan - > Date: Mon, 9 Sep 91 14:08:30 EDT > From: srz@charon.MIT.EDU (Stan Zanarotti) > To: oreilly@netcom.ubc.ca > Unfortunately, the SLIP code and associated libraries are part of Stanford's > MacIP library. We managed to get permission to redistribute it in object > format, but not source code. I can answer questions about what packets > it sends out to get the IP address, though. > > -stan According to my files -- from email from Peter Richards of MIT's TLO of 14 May 90, and confirmed in a phone conversation w/ Peter today -- Stanford agreed to MIT's distribution of the SLIP code as part of our distribution of TechMail-S sources, provided Stanford's copyright notice appears on the SLIP source (See below). TechMail-S as a whole would be distributed under MIT copyright. The documentation should also acknowledge Stanford's contribution by carrying this same notice. ---- Stanford copyright notice for SLIP source code in TechMail-S ---- TechMail-S contains serial line internet protocol (SLIP) code which was developed and copyrighted in 1988 by Stanford University. Stanford makes no representations or warranties, express or implied. By way of example, but not limitation, Stanford makes no representations or warranties of merchantiability or fitness for any particular purpose, or that the use of the licensed software components or documentation will not infringe any patents, copyrights, trademarks, or other rights. Stanford shall not be held liable for any liability nor for any direct, indirect, or consequential damages with respect to any claim by licensee or any third party on account of or arising from this agreement or use of the program. ---- end - Stanford copyright notice for SLIP source code in TechMail-S ---- Please make sure the Stanford notice is on the SLIP code and then make the sources available to Dennis O'Reilly et al at UBC. Thanks, Mark ------------ Mark Curby MIT Network Services MIT Room E40-342G (617) 253-7725 77 Massachusetts Ave. mlc@mit.edu Cambridge, MA 02139