Extensible James server: predictions in your INBOX
In a previous article, I covered how we used the James mail server to decorate emails with events in the OpenPaaS Inbox webmail.
As a reminder, the James project gives us a working mail server to play with, and customizing the behaviour of this server to implement business features is easy.
At Linagora, as part of the OpenPaaS solution, we heavily rely on the James server, and actively develop features using the functionalities of James. Today I will cover how we added recommandations on emails.
A recommandation is an hint for a possible mail move. The answered question is “In which folder should this mail be?”. The intent is to have automatically defined SIEVE scripts. From a User Interface point of view, a quick move button will be positioned on the global Inbox view next to your emails, if the system assumes the given email should rather belong in another mailbox.
You can notice that the probability is added as part of the suggestion.
The overall architecture look like this:
— A model is generated from a dump of the James database. Currently it is using ElasticSearch documents. But this part of the system will likely change in a near future. Every user gets his own prediction model. This is done on a recuring basis using systemd timers.
— The prediction REST API is built on top of the models. By giving details about emails, you get a prediction.
— James, when receiving an email, will call the prediction API. It will add the prediction results as part of the mail headers.
— Inbox can then finally use these headers. It will use these peaces of information to display the move button, and display prediction accuracy.
Under the hood James is using a mailet for executing code upon email reception post processing. We implemented a dedicated mailet for calling the prediction API for every incoming emails, as a OpenPaaS specific James extension.
An implementation difficulty was the need to get user specific headers. We then reworked the Mailet API to add this feature, as well as enhanced message delivery to take these changes into account.
So far, we will need to make the integration evolve:
— The prediction API needs feed-back. It needs to know when a message is effectively moved to get better predictions. To do this, we need to be aware of the James message store updates. It means we need some kind of Mail Delivery Agent (MDA) extensibility. Such extensibility will unlock some new possible user features that can not be achieved with regular Inbound semantic.
— Data ingestion for computing the model will likely change. We will prefer a data-stream comming directly from James.
— We would like to associate a per user threashold for automatically moving emails. If the accuracy is more than the defined threashold, then the email will be directly moved to the given mailbox.
The interconnection of James and Prediction API gave us a great feature. Now every one can get the equivalent of self defined Sieve scripts, without set-up and without any knowledge. It just require you to move emails, and the system will learn from it. Such use case show the potential of the James server, which allow building complex features for email systems.
