CiviCRM Community Forums (archive)

I guess what I meant was the imap2soap to clean out the imap folder and deal with bounces.

Right, but the imap2soap script has to be called periodically as well, and this is best done with a cron entry for it.

What imap2soap does, it talks to your IMAP account, gets the mail, and then talks through the SOAP interface to your CiviCRM instance. This is done so that it can be ran from a third computer – not necessarily your email server, but also not necessarily from your CiviCRM machine (i.e., you can run it from your home workstation).

The new PHP solution is assuming it’s being run from the same machine as the CiviCRM instance, so it does not use SOAP, it just uses direct API calls of the instance in question.

So it seems here, if I am reading this right....
1. Amavis patch is not needed any more this php implementation will take care of it.
2. imap2soap is not needed any more since this will take care of that as well.

It goes like this: if you need real-time handling of bounces, you need to go with AMaViS. If you’re ok with a solution that’s not real-time, you can go with imap2soap (and you can use URLs for (un-,re-)subscribes so you don’t delay handling of user acitons).

The new PHP script will replace imap2soap’s functionality, so if you don’t need real-time handling of bounces and the SMTP actions, you can forget about both AMaViS and imap2soap for CiviCRM 2.2.

3. the one cron we run as
 wget -O - -q http://www.example.com/sites/all/modules/civicrm/bin/civimail.cronjob.php?name=xxxx\&pass=xxxx
Will take care of
1. sending civimails that are on a time delay and / or spool
2. check the civimail email folder to processes
a. bounces
b. junk
c. unsubscribes (if you are using it for that)

No, it will most probably be a separate cron run – you might want to send emails only once an hour, but process the CiviMail email folder every five minutes, for example. But it should be invokable just like the above (it will simply be a second cron entry).

Is it ready? Do you need testers? And would you like to tell me how to set it up and I can then add it to say the wiki How to area?

I’ll ping this thread as soon as it’s ready (it should be sometime this week, depending how intensive BADCamp and CiviCamp will be).

Note that this will be part of the 2.2 release (sometime in dec/jan). you will need to backport it to 2.1, there might be accompanying changes in the verp address format (dropping domain id etc)

That’s true. For testing purposes, I’ll commit the first version (which works with the 2.1’s addresses, as these are what we how now on trunk) to the 2.1’s tools directory, but it won’t be maintained/supported for 2.1, and it will be officially developed/rolled-out for 2.2.

I’m not sure what you’re asking about – but if about how to upgrade this script, you’ll just have to overwrite the files from the 2.1 branch with the files from the 2.2 branch when you upgrade your CiviCRM (from 2.1 to 2.2), nothing fancy.

What Lobo meant, if I developed it solely for 2.2, it would be, in the end, incompatible with 2.1 (as we’re planning address format changes for 2.2). But I’ll commit the initial version to the 2.1 branch, merge it to 2.2 and then only change the 2.2 version for the address format changes. But I won’t maintain the 2.1 version past the initial commit.