CiviCRM Community Forums (archive)

A PHP version that will replace imap2soap.pl will be a great community contribution. Anyone willing to step up and do the needed work? We can help out a bit here. Hop into IRC and dive in

lobo

yes, i did read the post before replying

however not sure if u've setup civismtp, but it is fairly trivial to set up and does BOTH inbound and outbound processing for a pretty low price (note that we have no incentive to plug that service). typically shared hosts also have issues with high volumes of outbound mail also and a more complete service like CiviSMTP makes more sense, IMO. Running a 24x7 service is a pretty intensive operation and a bit more involved than having an available resource

lobo

Hmm, then it might make sense for the company you recommend to offer a basic and a delux version. A basic would be a free or minor flat rate for the imap2soap service and delux for the complete package to include smtp.

It just seems like this is a service that has slowed a lot of installs down. I can see why a lot of installs might not want to go through CPAN pain, etc. Anyway, I will wait for feedback and am ready to provide some hardware and bandwith if the interest is there.

Also, shameless plug for my imap2soap posts. Look for help with Civic mails getting thrown to junk. Please have look if you know anything about this issue.


Thank you.

Thanks Piotr 

As individual building block techniques are developed with PHP to deal with returned email, could they be identified and made available as we go along.   

For example a more efficient routine to read the pop3 email box than I used - see beginning of this thread - I think this might read the entire message body into the array for each email message, which is not necessary, because I'm only looking at the first few items in the array. 

Also, it has been mentioned that the CiviCRM PHP PHP routines may be already available to do things like delete the email record from the box if it has been determined to have been handled, but I don't know how to do this.

There has been limited discussion of when an email address is flagged as on hold - perhaps not on the first bounce, maybe depending on the type of bounce - returned non deliverable, as opposed to mailbox full.  Manually, I'm collecting a half dozen for an address and then mark as on hold.

I may be mistaken, but I don't think the email on hold indicator is a field that can be marked in a spreadsheet of potential on hold email addresses and uploaded (can't find a field to upload into in the upload routine).

Any discussion about how people are dealing with bounces when they are not using imap2soap would be appreciated.  In theory we are deleting from the return mailbox manually and manually marking the record on hold with the assistance of the php generated listing that is imported to a spreadsheet.  In practice, returned emails are accumulating.

Thank you for looking at a php option for handling returned emails.

Dave

I agree. PHP Version would provide a better solution because then you don't have to worry about offering your username/pass for your email to a 3rd party.

The idea behind the service was to make something turn key within the admin panel of Civic so you could enter your imap account name and password and click go. Done.

Likewise, if we did it in php, we could still provide the same service from the control panel. So count me in if there is anything I can do to help. As it stands, we can't use civic and I have it on 3 clients sites. I was looking into that 3rd party service, but they are a metered service and that could get costly pretty quick. Not a big fan of a metered service. Personally, I would prefer to play a flat rate. But I understand they have to make money and they have to make sure the have some level of control in place to keep people from slamming their server.

Anyway, the email is absolutely the biggest issue I have run into with Civic. So for now, I am waiting and hoping they come up with a better solution for those who are struggling with dependency and security rights issues.

the 2.2 tentative schedule is here: http://wiki.civicrm.org/confluence/display/CRM/CiviCRM+v2.2

you can watch the issue and potentially backport it to 2.1 if critical to your org

lobo

piotr posted the issue number early on in the thread: http://issues.civicrm.org/jira/browse/CRM-3616

We've stayed away from accepting donations (so far), but will introduce them shortly. In addition to the software, you need to have someone responsible for the database and some business process's that go along with usage. So far, that has not been a priority for us. We used to run CiviCRM on the main site sometime ago, but it was neglected, hence we turned it off

lobo

Just adding my $.02, based on what we've done on phplist:

- one single mailbox for the bounce
- the emails contains to extra headers X-mailing=id and X-contact=cid (not sure of the name, but that's the idea)

a php called from a cron fetch the emails and parse to find the ids and process them (no need from soap, that's on the same machine)

I'm using it for mailing with over 50k contacts, it works.

A couple of points: the php cron is called from the shell (php-cli), not from a wget of a webpage. It allows both to avoid the extra layer of the webserver, the timeout/memory problem, and let you set a lower priority on these batches (I nice -19 them). As for the login/pwd, the "cron" user(s) is defined in the config as a user that has the special privilege to authenticate from a cron/php-cli AND to do that without having to put a password (so you don't have passwords in clear text in the shell/cron)

As for the header fields vs. envelope, we have indeed problems from time to time with mail servers that strip the bounces from these extra header fields, so having a VERP is no doubt better from a technical point of view.

Moreover, with most of the mail servers accepting the name+whatever notation, that'd be easier to still have one mailbox eg bounced@domain, and use bounced+mailingID-userID@domain as the envelope.

Last but not the least, the major problem is with crap out of office systems, that sends that to the envelope address instead of the sender one, and are seen as spam. Not much we can do about it to my knowledge.

Dave, did you move further on the php version of it ?

X+

So you parse the body of the reply and hope that the bouncer included the headers, right?

Yes, it kind of mostly work, but as said, not as good as the verp.

As for putting php-cli as a first class citizen: really, that's soo much better than wget?curl...

I just saw your post about the 2.2. going to try and let you know.

thanks!

X+