CiviCRM 1.9 plans and a poll on dropping SMTP actions

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, sending an email to unsubscribe…@example.com, the user will be presented with a http:// link performing the same action. We believe this to be a much user-friendly solution. The question we want to ask is whether there are any advantages in leaving the SMTP (email) actions after we make sure they are properly re-implemented over HTTP. Dropping the support for these actions over SMTP would simplify the related CiviMail code greatly, as well as make the return SMTP channel (which is the hardest part to setup when building a CiviMail site) only needed to handle bounces. So, are there any compelling reasons to keep the SMTP (un)subscribe/opt-out functionality in place if it’s fully reimplemented over HTTP?

Comments

Yes I agree that the greatest barrier to entry with CiviMail is setting up the return path. I'm all for switching to http.

And if we could make the bounce processing simpler too, that would really improve things. One way to do that would be to build a php version of imap2soap. Requiring new users to figure out how to get PERL on their server as well as the required extensions (VERP etc.) is a big barrier (The amavis setup is a bigger barrier still). This stuff could be replicated in php and the only requirement would be the apache IMAP extension - which most systems already have.

I know what your response will be: patches welcome ;) but I don't see this making my priority list any time soon.

dave:

youe are right on with the patches welcome to address the above itch. But for folks who want to avoid dealing with Perl / Amavis, can always subscribe to UAS's CiviMail service and sidestep the whole install issue

Writing a php version of imap2soap etc does not make appear on any of our short/medium/long term lists

Great news - thanks for your work on CiviMail - can't wait to try it out!

SMTP unsubscribes as optional would be nice as some people may not have easy web access (such as in third world countries/blackberries to take two extremes).

I fully support dropping SMTP return path requirements. I'm using the simplenews Drupal plugin right now instead of CiviMail just because we're a small non-profit on a shared server and do not have the capabilities to do the whole SMTP return path settings.

I've been manually processing bounced e-newsletters on a 1200 person list, and it is only a couple people a mailing, which I can easily remove manually. So I wouldn't even be overly concerned about bounce-processing (i.e. not make it a mandatory feature).

It would be nice if the click would not be an instant unsubscribe, but a confirmation page with the option of different frequency, if any.

I was going to ask about "Reply-to" with unsubscribe in the subject line, but so many people having addresses that forward to other addresses, that can be more annoyance and confusion than help.

In direct answer to the question, finally, I don't see any day when the web is not available and e-mail is – even for any given person – so no, I don't see a compelling reason to keep SMTP functionality if it's difficult to maintain.

The danger is in forwarded messages, downstream recipients unsubscribing the actual subscriber?

benjamin melançon, Agaric Design Collective