3

I have the Sparkpost extension working great, but after 3 months of weekly mailings, 225 of my 2000 mailing list contacts have been marked "On Hold." This is a much higher attrition rate than with our old Mailchimp setup.

The Suppression list in Sparkpost only has 25 addresses in it. The other 200 seem to have been set to "On Hold" by the extension because of block bounces - cases where the recipient mail server automatically deemed our email unworthy of delivery, but the actual recipient never asked to be unsubscribed.

I don't want block bounces to permanently remove someone from our mailings. I could use the Sparkpost suppression list to remove our contacts who have actually opted out (marked our email as spam, or clicked the Unsubscribe header in their email client). Then I could re-enable all the other "On Hold" addresses. But it seems tedious to have to do this every month or so.

I found the logic in the extension code where block bounces immediately trigger "On Hold" status, but it's mixed up with enough other bounce cases that it doesn't seem trivial to change how block bounces are handled.

Has anyone else encountered this? Has anyone found a solution, or have any ideas? Thanks!

Improve this question
9
  • I have also encountered this behavior. Are you on a "shared IP pool" with Sparkpost? After examining message events for a long time, i've determined that we are having a lot of issues with the "shared IP pool" IP addresses that Sparkpost assigns our mailings being already blacklisted by many email providers ... for example the other day some of our mailing was sent through an IP where all @verizon emails came back with "571 Email from 52.35.124.222 is currently blocked by Verizon Online's anti-spam system".
    – Eli Lisseck
    Commented Jul 14, 2017 at 15:41
  • Yeah, just using the free Sparkpost account, so it makes sense that we'd get caught up in blacklisting caused by others... How are you dealing with it?
    – Norris
    Commented Jul 14, 2017 at 20:02
  • What really stinks is that we don't really have a large enough mailing list to justify warming up our own IP either... so we are kind of stuck in the middle... I've been using the Sparkpost API to retrieve our message events each week and sorting through which bounces are legit and which aren't... e.g. GET https://api.sparkpost.com/api/v1/message-events?&from=2017-06-16T08:00&events=bounce and your authorization is your API key. I'm sure there is a better way to sort through this but I haven't figured it out yet.
    – Eli Lisseck
    Commented Jul 14, 2017 at 20:34
  • On looking again at the extension code, it seems easier than I thought to tweak how different bounces are treated. In CRM/Sparkpost/Page/callback.php , starting at line 38, the event messages from Sparkpost are mapped to CiviCRM bounce types. I'm inclined to change Sparkpost codes 50 through 53 to "Relay" type rather than "Spam," so that they don't cause an immediate "On hold." These types all seem like the recipient server blocking the particular email, rather than an actual problem with the recipient address. Eli or others, does this make sense based on your experience with the bounces?
    – Norris
    Commented Aug 1, 2017 at 19:20
  • Not sure if this works, but trying to tag @EliLisseck in case you didn't see my last reply...
    – Norris
    Commented Aug 6, 2017 at 7:39

0

Reset to default

Your Answer

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

Browse other questions tagged or ask your own question.