Emailbox Service

    Overview

    Provide an email gateway to push emails into MindTouch. This functionality would make it easy for teams/users to capture email threads in one location by specifying an additional email address to cc, bcc, or fwd. This service will only be available for our commercial customers.

    Status

    First draft available for downloading! (March 26th, 2009)

    MindTouch Principals

    KarenA, RoyK

    Installing

    This application is in beta testing.

    Requirements

    • MindTouch MindTouch Lyons (9.02) or later
    • PHP libraries: iconv, libxml, SimpleXML

    Instructions

    1. Untar the source files to a new folder - it does not have to be installed on either the mail server or Deki's server. 
    2. Open up the /etc/config.xml to edit your configuration settings.
    3. Run dekimailbox.php

    Note that we have, by default, turned on PHP debugging so it's easy to capture errors and post them.

    Configuration values in config.xml

    • Email configuration
      • type - Server type. Supported values: POP3, IMAP (default)
      • host - Server name. E.g. imap.mail.com
      • username / password
      • ssl - Secure connection. Supported values: SSL, TLS or empty/unsetted for non-secure connection
      • port - Keep empty/unsetted for default by RFC.
      • folder - Imap folder. INBOX by default.
    • MindTouch configuration
      • host - The hostname of your MindTouch. Examples: https://ads.wik.is, http://wiki.developer.mindtouch.com
      • api - api path (should not need to be changed)
      • username - MindTouch username (read the security considerations below!)
      • password - MindTouch password
      • path - The default path that the email messages will write to; slashes denote a hierarchy.
    • Log configuration
      • path - Path to log file (without filename).
      • enabled - Enable/disable logging. Supported values: 1 (default), 0
    • Other configuration
      • charset - Messages will be stored in this charset
      • timezone - Timezone. See http://www.php.net/manual/en/timezones.php
      • savehtml - Supported values: 1, 0 (default). If enabled, messages will be stored as html if possible, otherwise html part will be save as attachment
      • removemessage - Remove message from mailbox after processing. Supproted values: 1, 0 (default)

    Security considerations

    Using a user with UNSAFEHTML could become a security hole - because there is no filtering done on this service (yet), anybody can email your endpoint - an email containing scripting could execute on the server. For this reason, we suggest that the MindTouch user who is setup to do this posting NOT be allowed to have UNSAFEHTML privileges.

    Design Considerations for this service

    Protecting the privacy of personal emails should be of utmost importance. To that end, this script should run under the assumption that all emails sent to it are ready to be re-published. Publishing should be an opt-in process rather than opt-out to reduce the need to develop complex filtering mechanisms and to reduce mis-postings of emails that were not meant to be published. From a product standpoint, selective email publishing from personal inboxes should be handled through the Outlook Connector.

    Requirements

    1. Retrieve emails from both a POP or IMAP interface from a given email address.
      1. Script should be able to deal effectively with different MIME types
      2. Date used should be "Received" header - this will be the header of the recipient's server (and will allow us to not deal with diff timezones)
      3. All email headers should be stored as a page property
    2. Take the subject of email, body of email, and any attachments and post them on a new MindTouch page (subject = page title, body = contents, attachments = file attachments)
      1. The email timestamp, email sender, email recipients should all be stored as a page property and exposed through a MindTouch template on that given page (simply prefix the content with {{wiki.template("Emailbox Header")}}
      2. The email recipient should be set as a page tag ("email-from:dev@mindtouch.com") (this is to workaround the inability to search properties)
    3. We will not attempt to do threading on individual emails - each email should be its own page; we will rely on DekiScript to try to display emails in some readable format (requires some more thinking through)
    4. The path of the email as it's stored on Deki should be configurable
      1. The title of the email needs to be unique - a possible default path would be /Emails/YYYY/MM/DD/HH:MM:SS (Using a path which is easily sortable in memory is preferable)
        1. This will still not be enough to prevent conflicts - script should recover by appending a hash to the HH:MM:SS title
        2. Display title should be {SUBJECT}
        3. The benefit of utilizing a date format is that it allows us to quickly sort subpages based on its URL without retrieving additional data (like tags or properties)
    5. Message parsing: Best effort should be made to strip emails of extraneous/repeated content (nice-to-have)
      1. Forwarded emails should have any extra formatting stripped
      2. Replies should attempt to strip repeated content as best as possible, except in the case of inlined responses
    6. How to handle multiple emails? An array of email with the associated dekihost/paths?

    Project Notes

    Initial product prototyping will occur in PHP; once the use cases and workflow are polished, the application will be converted into a C# service for futher polishing - this will simplify the set-up of the server (avoids cronjobs). 

    Helping out

    While this project hasn't been started yet, please list your name below if you're interested in helping beta test and refine the early iterations of this product. Those who do will be granted access to this connector (either through a commercial license grant, or a non-distributable custom buil) after its commercial release. Also remember to subscribe to this page so you get updates as they are made.

    Tag page
    Viewing 15 of 27 comments: view all
    I can see thread merging work for conversations over email -- all replys have the same subject line. We have a group of developers working on 7 or 8 projects. I would like some way to get emails grouped by those projects. As much as I try, email still carries a lot of information that doesn't get captured anywhere else. As an example, look at the LDAP sub-forum. That is a very specific topic but you cannot look at the titles (subject lines) and know they are all LDAP topics. If I could add { {deki: ldap}} I would have a chance of getting it in the right bucket. Think of it as tagging for emails.
    Posted 17:31, 10 Apr 2009
    OK, I can see parsing the entire email would be a pain so if that isn't doable, how about a tag in the subject [ldap] that maps to a start directory or the ability to parse multiple mailboxes, 1 for each start directory. Both of these would require a tag (or address) to directory mapping structure somewhere.
    Posted 19:28, 10 Apr 2009
    Like jgable, we have engineers and sales engineers who work on projects and use e-mail incessantly. The've asked me about sending e-mail to Deki. Primary use case is simply having a shared, indexed memory of important bits communicated via e-mail. My impression is that each project would have its own node in Deki. And each project area has its own e-mail node. By far, the e-mail node would be the busiest and have the most sub-pages. A project can last 2-6 months, or longer, and enter a maintenance phase. Usually, a single e-mail becomes a thread with 10-20 replies. Obviously, it would be convenient to group all e-mails with the same subject together. Interface: if a page had an e-mail address, members could elect to send the e-mail to the page or not. I think this is what SocialText does. edited 21:49, 10 Apr 2009
    Posted 21:40, 10 Apr 2009
    The way I'm approaching the design of this script (which is the easiest way - we can always polish it up later) is to have each script post to a single node - if you wanted to specify a new path for the contents, you would simply set-up another alias which points to another instance. Again, I'm not so sure how smart it is to throw in any MindTouch-specific "flags" inside the email contents at all (subject or body) - this causes a headache for parsing (how do we know when it's been replied too) and forces people to add noise.

    Now I know the use case for the email (I'm using it myself right now for our professional services team). What I'm finding (and this may not hold up in the long-run) is that *where* the email gets stored is less relevant, because we are relying on DekiScripting to do the display of the email contents on other pages. In the same way you don't design a database's schema based on how you'll access/read the contents, I don't want to (quite yet) burden the storage mechanism with the requirements for reading. My gut feeling right now is that DekiScript will do a good job of that.
    Posted 09:09, 13 Apr 2009
    Roy, Can you describe a little about how you expect DekiScript to display content on other pages? Are you saying someone goes in an manually conects an email thread to a specific page using dekiscript?
    Posted 10:31, 13 Apr 2009
    jgable, it's still very formative - we're still addressing the first part of the problem: storage.

    I want to reiterate my thoughts on this are VERY NASCENT - they are subject to change as we actually deploy, I start looking at how other people have done it, etc.

    The end goal is auto-threading. I think it's unavoidable on some level that people will have to do SOME work in tying email threads into MindTouch - be it from the email itself, or on MindTouch. Right now, we're playing around with email headers; there seems to be a way to thread based on its headers.

    Subjects are also a logical place to look, and we may go down this route.

    jgable - an update to the server-side storage of emails should be forthcoming, and after that, we'll start working on the DekiScript side of things which'll answer a lot of these questions - it may turn out not to work, in which case we go back to your original idea.
    Posted 10:55, 13 Apr 2009
    Its my thought that multiple mailboxes would be a logical answer as well. Its been my experience that subject lines are rarely all informative. If you have multiple mailboxes that are scanned, all you would need to do is forward or have the emails routed to the correct mailbox. The thought of subject lines and data parsing with keywords would be nice in the long run but implementing multiple mailboxes would be a short direct route to something I think will be asked of MindTouch any how.
    Posted 03:59, 14 Apr 2009
    If this can be a hint, it seems that http://forge.mysql.com/wiki/Eventum/ is a bugtracker system able to process email driven interactions about bugs and fills them into a web based & database repository
    Posted 00:17, 4 Aug 2009
    this sounds like an excellent feature... I'm willing to help test it out if that's still a possibility.
    Posted 05:36, 6 Oct 2009
    What is the status of this script? Is it considered just an add on to mindtouch or will it ever be a core function that is included in a release? Does it have any bugs as of today? Who is using it?
    Posted 05:46, 6 Nov 2009
    jonverve - the early beta is avail - we haven't put much work into it since then. it will be released into the commercial versions of mindtouch, and not be available for core.
    Posted 09:55, 6 Nov 2009
    @RoyK this would be incredibly helpful to our .org as we have almost NIL usage of Outlook. We also have a lot of Mac users who can't make use of any of the commercial desktop connector / print to wiki. :-(
    Would love to be able to help beta test this.
    Posted 15:32, 28 Jan 2010
    Hi, where does this service stand today ? available in commercial implementation ?
    Posted 08:26, 2 Feb 2011
    @openseo http://developer.mindtouch.com/en/docs/MindTouch_Module_and_Plugin_User_Guide/MindTouch_Mailbox
    Posted 08:04, 3 Feb 2011
    @karena : this is very great news
    sometimes documentation needs curation :-)
    Posted 15:32, 3 Feb 2011
    Viewing 15 of 27 comments: view all
    You must login to post a comment.

    Copyright © 2011 MindTouch, Inc. Powered by