dkovar@VAX.BBN.COM (04/17/88)
From the discussion that we've been seeing on info-appletalk and some personal mail message I've received I have the following impressions: 1) Many people want some way to send mail from their Mac to their favorite mainframe. 2) Many people lack the resources to do it on their own. 3) Many people would like this to be as cheap as possible. 4) It should be well supported. All of this adds up to a system that will support SMTP, POP, and a few other odd mail protocols, that will run over Appletalk, Ethernet, and serial lines, that is written by competent programmers who aren't going to vanish after having written 90% of it, and that is easy to license and easy to get. Various local implementations exist. Stanford just announced that their Telenet package will include some mail services. CMU is working on a system to tie Macs into the Andrew mail/messages system, Dartmouth has a system set up using dropboxes tied into their campus mail system, and CITI apparently ported some unix code over to the Mac that sits on top of the TCP/IP drivers. As far as I know, none of these are complete and only the Stanford one will really satisfy anyone else's needs. I suggest two things: 1) That those people interested in such a system define their own needs in detail. Stating that you'd like your Mac to talk to your local UNIX machine isn't enough. What mail protocols do you use, what network protocols, what machines you're talking to with your Mac and, perhaps most importantly, what do you want your user interface to look like. Should it provide its own editor? How should the local mailbox be handled? How about dropboxes? Go wild as it is usually easier to prune out the far out ideas than add them in after the fact. 2) That those people interested in getting it done try and figure out how to get it done. The response has been quite impressive so there is definitely a want if not a need. With the backing of all these people we could certainly go to one of the companies selling Macintosh based mail systems and say "Look, these companies and these universities would like, and would pay for, software that provides these services." Something might happen. You'd also end up paying "real money" to get it done. The ideal system would be public domain with source with the normal "you may use it but you cannot sell it and please send any enhancements back to us" restrictions. Is there a good way to get this done? Can I make myself a non-profit organization and do it? Can we find some university that is willing to take this on? Seems like we need a Consortium Development Group. I'm just tossing out ideas at the moment. Please respond to them, either to the group or to me personally and I'll collect and summarize them. -David Kovar DKovar@BBN.COM
joachim@iravcl.ira.uka.de (04/19/88)
There has been an ongoing discussion about Macintosh mail systems in the
past days, and as David suggested, anyone should state his/her
requirements.
The following text will outline the requirements/interface that I see. This
is not intended to be a full spec, although we are thinking about
implementing it. I am a student of computer science at University of
Karlsruhe, Federal Republic of Germany, and I am involved in Macintosh
projects at that university. I am a computer consultant, too. There is no
big difference between the requirements at our university and large
companies in Germany.
1. Macintoshes are turned on and off frequently, and may be off for long
periods of time (e.g. during holidays). Mail must not be returned
UNDELIVERABLE because of that. This implies that there must be a mail
server. Because most universities and companies already use a
UNIX/VMS/other host for mail, using this host to serve Macintosh mail is
the most likely solution. This does not imply however, that s/he is
allowed to login to that host.
There are a number of possibilities, how the Macintosh front-end might
communicate to the host, two of them are MacWorkstation and an
AppleTalk service (based on CAP, AlisaTalk, ..), others might be SMTP,
NNTP which I am not familar with. The protocol may be proprietary,
because it is only used to communicate to the mail server, not to the
world.
Of course if Apple released their specification of the AppleTalk Messaging
Protocol (Larry Taylor of Apple talked about it at EUC Heidelberg, April
8th, 1988), I'd go with that, if it suits all needs.
2. There must be a unified interface to mail and news, like the integration
present on unix hosts. I don't want to use a mac application to read/send
mail and another one to read/post news - or even worse, login on to
(different) host to do that. The application should also support digests
(whether received by mail or news), and interpret reply or followup
sensibly, i.e., reply to the originator of the message, not to the sender of
the digest, mail followups to the origin of the digest.
3. Unlike the present mail applications, INBOX and INTERMAIL one cannot
assume that all possible recipients are known to the mail server. This
could be reasonable for one university or company, but not with the
internet behind. Of course, if your site already has a nameserver, the mail
application should be able to lookup local mail addresses by name.
4. One cannot assume that anybody is going to use a Macintosh to read
her/his mail. This has two consequences:
First, if files are to be transferred - and there is definitely a need to
include support for that - they must be included in a way that allows them
to be extracted manually and processed by some other tool. A simple but
sufficient solution is to include them binhexed, each preceeded by a line
standard mail will read this just as he always did and fire up binhex or
stuffit. A user using the mac mail will read a message that this mail
contains files, and choose extract from the file menu...
Even if I am using a mac to read mail, I may want to process/archive files
on the host. Someone might have mailed me a shar archive for use on the
(unix)host, or I may use unxbin on a unix computer and store the files
directly to AUFS volumes (that's how I install new stuff).
Second, there must be a character set conversion included. If you are only
going to mail in English, this is not required. If however, you receive mail
from any country, this is important. Imagine German umlauted characters.
Of course these characters are included in the Macintosh character set.
But they aren't ASCII. If I know that the recipient of the mail is using a
mac too, and that the mailers in between don't discard characters with the
eigth bit on, I may send the character unchanged, otherwise it has to be
mapped to the closest ASCII equivalent, possibly combined by several
characters. Alternatively, some other German user is using the German
version of the ISO character set. This is ASCII with the special characters
[\]{\}~ replaced by German characters. I want to tell my Macintosh that
any mail received from this user is to be interpreted using that character
set. Another example: VAX/VMS supports multinational characters using an
ASCII extension, proprietary to DEC.
The point is, that there must be a possibility to convert both incoming and
outgoing characters, depending upon the sender/receiver and/or system
defaults. I emphasized this point, because this is crucial to our
environment - you won't sell your mail program in Germany, if the user
gets beeps or garbage typing umlauted characters. Of course this is a
marketing decision.
Most of the points above are technically, not related to the user interface.
The following highlite some of the user related aspects.
5. It should include an editor. It does however not need to be a full blown
word processor. If you want to pass your new novel to another mac user,
include the document as an attached file. Anything within the range of
TeachText and MPW Shell is possible. No styles or justification is required
(imagine an IBM PC user, reading your letter on his monochrome card), but
font and size should be user selectable. Word wrap should be automatic,
based on charcter count, not on the window size.
The program should be able to manage arbitrarily large files. This may
however be limited to viewing/archiving them, not editing. The largest
mail I received was 2 MB and consisted of a uuencoded tar archive. Of
course this mail was to be decoded by unix tools, but you don't want your
mac to crash because of a large mail.
6. It has become a habit to comment on text by preceeding it with some
special character like > and inserting new text. While this is not the only
way to point out what you are going to reply to, and especially the mac
could provide a more graphic feedback (at least different fonts), this
technique is common sense. If the user chooses a function like reply, the
macintosh mail program should copy selected text (discontinous
selections should be supported) to a new window and mark it as comment.
7. The program must provide for a list of name aliases. This should be
entirely transparent to the rest of the program. I.e. there should be no
special dedicated menus, but editing the list should be allowed whenever a
mail address is required and selected from the list. Selection should be
possible by both scrolling/clicking or typing as in standard file. New
aliases should be created automatically if you reply to mail. There must be
an option to delete no longer used names.
8. While incoming mail should be presented in separate windows
automatically, this may not be appropriate for news. A scrolling list of
items that can individually or collectively be opened or discarded comes
to my mind. There should be either no (prefered) or a very large limit to
the number of open windows - aren't you bothered by the finder's limit of
12 windows?
9. There must be an automatic archive feature. I want any incoming mail to
be saved automatically, say in a folder named after the sender and with
the filename taken from the subject. There should be a flag associated
with each newsgroup, whether it should be archived (local or remotely) or
not, and this flag should be independent from whether I want to read it or
not - I don't read binaries.
There should be an option that asks me where to put the file and when it
should be resubmitted. I consider this to be an important feature if mail is
going to be used in your administration. This will also provide a simple
reminders utility, although a real appointment calendar is more superior.
10. There should be an INIT that checks for mail on startup (this could be a
RDEV that selects among several mail hosts). There should also be a
possibility for the mail host to tell you about new mail arriving during
your macintosh work. This could be done using the broadcast mechanism I
published in the past (you can get it free, send mail to
ry77@dkauni11.bitnet, I'll mail it to you).
Joachim Lindenberg, University of Karlsruhe
Federal Republic of Germany - West Germany.cetron@utah-cs.UUCP (Edward J Cetron) (04/20/88)
> I'm just tossing out ideas at the moment. Please respond to them, >either to the group or to me personally and I'll collect and summarize >them. > >-David Kovar > DKovar@BBN.COM I think the first question to answer is the physical distribution method. If every Mac is directly connected to a VMS/UNIX box, I know of at least one (maybe more) Public Domain packages which will work. I also know of several Appletalk-only Mac to Mac systems (Intermail, Inbox, TOPSsomething, etc). What I DON'T see is a mechanism which: 1. can be used Mac to Mac via localtalk transport. 2. can ALSO be used Mac to ??? via localtalk to ethertalk. My suggestion (and yes it is just MY suggestion based on our facilities preferences after trying lots of mailers on the Macs AND the two flavors of vaxen): 1. use 'standard' SMTP as the transport mechanism from ??? mainframe to a centralized Mac. Currently, Mac-PMDF seems to be the most versatile package for this. What needs to be added is the transport via ethernet to localtalk for those sites, serial line support is already there. 2. use Intermail as the Mac to Mac package. 3. write the code and hooks to gateway the mail from Mac-PMDF to Intermail. This will likely be the hardest part. Also, if a very clean job is done here, many other Mac-Mac mailers could be added here. Well, that's my two cents worth....now if only I could find to time to check how reasonable the above is.... maybe Microsoft (who know owns Intermail) would be interested? -ed cetron@cs.utah.edu