On a CiviCRM 4.6.30 / Drupal 7 installation using the com.cividesk.email.sparkpost extension, outbound email stopped working after enabling the PHP Mcrypt extension on the server. This affected both CiviMail and transactional emails.

Why would this occur and how can it be resolved?


CiviCRM has a utility class CRM_Utils_Crypt for encryption & decryption. If PHP Mcrypt is installed, it uses that plus base64 encoding. If not, it falls back to using just base64.

This class is used for encrypting some settings, including:

  • smtpPassword in core 4.6.30
  • sparkpost_apiKey in com.cividesk.email.sparkpost

PHP Mcrypt was not initially installed on the server, so these settings will have been encoded by CRM_Utils_Crypt::encrypt() just using base64_encode.

Once PHP Mcrypt is installed, CRM_Utils_Crypt::decrypt() will try to decrypt these settings using mcrypt functions. This fails in this case, because they weren't encrypted with mcrypt when they were entered.

The simplest solution is to re-enter the settings. They will then be stored encrypted with mcrypt. If this wasn't feasible, it should be possible to write a script to decode specified settings using the non-mcrypt method and then encrypt and store them using mcrypt.

A few thoughts...

  1. If Mcrypt is not installed, settings are not being stored encrypted. It would be good if site admins were made aware of this, perhaps via the System Status page. This could also warn of the consequences of enabling Mcrypt on a server where Civi is already configured.

  2. The conditional code in CRM_Utils_Crypt::encrypt() & decrypt(), which falls back to just base64 encoding, appears to have been added for PHP 5.2 compatibility on Windows: see Email Configuration at https://wiki.civicrm.org/confluence/display/CRMDOC/CiviCRM+Configuration . As CiviCRM no longer supports PHP 5.2, the reason for this change seems no longer to apply and perhaps we should make Mcrypt a requirement. However...

  3. The PHP Mcrypt extension has been deprecated as of PHP 7.1.0 and moved to PECL as of PHP 7.2.0. Comments there say:

    • "This extension rely in libmcrypt which is dead, unmaintained since 2007."
    • "Avoiding mcrypt is only half of the advice. The other half: NEVER do crypto in PHP in the first place!" [It goes on to give some good arguments and alternatives.]

In summary, I think Civi should not leave it to chance, when it comes to deciding whether or not to encrypt something, whether a particular PHP extension is installed or not. It should at least warn site admins, if not require a suitable encryption method to be available. Which method that should be needs discussion, given the deprecation of PHP Mcrypt.

  • This seems like it should be discussed on civicrm-dev, or on chat.civicrm.org in the ~dev channel. – Jon G - Megaphone Tech Aug 12 '17 at 19:20
  • I thought the same and posted on Mattermost on 9th August. One suggestion there was to write this up as a Q&A here. – davejenx Aug 22 '17 at 14:55
  • Ha :) I realize my comment was super unclear. I was referring specifically to the deprecation of mcrypt. The rest seems appropriate for SE. – Jon G - Megaphone Tech Aug 22 '17 at 15:15
  • Tim Otten offered a good suggestion on Mattermost: "fwiw, Civi includes a copy of phpseclib, which is wrapper that falls back to the best available implementation (eg openssl, mcrypt, pure-php). Rewriting CRM_Utils_Crypt with that (while preserving the crypto params) would also fix the compatibility issue." – davejenx Aug 22 '17 at 17:11
  • I just had a similar experience and posted an issue to deal with the simpler problem here: issues.civicrm.org/jira/browse/CRM-21120 Agree that longer term is a different issue and Tim's suggestion sounds like the right direction. – Alan Dixon Aug 29 '17 at 17:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.