Integrate email and wiki

Please only use the "Comments" or "wish list" section for comments if you are not AlexanderSchremmer or ThomasWaldmann.

Motivation

A mechanism for easily getting email content onto a wiki would increase adoption, esp. in corporate use.

Implementation scope

First implementation

• Email support will serve 2 distinct purposes:
  • archiving some emails (not intending to refactor, "keep as is" for reference)
  • getting content onto some page (including attachments, intending to (maybe cooperatively) work on that content)
• ACLs would be adhered to by looking up the sender address against the wiki user profiles, determining the posting user's wiki username.

• We do not implement email server or client functionality but just some procmail-kind of python script.

Refinements (later)

• ACLs: Of course this is no hard security as email sender address can be faked. Check passwords or have other means of authentication.
• In addition to having a mechanism for getting email content onto the wiki, wiki email integration would involve advertising the email address. Jot for instance has a "To post email to this page, send a message to some_address@somedomain" on each page.
• Maybe implement pop3(s) / imap(s) clients or an smtp server script. Keep spam in mind.

• Do we need a (slightly dangerous) overwrite mode for page content?

• Do we need a (very dangerous) overwrite mode for attachments?

Implementation details

Moved to the page HelpOnConfiguration/EmailSupport

Comments

Please only use this section for comments if you are not AlexanderSchremmer or ThomasWaldmann.

• I would look into applications like request-tracker how the solve things. There is also a dialog between mail and a page (database in their case). RT is in objective perl, though.

• And there is Roundup, the ticket system written in Python. It strongly integrates mails.

• see FeatureRequests/WikiMailManIntegration for Mailing Lists stuff

• From my experience. We need to think about the actual use of this feature in a corporate environment (normal people, not geeks). In this kind of context, bells and whistles like ACLs or target page calculated from e-mail headers are sci-fi. I rather prefer to focus on a simple use case, implement it fast, extend later using the feedback. My favorite use case for wiki e-mail integration is the addition of meeting minutes to a project page. It will work like this: let's allow users to send a mail to MyProjectPage@wikifarm.com, create a subpage with the subject and the text/plain part, add any attachment (including the raw email). Optionally, when MyProjectPage includes HasIndexCategory in its text (written down there by the admin) add a link to the bottom of MyProjectPage/PageIndex pointing to the new page (MyProjectPage should [[Include(/PageIndex)]] where appropiate)

  • we can't use MyProjectPage@wikifarm.com as that does not allow non-ascii pagenames.

    • I know, but using non-ascii pagenames usually isn't a good idea: it doesn't look clean in e-mail, is hard to enter directly in the URL box. Ascii-only names can work for choosen pages (like project or root pages) OTOH in modern MTAs the user names are not unix users, just LDAP or SQL entries. Need to check if non-ascii user names are allowed in such cases.

  • using the subject only as page name can be done by the method shown above (either on request or by default via configuration).
  • using some category in the parent page to trigger appending of generated content to another subpage is a nice idea, we think over it.

• ScriptMarket/Mail2Moin - get the docs about integration with postfix/fetchmail from there!

old content of this page, todo: refactor/review

The page name can be yielded from the from-address, subject or mail body. This should be configurable. The sub page name can be yielded from the subject or body, in the default config it would just be a concatenation of From-Subject-Date. Sample of a wiki-wide config file:

base_page = [match_from("wiki-([^@]*)@"), match_subject("\[([^\]]*)\]"), match_body("^(Store: ([^\)]*)"), "ConstantPageName"]
sub_page = "$from-$subject-$isodate"

The first match in base_page and sub_page are concatenated and used as the page name of the mail.

wish list

These are user wishes for the existing 1.6 email integration:

• replacing "/" in subj by "\" to have valid auto-created sub page names

• for table created by + operator, move datetime from column 4 to column 1

• if an email is forwarded to the wiki, use original from / to values

  • check x-original-to (and -from ?) - check email standards whether we can do that. x-original-from seems to be rarely used (but maybe some procmail script on the mail server could add such a header?)

• generate header above content in any case

• mail_import_pagename_envelope = u"+ %s/" makes mailimport behave like if you write "+ " before and "/" after any pagename you give (default is no change, u"%s")

http://test.wikiwikiweb.de/ is now using:

    mail_import_pagename_envelope = u"+ %s/"

CategoryFeatureImplemented