Outline

Background

o Mission Critical Messaging Requirements
o MCM Reliability vs. Architecture
o The Open Internet Messaging Architecture
o Sample Architecture


The Role of IMAP

o IMAP: What is it?
o IMAP Features
o IMAP History
o IMAP Status
o IMAP Implementations
o Real-World deployment: UW Case Study


The Role of ACAP

o Scalability and Administrative Flexibility
o Partial Answer: ACAP as Mail System "Glue"
o ACAP History and Status
o ACAP Illustrated
o What's Still Missing? Administrative Agents
o Real-World deployment: CMU Case Study

1. Background...

• Mission Critical Messaging Requirements

• The Open Internet Messaging Architecture

• Sample Architecture

MCM Requirements

• Interoperability

• Reliability

• Scalability

• Maintainability

• Security

• Usability

• Administrative Flexibility

MCM: Reliability vs. Architecture

• Reduce size of "fault zones" --> "Horizontal Scaling"

• Reduce "single points of failure" --> Redundancy

• Reduce complexity, heterogeneity --> Avoid gateways; use Internet standards

• Gradeful degradation, failure --> Time outs, retries, DSNs

The Open Internet Messaging Architecture

• ESMTP -Mail transport

• NNTP -News transport

• RFC822 & 1036 -Header definitions

• MIME -Content encoding & labeling

• DSNs -Delivery Service Notifications

• POP, IMAP -Remote mailbox access

• ACAP -Remote configuration access

• LDAP, WHOIS++ -Directory access

Sample Architecture

2. The Role of IMAP...

• IMAP: What is it?

• IMAP Features

• IMAP History

• IMAP Status

• IMAP Implementations

• Real-World deployment: UW Case Study

IMAP: What is it?

• The Internet Message Access Protocol

• Protocol for manipulating remote message stores

• Foundation for client-server messaging infrastructure

• Allows access to mail store from multiple computers

• IETF standard's track

IMAP Features

• Support for online, offline, and disconnected operation

• Selective access to MIME body parts

• Access to multiple mailboxes, potentially on multiple servers

• Support for folder hierarchies (i.e. nested mailboxes)

• Standard and user-defined message flags

• Shared/concurrent access to folders by multiple users

• Server-based searching and selection

• Support for advanced authentication techniques

• Provision for protocol extensibility, e.g. Annotation

IMAP History

• 1986:
  o IMAP conceived at Stanford University
  o Interlisp client and DEC-20 server implemented
  

• 1987:
  o IMAP2 defined; client & server updated
  o First Unix server implemented
  

• 1988:
  o First IMAP RFC published in July (1064)
  o Initial work on C-Client library
  

• 1989:
  o Crispin hired by University of Washington
  

• 1990:
  o Revised IMAP2 RFC published in August (1176)
  o C-Client based Unix server in November
  

• 1991:
  o MIME support added, forming basis of IMAP2bis
  o IMAP3 offshoot published in Feb. (since abandoned)
  

• 1992:
  o IMAP2bis server deployed by UW
  o Pine 2.0 released with IMAP support
  o CMU begins AndrewII/Cyrus project
  

• 1993:
  o IMAP2bis I-D published in August
  o First VMS server implemented
  o IETF IMAP Working Group formed
  

• 1994:
  o IMAP4 approved as Proposed Internet Standard
  o IMAP4 RFCs published (1730-1733)
  

• 1995:
  o First IMAP4 server released by CMU
  o IMAP4 C-Client and server released by UW
  

• 1996:
  o www.imap.org site started by UW
  o 1st & 2nd annual IMAP meetings held :)
  o IMAP4rev1 specified
  o IMAP4rev1 servers released by CMU and UW
  o At least six commercial IMAP4 servers released
  o IMC hosts first IMAP interoperability bakeoff
  o IMAP embraced by Microsoft, Netscape, many others...
  o Product announcements > 3x all previous years combined
  

IMAP Status

• IMAP4rev1 is latest specification

• IETF Proposed Standard

• Rev1 RFCs available soon

