Along with the introduction of CiviMail Processor as the new supported return email hander, we’ve made three changes that are relevant for third-party CiviMail developers in CiviCRM 2.2.
Unified email formats
From CiviCRM 2.2 on, we’ve unified the format of the ‘action’ email addresses used in CiviMail. The new format is
a is a one-letter symbol for the action to be performed (b for bounce, c for confirm, e for resubscribe, o for opt-out, r for resubscribe and u for unsubscribe), followed by two ids relevant to the action, followed by the 16-digit hex hash – all separated by dots. This means that all CiviMail-bound emails might should now match
Note 1: In the case of the subscribe action,...Read more
- CiviCase - case management component with configurable workflows (learn more...).
- Personal Campaign Pages - Allow constituents to create and promote their own personal fundraising pages in order to drive traffic to your organization's online contribution pages (learn more...).
- Simplified CiviMail Requirements - PHP-based option to handle return channel (bounces, replies ...) - replaces AMAVIS and simplifies installation and...
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...Read more
On every new CiviCRM install, I've had the same question about the difference between CiviCRM (the mass mailing module) and the send mail feature (from and individual contact and a search result). The question is when to use one or the other.
I understand than historically, these two features comes from both end of the spectrum, CiviCRM was made to send newsletters and bulk emails, and the send email is a replacement of sending a mail from your mail client. However, you can have a mailing list of a handful of contacts, and you can send "individual" emails to several dozen contacts.
As Dave put it (http://forum.civicrm.org/index.php/topic,4889.0.html):
Send Email to Contact(s) - The model is basically the same as sending a simple / quick message to 1 or a few people from Outlook / my email client. However, it has the benefit of keeping a record of the communications inside the CRM....Read more
Hi CCRM Friends,
My name is Shane Hill. Some of you may have read my name in a few places or on some lists. This post is meant to introduce me and give some background. I am with the organization The Urban Alliance For Sustainability. http://www.uas.coop and we use CiviCRM to manage our constituency and send email blasts. At first, I was just a volunteer with UAS as I believed in their mission (now my mission) and I wanted to lend my experience to what they were (are) doing. Then in time I inherited their web operations which eventually led to having to deal with CiviMail. :)
When I say I had to deal with CiviMail, do not get me wrong. I love CiviMail and CCRM, it's just that CiviMail comes with a high technical bar to entry and at times I felt a bit like a pole-vaulter using a soda straw (bio-degradable plastic) to get over the bar. So I changed a few things about the CiviMail implementation that we had going and ended up...Read more
Thanks to UAS’s Shane Hill’s impressive recent CiviMail improvements (currently, among others, an order of magnitute speed-up in email generation…) and the forthcoming changes for DA, we decided to make a separate CiviCRM release consisting of CiviCRM 1.8 and the improved CiviMail. The release will be called CiviCRM 1.9 and is developed on the
v1.9 branch in our Subversion repository.
CiviCRM 1.9 will be strictly a CiviMail-improvement release, which means there will be no changes to core CiviCRM nor other CiviCRM components.
Now, the poll. One of the improvements we want to roll in this release is that all of the CiviMail actions that the users can now undertake over SMTP, like subscribe, unsubscribe, or opt-out, can also work over HTTP. This means that instead of, for example,...Read more
Earlier today Fen Labalme from CivicActions sent an email to the dev list regarding CiviMail performance and the not-so-great number that they've seen on their servers. His complete email and the thread is here.
The results were not great and I wanted to verify and check the results on my local powerbook. I ran a few tests with mock data and came back with significantly better results.
- We really have not spent a lot of time optimizing the speed and throughput of CiivCRM. I suspect if we spend a week or so, we should be able to squeeze out a 2-3x improvement. All numbers approximate. Would be awesome for someone from the community to step up and either lead the charge or sponsor the effort or both. Ideally our goal should be to send at least 100K - 250K mails/hour on a 2 or 3 machine architecture on modern hardware. Web server on one machine, db server on the other,...
CiviMail, described in general previously, is our component for mass-mailing the CiviCRM contacts. In this entry, we’d like to get a bit more into the details on how CiviMail exactly works ‘under the hood’.
Recipients List Building
Getting the final list of recipients is not as easy as it may seem. If you look into the
getRecipients() method of the
CRM_Mailing_BAO_Mailing class, you’ll see that we’re building some temporary exclude (
X_*) and include (
I_*) tables, based on
- the user’s selection – excluded/included CiviCRM groups,
- the user’s selection – excluded/included previous mailings’ recipients,
- whether the contacts already received this mailing in...
CiviMail is a component that allows the users to create, send, track and manage CiviCRM-based mailings. In CiviCRM 1.5, CiviMail underwent speed and memory optimisations; in CiviCRM 1.6 we’re concentrating on usability improvements.
CiviMail users can create mailings sent to a single CiviCRM group (both regular and ‘smart’) as well as group sums and differences; the recipient list can also be based on inclusions and exclusions of previous mailings’ addressees. The mailing template can contain various recipient-specific tokens, replaced accordingly for every target contact. The mailings can be scheduled to happen on a certain date, as well as be sent in admin-defined amounts (so the mailserver is not swamped with a one-time massive queue).
Once a mailing is sent, the CiviMail users can track the delivery and bounce ratio, the number of forwards and unsubscriptions, the number of emails being actually read (opened) by the...Read more