#180 XRMS Built-In Email Client


I have spent the last few days working really hard on the spec sheet of an email solution for XRMS. As it turns out, what I envisioned is a small but highly functional built-in email client inside XRMS. Let the idea or the length of the document not scare you. The concept is actually very simple but I have been as detailed as time and energy allowed to write this out. Please note that the parts highlighted in yellow are the items I am not quite sure about or do not know enough about to even make a competent statement.

This is more than just a rough draft and, while I am still polishing the concept, it should probably give you a very good idea what I have in mind. I will start a thread in Open Discussion pointing to this Feature Request and I would greatly appreciate your feedback on it since there is some money available and the willingness to make this happen.


  • 360team.ca

    360team.ca - 2008-08-20

    Specification Sheet

  • Wingthor

    Wingthor - 2010-03-15

    The major difference between IMAP an POP is that an IMAP server stores the email on the server, and sync. the content with the client. POP clients downloads the email to the clients PC. A POP client can be configured to leave a copy on the server.

    IMAP is preferred, but many ISP's only offer POP due to size of mailbox. Personal I prefer IMAP since it more seamless, and I can have all my email located in one place which is accessible from anywhere.

  • Wingthor

    Wingthor - 2010-03-15

    Don’t know how far you have come with this implementation, but I write some comments anyway.

    After reading the attached PDF, I think what want to achieve is you more or less to turn XMRS into an email server. This means that if you set up XRMS to fetch the email from the server, you must also make it capable to handle requests from the email clients. Or you will get a “hell of a job” setting up filtering code in order to get XRMS only get relevant emails. Remember not all emails are CRM related, even not emails from your customer. And what if the customer is new, or not in the XRMS database.
    POP normally downloads the emails to the client, and then deletes it from the server, you can of course force XRMS fetch function not to delete, but XRMS can’t control the users email clients to that extent, since the email client is user controlled, so if the user connects to the email server with their usual email client, the risk is big for that the email is gone when XRMS tries to fetch it. Most clients using POP does not store a copy of the sent email on the server, but stores it in a local file on the user’s PC. And, who can read whose mail?

    From experience many email users uses their mailbox as an archive. This causes the mailboxes to be huge. They also build structures like directory structures in order to easily find relevant mails.


    Drop out POP support. Focus on IMAP, and perhaps only download email headers. Perhaps make XRMS able to communicate with Squirrelmail or Horde (webmails). So that XRMS opens the email with one click. Let the email server handle the ACL for emails, but perhaps, implement a secretary function, or a function where selected users have access to email server user name and password. Make sure XRMS can communicate with web mail over a secure channel. Set XRMS to monitor only one directory set by the user’s e.g. inbox/work, plus perhaps subdirectories to the user choice of monitoring directory. So that user can decide the relevance to XRMS. Make XRMS make a copy in the sent folder on the email server when sending mail. If an attachment is relevant, put it in the files DB, with a link to the activity and the email as it appears in XRMS. Make the email be marked for a follow-up.
    Ubuntu (more or less debian) comes with Dovecot IMAP server ready to use. Have a look at functionalities in Dovecot server, and perhaps some other IMAP servers like Cyrus.


  • 360team.ca

    360team.ca - 2010-03-19

    Hi, Wingthor!

    I am not sure I understood all of your suggestions. The idea was to give XRMS a built-in webmail client and not turn it into a server. A lot of the issues you raise are actually far more dependent on corporate policy rather than functionality. The plugin has already been developed with a particular set of functionalities and, thankfully, its architecture is flexible enough to allow extensions in many different directions. Either way, this has actually already been done - the plugin has been in heavy production use for nearly half a year now.

    One of the reasons why there have been no announcements about it here is that it is not Open Source. Since sponsorship for the project has been very limited and since the plugin became a lot more sophisticated than originally envisioned, it is only being offered as a SaaS addition to XRMS and not even yet on a retail basis but to a limited number of clients who agreed from the onset to the "Beta" status of the plugin and to participate in its testing.

    The official launch of the "plugged" XRMS service is envisioned within the next month or so.

    All the same, thank you for your comments and ideas. I am sure some of those may eventually make it into the final product as client demand dictates.

    Have a great weekend!


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks