Mail Agent Protocol
Mail Agent Protocol
By Dave Winer, dwiner@well.com
We document the current mail agent protocol implemented by Eudora and Frontier, and suggest a framework allowing other mail clients to hook in.
Eudora 2.1 and later versions implement a simple protocol that allows other applications to access the flow of ingoing and outgoing messages. This flow is used by several Frontier suites that capture mail messages and store them in searchable databases or to flow the text to a website.
With new interest in the email community, new clients coming from other vendors, it's a good time to document the protocol, with an eye towards supporting multiple mail clients and moving towards a cross-platform protocol.
This spec is targeted at two audiences:
- People who are implementing scriptable email clients and
- Script writers who want to build systems out of scriptable email clients.
We're documenting this project as part of the MIDAS process to be open about how we're working with email client vendors to develop a uniform interface for processing email. All our work is clone-able and open.
If other scripting environments wish to adopt these standards, nothing stands in their way. All the software needed to test compatibility is free. You must have a Mac to run the software at this time.
From the mail client side
The mail app must provide scriptable mechanisms that allow a caller app to:
- Turn notification on and off.
- Given a message identifier (format up to the mail app) provide the caller with the fields of the message: subject, date, sender, message text, etc.
- If notification is on, send a message to each registered app, indicating whether the message is incoming or outgoing, and provide a list of message identifiers.
The eNot Apple Event
Following the convention implemented in Eudora 2.1, the notification message id is eNot, and the class of the message is the application id of the mail client app. See mail.traps.CSOmeNot for the handler for the Eudora notification message. All other mail clients should install a similar trap handler.
The eNot script is called when Frontier receives an Apple Event whose class is CSOm and whose ID is eNot. It receives two parameters, whatEvent and theList.
whatEvent can take on one of five values, all of which are OSTypes: wHCn, wArv, wSnt, wFil and wWcn. In our scripts, we only pay attention to 'wArv' (a list of incoming messages) and 'wSnt' (a list of outgoing messages).
theList is an Apple Event list, containing message ids (we call them cookies, of course), that can be passed back to the email client, one at a time, to obtain information about a message. It's entirely up to the app to determine the meaning of the elements of this list. We pass them back without interpretation.
For now, all handlers should call mail.init, to make sure that the proper tables exist and that the handlers have been installed. At some point in the future we may move this functionality, but mail.init will be supported for the indefinite future.
The eNot script loops over all the elements of the user.mail.agents table, calling all the scripts. The scripts are told which email client generated the call. This means that script writers can have multiple applications hooked into the mail flow, and these scripts will work across all compatible mail client apps.
suites.mail.drivers
The other required element for supporting the mail agent protocol is a sub-table of suites.mail.drivers. I've supplied the driver table for Eudora. Each driver table contains two scripts, getMessageTable and setNotification.
getMessageTable takes two parameters, a message id (called a cookie) and the address of an object db table. It fills the table with information about the message that the cookie points to.
setNotification takes a boolean parameter which indicates if message notification is to be turned on or off.
A tour of the framework
After discussion on the MIDAS list, people want to see what the framework looks like without having to install Frontier. That's OK with me. The listings are on the Mail Framework page.
This is not just a spec for Apple Events. It's a framework for running scripts written in any OSA language behind any mail client, or even multiple mail clients running at the same time. The framework requires a structured storage system, such as Frontier's object database. To our knowledge, only Frontier implements a system that can store scripts and data as needed to implement such a framework.
It's important, once again, to point out that Frontier can host any OSA-compatible scripting language. Check out our [Macro error: Can't find a sub-table named "#ftpsite".] page for details.
We implemented this framework and protocol in Frontier 4.1. You can download Frontier from its website.
|
This page was last built with Frontier on a Macintosh on Wednesday, August 27, 1997 at 7:37:38 PM. Thanks for checking it out! Dave |