Tuesday, October 21, 2008 - 17:39
Written by

I’m happy to report a PHP counterpart to imap2soap is coming in CiviCRM 2.2, so the handling of CiviMail’s return channel should be much easier in the future (ideally as simple as setting up a cronjob).

There are also other CiviMail improvements and changes in 2.2 (kudos to U.S. PIRG for their sponsorship!) which I plan to unveil in upcoming post(s), but let’s concentrate on the return channel for now.

The solution will be based on UI-configurable mail sources, and the idea is that every now-and-then – depending on your cron settings – the CiviMail processor will poll the source and take care of all the emails found there, either by processing them or ignoring. The processing will be done by using local API calls, so will also work on PHP installs lacking the SOAP support.

In the case of IMAP accounts, the emails from Inbox will be moved to either CiviMail.processed or CiviMail.ignored folders. In the case of POP accounts and local Maildirs, the emails from the account/dir will be moved to you CiviCRM’s files/civicrm/custom’s subdirectories.

For the adventurous CiviMail users who would like to try this solution on their CiviCRM 2.1 installs, please contact me in this forum thread – but do keep in mind that this will require editing some files (as there’s no UI for the account configuration yet).

Filed under


I would LOVE to try the solution on my 2.1 install! Think it would work with Google Apps IMAP?

Thanks for the great news!

To make it work with GMail’s IMAP/POP, you’d have to make CiviMail send to localpart+-prepended addresses (this requires hacks in three places) and edit the bin/CiviMailProcessor.php in one place (the $localpart variable).

This will be properly (i.e., UI-wise) implemented in CiviCRM 2.2.

I will try it both on a Google Apps account and a normal web host linux email server. I don't care about GIU - I can edit whatever files you tell me to and hack it till it's smooth. Just let me know the hacks: I want to experiment with this. Thanks!

It would be best if you joined the forum thread at for further discussion. :)

That sounds great. I just ran into a situation where I would like full CiviMail capabilities on one install but it's on a SOAP-less server. I will see if I can use it as a test case.

Is it really worth it to develop support for POP? I think that it would add a great deal of complexity, and I have yet to find a mail server that supports POP but not IMAP. The reverse is however common. --
Dave Hansen-Lange
Web Developer
Advomatic LLC
Hong Kong office

As you can see from the implementation, POP support isn’t that hard, given that ezComponents abstracts most of POP/IMAP/mbox differences out.