I've been seeing a few strange errors on one of my CiviCRM (4.4.4) site recently.

    [message] => Missing input parameters
    [code] => 
QUERY_STRING:       reset%253D1%2526jid%253D69%2526qid%253D1605%2526h%253D077ec51a7e598906 
REQUEST_URI:        //civicrm/mailing/optout?reset%253D1%2526jid%253D69%2526qid%253D1605%2526h%253D077ec51a7e598906 
SCRIPT_NAME:        /index.php 
PHP_SELF:           /index.php 
REQUEST_TIME:       1428513094 

Based on the error message, it looks like the optout request is somehow getting encoded, which yields a CiviCRM "Sorry but we are not able to provide this at the moment" error.

At first, I thought that there was a problem with the request, but I noticed that if I decode the request URI, I get a valid optout address.

It seems that there might be an email client out there incorrectly encoding the optout and unsubscribe tokens, but I haven't been able to reproduce this in testing both HTML and TXT email formats.

Any thoughts about what might be happening here?

  • How does the URL look in the email source? In other words, is your site re-encoding or is the email re-encoding? Also, check the preview screen when you test the email. That'll tell you whether it's your WYSIWYG doing the encoding.
    – Andie Hunt
    Apr 8, 2015 at 17:46
  • Thanks Andrew. I'm uploading TXT and HTML files directly rather than using WYSIWYG. The source URLs look like this: /civicrm/mailing/optout?reset=1&jid=87&qid=3150&h=7f486ed8d8e33822
    – BBC
    Apr 9, 2015 at 16:24

2 Answers 2


This sounds like an issue a customer of ours encountered. In the end they resolved it at the device level.

From our issue tracker notes on the subject:

The issue is to do with character encodings. CiviCRM emails are sent with the following headers:

Content-Transfer-Encoding: 8bit
Content-Type: text/html; charset=utf-8

Whereas it appears Exchange is re-encoding these as 'quoted-printable' when serving them to the iOS device:

Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Here was their final feedback to us

"You were right about this being something to do with legacy mailservers, etc. Sort of. I sorted out how to replicate this behavior on ANY iOS device. Simply create a new mail account on your iOS device using the "Exchange" option as outlined here: http://www.macobserver.com/tmo/article/how-to-set-up-gmail-on-ios-using-exchange-activesync

Although he isn't here today to ask, I believe our ED has his email setup this way on both his iPhone and iPad, and this is causing the issue. I will check in with the member who is experiencing the same issue and see if they are on an Exchange server or a Google mailserver set up in a similar manner.

I'm setting this to resolved, and we'll work internally to get all our people on the correct iOS settings.

Thanks much for your help!"

  • We're encountering this too, sometimes with "Missing input parameters" and sometimes "There was an error in your request", in the Civi debug log accompanied by a backtrace. We also get opt-outs that succeed. If it's caused by some combination of Exchange and iOS at the recipient's end, am I right in thinking there isn't much we can do? We have no control of the mail server or OS used by alumni of our member schools.
    – DaveFF
    May 20, 2015 at 15:31
  • Thanks for the info Eileen. It seems that we have at least a couple of users in our system who have the same iOS setup. Apparently, it was a fairly popular way to get push notifications to appear for iPhone users.
    – BBC
    May 21, 2015 at 19:48

It's often best when encountering bugs that are difficult to trace to start by upgrading to the most recent version, which in your case would be the lastest LTS version. That way you aren't spending time diagnosing a bug that others have already solved.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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