Posted by
Peter Jönsson  -  October 2009
In the past I seem to remember that there has been some discussions about a rxml-module for reading mails from an imap server. Does anyone  have any working examples or code snippets implementing imap reads in rxml?

The solution I'm working on now involves an automated workflow with another system and the data exchange are to be done in emails (including attachments :)

All suggestions are very welcome.

Posted by
Peter Jönsson  -  April 2010
Thought that I should post my own solution to the mail-reading problem ;)

The more one looks at email formats and protocols and all the quirks therein the more certain I become that one shouldn't try to solve the base problem (i.e. to read the emails directly into roxen) in rxml, a module or the like.

A very handy solution on Linux systems is instead to use Fetchmail and Procmail to get and store the emails maildir style. Further a little shellscripting and the use of uudeview to handle attachments will put both the emails and attached files in directories that can be mounted into Roxen and then read with RXML to do whatever you desire.

Posted by
Erik Dahl  -  April 2010
I'd say so too since you may have other things triggered using this type of setup. E.g. importing a mail into the site as a web page, insert information in a database etc.

It will be interesting to see what your solution is used to.
Posted by
Peter Jönsson  -  April 2010
Well the primary use of this function right now is for an automated workflow to a language translation agency.

In short we have a database driven app included in our Roxen cms-templates that allows editors to send any regular xml page for professional translation into a number of languages.

The translation app stores vital information about each job in a database. Constructs and sends an email with xliff-formatted page data as well as xml-based job info to the translation agency.

From the translation agency Roxen recieves emails of job confirmation reciepts and, within 24 hours, the translated page which is automatically or manually published on the website.

Apart from having to handle a bit more steps to circumvent flaws in the mail protocols (like having to zip xml-files and decode base64 data) it is all very transparent and handy. In the future we expect this particular service to move to a http based transport layer (like SOAP) but for now it works ok. As you pointed out the same solution for the mail mechanisms could also be used for almost any arbitrary email based solution. Handling bounce emails to keep a customer database up to date could be one of these.
Search this thread: