In a business context emails are a very important communication channel. Customers like to
communicate using email because it's so simple. Replying to emails will keep your history,
and you can attach everything you want and send it to your business partner.

And on the other side, here is our plone portal. With all the advantages a content management has.
You can use it to hold all the information important in your company, it will be searchable and
available.

To bring the two concepts together is the idea behind mailtoplone.

Starting such a marriage isn't that easy, because Plone is huge and so are Emails nowadays, having people
organizing their entire life inside their mail client. To give it a start let's think about two
major principles:

• Content:
  

        Managing content is the major mission of plone, and where it's really good at.

• Rules:
  

        You can't think about emails without thinking about rules. Rules help you to conquer the process
        of organizing the flood of emails floating through the world wide web.

So the approach of mailtoplone is to create content out of emails, based on rules.

The question is, how do emails get to your plone instance?

Drop a mail to plone

Mailtoplone defines an InBox, to be populated with Emails. This folderish type can be populated using a xmlrpc method.
Dropping a mailstring (a plaintext string containing the whole email including envelope), a plone content type
Email will be generated, the data field will contain the mailstring. To ease the usage of this xmlrpc method, a script can be
used:

    - dropemail
      (specify the url of the InBox and optional a file ( if no
      file is specified will use stdin)

You can integrate this script to your mailserver to automatically drop mails to plone.

Further processing

Having the email inside plone, we're able to work with it. Remember we mentioned rules as an important principle.
Plone has a great rule mechanism, called Content Rules
Having custom actions and conditions enables the processing to be flexible. The idea is to use the global InBox,
which all mails are dropped to and assign content rules to it, to further process the Emails.

1. Install the mailtoplone packages

Mailtoplone consist of three eggs:

mailtoplone.policy:

 Installs mailtoplone.base and mailtoplone.contentrules.

mailtoplone.base:

 Contains the custom types InBox and Email, also the adapters used when generating content out of emails and the dropemail script.

mailtoplone.contentrules:

Contains definitions of content rules actions and conditions to be used with mailtoplone

You can get these eggs and also a buildout from the collective

mailtoplone.base and mailtoplone.contentrules are also on pypi.

2. Create your global InBox

Add an InBox to the portal.

3. Mark existing content to be used together with mailtoplone

Mailtoplone finds possible dropboxes by their markerinterface, following Markerinterfaces are currently (version 0.1) defined:
 

IMailDropBoxMarker(Interface):

 """ marker interface for mail drop boxes """ 

IBlogMailDropBoxMarker(IMailDropBoxMarker):

""" marker interface for blog mail drop boxes """   

IEventMailDropBoxMarker(IMailDropBoxMarker):

""" marker interface for event mail drop boxes """ 

Remember to reindex the object after marking it.

4. Create Content Rules and assign them to your InBox

You can use each of the standard triggers, conditions and actions and combine them, with the one's defined
by mailtoplone. A common rule may consist of following components:

• Event trigger: Object added to this container
• Condition: Email Header
• Action: Deliver
• Action: Delete Object

Assigning such a rule to the InBox would enable to delivier emails to another destination in your portal and create content
there based on the context (by using the provided markerinterfaces different implementations of the drop method are
called, thank's to the component architecture).

1. Create the structure

• Create the InBox `globalinbox`

• Create the Folder `webblog`

• Mark `webblog` with `IBlogMailDropBoxMarker` (using @@manage_interfaces)
  

• Reindex `webblog`

2. Create the content rule

• Event trigger: Object added to this container

• Condition: Email Header

• Action: Deliver

    Specify `webblog` as key.

• Action: Delete Object

3. Assign the created rule to the `globalinbox`

4. That's all

This would be sufficient to create the News items. Of course, you're free
to specify content rules for the `webblog` too. For example
to publish news items after they have been added, so anonymous visitors would see them,
or anything you can imagine.

Extending mailtoplone

Mailtoplone makes heavy usage of the component architecture, and therefore, like plone
itself encourages you to extend it's functionality. Here are some approaches:

• define more conditions to check the mail for
• define more actions ( deliver to foreign urls e.g. )
• create more sophisticated adapters (e.g. create content types for addon products)
• maybe there's more than just content creation, for example reporting
• Create more ways emails get to the plone instance ( e.g. fetching from a mailserver via pop or imap)
• *
  

try out mailtoplone, post to the tracker,
or contact me on irc (#plone, mr_savage)