0) HELP
This message will generate a response of a "Usage Summary" including a URL for full information.

1) +Username [global] <MAIL | AIM> <address>
This is how the Sender can register a Recipient at runtime. The plus sign denotes that we are adding a recipient. "Username" is the Recipient tag (MUST be unique for this user. SHOULD be unique within the system?). The 'global' tag may be used to denote a system-wide user, e.g. any Sender can send to them. (Perhaps this would be useful to provide access for non-registered Senders?)
The tag "MAIL" denotes that the <address> is a standard internet email address, e.g. user@host.dom
The tag "AIM" denotes that the <address> is an Instant Messanger name. (Perhaps this would be useful to queue messages until the User comes online? Or to email messages if the user is not online but relay them directly if he or she is online?)

2) +Username [global] AIM aim-name FALLBACK MAIL user@host.dom
This would resolve the case where the Recipient should have messages relayed if they are online but emailed if they are offline. The order of AIM and MAIL when FALLBACK is included is potentially meaningless. At least I see no point to it at this time.

3) Username - <message> [\]
If the user is online with the name they have been registered using (e.g. AIM aim-name) than a new AIM message will be composed <Sender> <message> and will be sent to the user. "\" is ignored in this case.
If the User is offline, or no AIM handle is available for the user, an email will be composed. If there is an email pending (e.g. the previous IM from this Sender for this Username did not end with "\") this IM will be appended to it. The message will be sent when Sender sends Username a message without a trailing "\", when a particular message size is reached, or when a particular time period is reached without an additional IM.

4) Username CANCEL
This message will cancel a pending email message. Potentially by sending back an IM saying "Enter -yes- if you really want to cancel your email to Username". It will do nothing if there is not a pending email message from Sender to Username.

5) Username DELETE
This message will remove Username as a recipient associated with Sender. It may also prompt for confirmation.

Sender. A Sender must register with the system, and certain information should be stored in the system about this type of user. Some potential information is:
1) Email address.
2) AIM Name.
3) Message Preference (user to Sender) [AIM, Email, or Fallback (with order?)]
4) Recipients.
5) Password. For changing data.
6) Private? flag (see #7).
7) Possible Senders (in the event of a Private user).

Recipient. A Recipient must be registered with the system, either by him/herself or by a Sender. Every Sender is also a Recipient; every Recipient is not a Sender. There should be some way of determining priority between Recipients and Senders when the name {is | isn't} already registered in the system. Perhaps this can be done through the concept of a "Local Recipient" vs. "Global Recipient" (e.g. tying a Recipient to a particular Sender). Some information needed is:
1) Email address (can be NULL if AIM Name is not NULL).
2) AIM Name (can be NULL if Email Address is not NULL).
3) Message Preference (Sender's setting overrides in the event that Recipient is a registered Sender?).