Mailing issue. Could not identify any recipients. Perhaps the group is empty?

Question

I am experiencing a weird issue on my CiviCRM 4.7.3 on Joomla 3.5.0 (also happening on some 4.7.8 on Drupal 7)

When I try to send or schedule a mailing and I hit "Send test" I receive an error saying Could not identify any recipients. Perhaps the group is empty?. However I have selected a group with valid recipients inside (I can see the yellow text near the recipients field saying "~81 recipients").

If I ignore the test and try to send the mailing, it does not give me any errors, but no emails are sent and if I check the report it says:

Intended Recipients     1
Successful Deliveries   0 (0.00%)

The Mail module works - I can send mail through CiviCRM to a contact directly, only through CiviMail there is a problem.

Further debugging information

After a lot of debugging I can narrow the problem down to an ACL issue:

In CRM/Mailing/BAO/MailingJob.php the deliver() function is reached but the query ($eq->query, $eq->fetch) doesn't return any results.

This is due to the condition from $aclWhere, for me it is:

( ( `civicrm_group_contact_cache-ACL`.group_id IN (8) ) )

which is joined in the full query by

LEFT JOIN civicrm_group_contact_cache `civicrm_group_contact_cache-ACL` ON contact_a.id = `civicrm_group_contact_cache-ACL`.contact_id

while I do get a contact joined in the query, an entry in civicrm_group_contact_cache seems to be missing. What is that table for, anyway?

Answer 1

The solution for me was to set up a Bounce Processing email account in Administer menu > CiviMail > Mail Accounts.

Answer 2

We're using Drupal 7.56 and CiviCRM 4.7.25 and we also have this problem. None of the above solutions worked.

This seems to be a very general type of error that can be inadvertently triggered by a great many causes. For us, we eventually discovered that our SMTP gateway had ceased authorizing payment on our account and was declining our traffic from CiviSMTP.

So if you're receiving this error, it might be a good idea to double check that your expected mail path actually works as you expect it to before you go digging through code. :-)

Answer 3

For me (CiviCRM 4.7.8) the problem was related to some changes introduced in 4.7.8. regarding permission checks (see GitHub PR #8415, Jira issue CRM-18159).

Reverting those changes fixed the problem:

Remove the acl clauses by replacing

list($aclJoin, $aclWhere) = CRM_ACL_BAO_ACL::buildAcl($senderId);

with

$aclJoin = ""; $aclWhere = "";

1. in CRM/Mailing/BAO/Mailing.php in function getTestRecipients (line 926)
2. and in CRM/Mailing/BAO/MailingJob.php in function deliver (line 502)

---

Some details from Debugging

While CiviCRM works fine on another installation with 4.7.8 in our live system there seems to be some issue with ACL (access control) related to mailings, causing CiviCRM to block the user trying to send a mailing to address any contact.

It seems like the database table group_contact_cache is not filled with the necessary entries in the affected system. However, I don't know why that could be the case.

Answer 4

I was having same problem on Drupal 7.43 / Civi 4.76 and managed to fix it. Unfortunately I'm not sure which action I took achieved the fix - perhaps one of the following will help you.

• cleared all Drupal and Civi caches via the frontend
• emptied Civi Cache tables via phpMyAdmin
• deleted the contents of the templates_c folder
• deleted the contents of the ConfigAndLog folder
• deleted the cache folder in my extensions directory
• I disabled and uninstalled the Cividesk Sparkpost extension
• installed the Proexchange extension github.com/proexchange/com.pesc.sparkpost.

In case this unfairly maligns the Cividesk Sparkpost extension note that I have it working on another of our sites that uses Drupal 6 / Civi 4.76. I am not sure whether it was the problem but I did keep getting errors which may have to do with something else in my installation.

Answer 5

We also had this problem. Following this other issue CRM-19685 and solving it applying the following SQL script fixes the 'Send test' problem.

UPDATE `civicrm_contact` SET `preferred_mail_format` = 'Both' WHERE `preferred_mail_format` IS NULL;

Answer 6

We noticed this issue recently on 4.7.15 but forgot to follow this fix post upgrade. Once we applied it, the error cited above disappeared.

Answer 7

If you are using Amazon SES for sending email, Check Return-Path email domain verified by Amazon SES (it return with error message "554 Message rejected")

More Details here : http://docs.aws.amazon.com/ses/latest/DeveloperGuide/smtp-response-codes.html

Same might be applicable for other provider, Check CiviCRM log for more details.

Answer 8

I know this is an old thread but on the off chance, someone else finds this helpful. I came across this error when I had an unclosed token in an email. I'd use the checksum token but inadvertently removed the final bracket - the email had "www.mysite.org?cid1={contact.contact_id}&{contact.checksum/"

Once I added back in the final '}' all was back to working order!

Answer 9

I think perhpas you are confused about what "send test" does.

The number near the recipients field is the number who will receive the finished email. It has nothing to do with the send test buttons. (Possibly it would be better if they were labelled Send Draft)

Send test either sends one email to the email address in the box if you use the Send test email to: panel (the middle panel in the image below), or it sends a test email to the group you have chosen in the right panel (below Sent test email to group: . In the image below, the test email would be sent to the Case resouces group if the send test button directly below that name was clicked.

The idea of sending a test email to one or a few people before sending the actual email is so that you can check links and formating or perhaps so that others can proofread or approve the email, before you sent it out.

Answer 10

These suggestions have not worked for me (now on 4.7.11). The workaround for this has been to reuse & edit old successful mailings, which seem unaffected.

Answer 11

I had the exact same problem, but it was being caused by an incorrect password in the SMTP Outbound Mail Settings (someone had changed the password and not updated CiviCRM!).

More generally it is probably worth testing the Outbound Mail Settings as a problem here could be causing this issue.

Answer 12

Same problem :

I have just upgraded to Civi 4.7.16 (Drupal 7.54) :

• "Send Test" issues the same message (Could not Identify ...)
• If I overpass the test and send the mailing, the mailing fails : Intended recipients 206 Successful deliveries 0 Bounces 21 (all for "syntax" reason)

CRON Mail Report says :

*Parameters raw (from db settings): instanceId=[ID of report instance] required format=[csv or print] optional-output CSV or print-friendly HTML, else PDF

Parameters parsed (and passed to API method): a:3:{s:7:"version";i:3;s:10:"instanceId";s:32:"[ID of report instance] required";s:6:"format";s:67:"[csv or print] optional-output CSV or print-friendly HTML, else PDF";}

Full message: Finished execution of Mail Reports with result: Echec, Error message: A fatal error was triggered: is not of type String*

I have no ACL defined

Answer 13

I use CiviSMTP

Actually, it is a known issue : there is a patch there : https://forum.civicrm.org/index.php?topic=37194.0

But why isn't it finally fixed in the standard CiviCRM ?

Answer 14

The message identifies one possible cause, but many other problems lead to the same message. A more verbose version might read:

"No mails were successfully sent. This could be caused by many different issues. Known causes include:

• could not identify any recipients
• errors relating to the SMTP service, including authentication or network problems
• invalid tokens in your mail
• no Bounce Processing account configured"

Check the CiviCRM log file - some causes are logged there.

Answer 15

Check that every contact on the list is not 'on hold'.

I deleted the mail server and since this group was used as the first test, all contacts on the list were set to 'on hold'.