Alan's Gateway Project

AOL IM <-> EMAIL Gateway

Concept -- Specifications -- Work Needed -- Downloads -- Contact Info


This project has been under discussion since late January 2000. The driving force is that it is easier to send an IM than an email for many users, specifically me (Alan) when I'm at work. Yet some people prefer to receive an email than an IM, and some are not active on AIM.


Goal: Provide the ability to send quick messages via AIM whether the user is online or offline. Additionally, to send URLs (using AIM) to those people who do not wish to receive them via AIM.
Scope: Provide a gateway between AOL's Instant Messanger client and standard Internet email. Ideally bi-directional, but initially IM to Email.
Description: There will be a client (details TBD) which sits on AOL's Instant Messanger system. That client will wait for an IM to come in and will act on the message according to the sender and the content.
Objects: 1) Sender. Each sender will be registered with the system "offline" (e.g. through a web-based or command-line program.
2) Recipient. Each recipient will be registered with the system. The recipient may be registered uniquely within the system, or may be registered to a particular Sender. The Recipient can be registered offline or "online" at runtime.
Details: There are three kind of messages within the system:
1) Sender to System. These messages are described under "Message Formats" below.
2) System to Sender. These messages are related to confirmation requests. The system should confirm "cancel" and "delete" messages.
3) System to Recipient. There are two subsets of this message, Email and IM.

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?).

Work Needed:


None yet. What did you expect?

[Future Link to AIM Clients] Perl AIM Module Net-AIM or Net-AOLIM
[Future Link to Jabber Clients / Project]
[Future Link to ICQ Clients]who cares? :-)
[Future Link to MSN Clients]who cares?


Volunteers should contact Alan Danziger. Please provide an idea of how much experience you have working in an Instant Messanger environment, what/which environment, and/or details on how you can (or would like to) provide Added Value to the project.

Also extremely useful is feedback to this project idea, and to the details included within.
"Need bandwidth, will code."