• Tremendous vendor interest

• ISP support is still limited

IMAP Implementations

Servers...

• Unix: CMU, UW, Netscape, Digital, Sun, CDC, Isocor, ...

• VMS: Innosoft

• NT: Digital, Netscape, ...

Clients...

• Unix: Pine, Ishmail, Simeon, ZMail Pro, ML, MMail, Solstice, ...

• VMS: Pine

• NeXT: EasyMail, Eloquent, MailManager, Mynah, Pine

• Lisp: MM/D, Yes-Way

• OS/2: Pine

• Macintosh: Mail_Drop, Mailstrom, Mulberry, Simeon, Siren

• Windows: PC-Pine, Simeon, Siren, Solstice, ZMail Pro, Pronto, ATISmail, EMBLA, Orpheus

• Coming Soon: Netscape Navigator, MS Internet Explorer

Real-World deployment: UW Case Study

• Over 50,000 user accounts

• 500,000 messages/day

• Peaks above 20,000 msgs/hour

• Directory: homebrew, probably moving to LDAP

• Security: PGP, probably moving to S/MIME + X.509

• Needed: robust/scalable/standards-based client-server email architecture

• IMAP has served UW very well

• Looking forward to ACAP to complete the picture...

3. The Role of ACAP...

• Scalability and Administrative Flexibility

• Partial Answer: ACAP as Mail System "Glue"

• ACAP History and Status

• ACAP Illustrated

• What's Still Missing? Administrative Agents

• Real-World deployment: CMU Case Study

Scalability and Administrative Flexibility

Key issues:

• How do you administer tens of thousands of users?
  - growing number of users, # messages stored

• How can the mail system expand arbitrarily?
  - add servers, services without segmenting users

• How can new services be layered on top?
  - mailing list management, message processing, etc.

Part Answer: ACAP as Mail System "Glue"

• ACAP = Application Configuration Access Protocol

• Successor to "Internet Message Support Protocol"

• A network repository for lightly-structured lists

• Applications:

  • Any client-oriented data (bookmarks, preferences, newsrc, etc.) can be stored

  • Data like this can be _shared_ with access control lists

  • "Brokerage" of locations:

    • IMAP allows multiple servers to be accessed by a single client session

    • Data of individual users can technically be arbitrarily broken up over many servers

    • ACAP provides a mechanism for locating multiple message sources

ACAP History and Status

• First version, IMSP, implemented 1995 by CMU and Esys
  - currently available, _works now_ for user data
  - in final revisions to do location brokerage

• ACAP revised 1995-1996, new protocol spec. fall 1996

• IETF working group December, 1996

• Server and client library available January - Feb 1997

• Vendor support from some major players...
  - At least three vendors plus CMU, UW doing implementations
  - First user applications in spring of 1997

ACAP Illustrated...

What's Still Missing? Administrative Agents

• Applications and/or servers to administer message stores,
  users, user identification and authentication databases

• MADMAN work in IETF - nothing concrete at this writing

• Individual vendors provide partial pieces
  [i.e. Netscape administrative applications]

• Much can be automated or customized, but requires
  knowledgeable programming and administration staff

Real-World deployment: CMU Case Study

• Scalability in a different direction - shared mailboxes

• CMU's "Integrated Messaging Model"

• 34,000 shared folders from varied sources:
  - Shared resources converted to IMAP store
  - Netnews, Dow-Jones, AP news wire, other services
  - System logs and other applications
  - 8000 "local" bulletin boards
  - User-created, administered "private" bboards

• Access to all shared message stores through IMAP clients

• In public deployment since July 1996, semi-public since 1994

• Peaks (as of September 1996):
  - 400 simultaneous users
  - 19000 daily user connections
  - 200000 weekly user connections
  - 140,000 messages a day stored
  - 1 million messages a week
  - Over 2 million stored at any one time
  -- on a single server (Sparc 20, 128 megs of RAM)

• Users have a choice between IMAP and POP, use IMAP at a 5:1 rate

For More Information...