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
- Untar the source files to a new folder - it does not have to be installed on either the mail server or Deki's server.
- Open up the /etc/config.xml to edit your configuration settings.
- 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
- Retrieve emails from both a POP or IMAP interface from a given email address.
- Script should be able to deal effectively with different MIME types
- 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)
- All email headers should be stored as a page property
- 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)
- 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")}} - The email recipient should be set as a page tag ("email-from:dev@mindtouch.com") (this is to workaround the inability to search properties)
- 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)
- The path of the email as it's stored on Deki should be configurable
- 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)
- This will still not be enough to prevent conflicts - script should recover by appending a hash to the HH:MM:SS title
- Display title should be {SUBJECT}
- 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)
- Message parsing: Best effort should be made to strip emails of extraneous/repeated content (nice-to-have)
- Forwarded emails should have any extra formatting stripped
- Replies should attempt to strip repeated content as best as possible, except in the case of inlined responses
- 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).
Related forum discussions
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.
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.
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.
Would love to be able to help beta test this.
sometimes documentation needs curation :-)