Auto Responder

January 12th, 2012 (updated September 24th, 2014)

The automatic email responder is a system for accepting emails and text messages and generating responses for them automatically.IMG_0223

Architecture

A majority of the architecture of the Auto Responder is shown in the following image.

Auto Responder Architecture

The Auto Responder program runs as a Windows service. It has one thread that runs continuously and polls an IMAP server for email messages. I had been using the POP3 protocol and a POP server but that required a new connection every time I polled the server. IMAP is a protocol that can handle a continuous connection to the server and it allows me to use a 5 second polling time. When a phone does send and receive SMS to email messages quickly, my system responds very quickly and a user can sometimes get a response within 10 seconds of sending their message. The Auto Responder also has numerous threads running for making SMTP connections. Some or all SMTP servers disconnect after each email is sent. They do not stop a client from making multiple connections simultaneously so I have a queue for each of many SMTP handler threads. Emails are placed in the shortest queue and sent to the server as quickly as possible. In addition to email support, the Auto Responder also accepts direct SMS text messages. The Twilio service is used as a phone number destination for text messages. Twilio uses the Auto Responder system as a web service server to send SMS messages and to accept responses to them. Twilio is also used as a web service server to send SMS messages directly from the Auto Responder acting as the client. SMS text message handling is quicker than email handling and is not reliant on any text-to-email services.Try it. As of March 13, 2013, the SMS phone number 775-***-**** (send me a note if you want to get the number!) is working and sending a text message with “test” in it should get you a response that is similar to “You are not a registered user but the test completed successfully.” A few year from now, that number may no longer be available.To get status information from the Auto Responder, a web page is available that mimics the IOS (iPhone) user interface (shown way above and below). Although there is a single PHP file used for the entire web interface, it is used to display many different pages of information such as a message log of all incoming and outgoing messages. JavaScript is used to asynchronously send and receive data to keep the pages up-to-date. If a new message comes in and is handled by the Auto Responder, the message page will show the message within a few seconds of the event.IMG_0077_thumb[1]

The Message Page

Another feature of the Auto Responder Windows service is the ability to accept a socket connection from another process on the same system. The local socket connection is used to get an email broadcast request from the web interface through a PHP script and then use the Auto Responder service to send the message to all known email addresses. The local connection port is also used for the SMS messaging described earlier. It is possible to see all messages in the log or those for a specific team or user. The user list is shown below. There are also notifications in the message log about errors and other system information such as when the service program starts or when one or more of the email connections fails.IMG_0078_thumb[1]

The User Page

The XML file containing the automatic responses, server locations and ports, and some other information, can be edited on the configuration page. The data is obtained at the moment the page is displayed and AJAX is used to send the update request when the user clicks or touches the update button. The configuration page includes the user list that is updated whenever a user registers or un-registers.IMG_0080_thumb[1]

The Configuration Page

Editing the XML data for these configuration items is not the most robust mechanism for maintaining these things but is acceptable for an administration page not seen by any typical user. A fancier system is not needed for these management tasks at this time.

Puzzle Race

The entire idea was based on the text messaging “feature” of a puzzle race I attended for the last three years in San Diego. A puzzle race is a race, similar to the Amazing Race on TV but with real puzzles to solve. The race I competed in, arranged by Outdoor Outreach and designed by Puzzling Things, required the use of cell phones or other text messaging equipment during the race. This added a certain amount of fun to the race while also allowing us to get almost immediate feedback on our results. Some puzzles were answered using an answer sheet and there was no way to be sure you were right until scoring at the end of the race. Most puzzles involved sending a text message and the acting on the answer. I do not know what technology was used in that race and I developed my application from scratch with only the basic concept of answering question as a starting point. The race that I am trying to develop is complex and is a very different topic that I hope to cover in detail once the race is done.

Update

The puzzle race that was mentioned above that will use this “product” is scheduled for August 17, 2013. Information can be found at http://www.gstroop251.com.

An inactive demo is now accessible. This demo shows the web interface and some of the AJAX processing takes place. The demo does not get new messages and data on the server cannot be altered in any way. Contact me if a demo of the real “product” is needed. The demo web interface to the Auto responder is here.