This is the latest version of our e-mail requirements list I could find
in the MUEMail list logs ...
John
Date: Wed, 19 Jan 1994 10:51:14 -0500
From: Allison Debra <[log in to unmask]>
Subject: Updated email mtg. notes/req.
This message contains updated requirements and meeting notes. Please note
our upcoming meeting schedule:
Wed. Jan. 19 1:30 in 2 Hughes, SoftSwitch presentation
Wed. Jan. 26 1:30 in Hoyt conference room, IMAP/POP team presents
Wed. Feb. 2 1:30 in Hoyt, Joe to present Microsoft solution.
Anyone receiving this message, and other interested people, are invited to
attend any of our meetings. Contact Debi Allison or John Harlan with
questions or comments.
Miami University Electronic Mail Meeting
held 29 November 1993 ; updated for 15 December 1993 meeting.
Present: Chris Allison, Debra Allison, Sarah Baker, Kent Covert,
John Harlan, Steve Moore, Peter Murray, Joe Simpson,
Steve Thole
--> indicates additions/changes
Terms: IMAP -- Interim Mail Access Protocol; client/server; all mail
resides on server but can be retrieved by client
from
desktop or remote locations (via dial-in or
Internet
connection)
POP -- Post Office Protocol; client/server; all mail is
downloaded from server to desktop, where it is
stored
and manipulated; can only be retrieved from desktop
(or via fancy connection to desktop via AppleTalk
Remote Access or similar software for other
operating
systems?)
Required / Desired Features & Functionality
[E denotes enterprise-wide applicability; C denotes client]
E 1. Interoperability, standards-based (currently SMTP)
- clients need to interoperate with enclosures
E 2. Server stores mail and address lists
E 3. Ability to forward (i.e., redirect) mail automatically (i.e.,
the enterprise server is capable of redirecting e-mail to the
user's desired client)
- presently possible with Pegasus Mail but not Microsoft Mail
E 4. Ability to read e-mail from anywhere:
- desktop
- dial-in from remote location (home, while traveling, etc)
- Internet connection (ditto)
E 5. Universal directory service, including:
- easy way to look up addresses
- distribution lists on server to free up desktop / client
resources
- ability to build own distribution lists
- ability to activate / deactivate a directory address, at
the request of a user
--> - Directory synchronization, so that someone added to a
departmental/divisional server automatically appears in the university
directory.
E+C 6. 'Rich enclosure' capability
- easy to use
- MIME compliant
[Note: SoftSwitch, which converts/translates document
from sender's preferred application format to recipient's
preferred application format]
C 7. Common platform support; not --> (necessarily) a single solution,
but multiple solutions which support all client targets, including:
- Macintosh
- Windows & Windows/NT
- DOS
- OpenVMS
- VM/CMS
- UNIX
- OS/2
--> We should not have multiple solutions per platform; fewest possible
products and vendors to contend with, even at the cost of some bells and
whistles.
C 8. Notified mail (i.e., desktop notification of mail arrival)
[Desired: choice to "disturb recipient" or "do not disturb
recipient"]
E 9. Scalability (the ability to handle up to 20,000-30,000
potential users)
E 10. Account administration / management (and ease thereof):
- batch capability for adding and deleting users
11. Ability to request acknowledgement that message has been
read
12. Ability to print hardcopy of unread messages and send to
recipient (i.e., for persons who have not activated their
e-mail accounts)
--> 13. Efficiency (in terms of delivery) and cost for hardware/software,
implementation and maintenance.
--> 14. Strategy for dealing with student mail.
Concerns:
- account administration; roving students; transient nature.
- student services needed: distribution of class lists.
- Students don't have a single point of entry.
- Training
- What will students not be able to do that faculty/ staff
can? What will differentiate faculty/staff services from student services?
- Requirement for ability to send students' projects to
faculty.
In general: - want tighest possible coupling between e-mail directory
service and mail client software
- ability to make environment look the same in office or
at home (i.e., through use of AppleTalk Remote Access
type software)
Client (desktop) Issues: - sequential routing with branches to allow
parallel processing
- mail filtering rules (services
available in
the client environment that are
not
available on the enterprise level)
- acknowledgement generated when
message
is received and/or read
- shared calendaring
--> - Ease of use at the desktop
Next steps: - flesh out and refine these requirements, and meet again
- one group to examine client solutions as measured
against enterprise solutions
- another group to examine enterprise services
Parting thought: 'Mail is an action I can perform on anything on my
desktop'
--> Notes from 12/15/93 meeting:
- SoftSwitch for MVS, VM and UNIX - X.400 store and forward system.
Directory services - keep data base in sync on each email server. Can handle
large address databases. Provides document conversion and preserves
formatting. Doesn't store email on the server (no IMAP capability). Unique
features: document translation; gives enterprise-wide directory services to
each of our mail packages. Can cooperate with POP and IMAP.
--> Results from 12/15/93 meeting:
Sub-groups will research and present various options to the entire group.
1. IMAP/POP - Post Office centrally for university with IMAP and POP clients
where possible, and mail forwarding to VMS and other places where not
possible to have clients. Issue: add POP later? Just look at IMAP for now.
PHQUE for directory serviceds and any good UNIX mail forwarder?
Layers: IMAP as central server; PMail Server; VM mail server; MS Mail
server; desktop.
IMAP/POP Team: Peter Murray, Kent Covert, John Harlan. Will present this
option at our Wed. January 26 meeting at 1:30 in Hoyt.
2. Microsoft solution or a pure P-Mail solution: Joe Simpson to present at
our Feb. 2 meeting at 1:30 in Hoyt. He will try to get Doug Brennan and
Microsoft tech person to attend.
3. SoftSwitch Team: Steve Moore. He will have SoftSwitch rep come to our
Wed. Jan. 19 meeting at 1:30 in 2 Hughes.
4. X.400 and X.500 Solutions: We need to designate someone to research
this. Steve will send out latest FAQ on X.400.
This committee will come up with a recommendation to present to the
Microcomputer Committee, Kris Froehlke, and the Policy Committee (?) as
deemed by Kris.
John B Harlan Campus Wide Information System (CWIS) Coordinator
& Client Services Liaison for Networking, UNIX & VMS
Miami Computing & Information Services (MCIS)
Miami University
137 Hoyt Hall
Oxford, Ohio 45056-1618 USA
513 529 5330 voice 513 529 1496 fax
[log in to unmask]
|