Body: <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>Has anyone else encountered this?  Has anyone found a solution, or have any ideas?  Thanks!</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-14T15:41:34.427Z
Comments.Text: 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".
Comments.UserDisplayName: Eli Lisseck
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-14T20:02:24.860Z
Comments.Text: 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?
Comments.UserDisplayName: Norris
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-14T20:34:28.950Z
Comments.Text: 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.
Comments.UserDisplayName: Eli Lisseck
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-08-01T19:20:26.067Z
Comments.Text: 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?
Comments.UserDisplayName: Norris
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-08-06T07:39:02.017Z
Comments.Text: Not sure if this works, but trying to tag @EliLisseck in case you didn't see my last reply...
Comments.UserDisplayName: Norris
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-08-06T16:16:41.827Z
Comments.Text: I guess the only issue I see with that is if you need to update the extension, it will regress... but otherwise it seems pretty safe to make that change.
Comments.UserDisplayName: Eli Lisseck
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-18T17:25:27.977Z
Comments.Text: I have just encountered the same behavior, more than 200 ON HOLD BOUNCE in CiviCRM via CiviDesk Sparkpost extension out of about 1500 contacts. Is the fix to modify lines 50-53 working? Have you contactacted CiviDesk on this issue?
Comments.UserDisplayName: Karl Rudnick
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-04-27T15:37:45.830Z
Comments.Text: I have the same problem. I'd have much preferred to use my hosting provider to send email but that has other problems and at least Sparkpost is working in all other respects. Has anyone got a solution yet? In particular I am interested to know whether a dedicated IP address will help. Certainly don't want to move from the free to paid service unless I am sure it will solve the problem. Quite happy to pay if it does.
Comments.UserDisplayName: Mick Kahn
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-10-26T19:04:02.687Z
Comments.Text: @Norris I think it would be dangerous to keep sending to emails that are returning errors 50 - 53 as that will affect the reputation of your domain as well as the SparkPost IP.
Comments.UserDisplayName: Joe Murray
Tags: <civimail><bounce><sparkpost>
Title: Cividesk Sparkpost extension aggressively marking contacts "On Hold"
ThreadText: # Cividesk Sparkpost extension aggressively marking contacts "On Hold"
  
  (Asked by: username_0 on 2017-07-14)
  
  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!
  
  **Tags:** civimail, bounce, sparkpost
  
  > **Comments:**
  > **username_1**: 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".  
  > **username_0**: 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?  
  > **username_1**: 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.  
  > **username_0**: 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?  
  > **username_0**: Not sure if this works, but trying to tag @username_1 in case you didn't see my last reply...  
  > **username_1**: I guess the only issue I see with that is if you need to update the extension, it will regress... but otherwise it seems pretty safe to make that change.  
  > **username_2**: I have just encountered the same behavior, more than 200 ON HOLD BOUNCE in CiviCRM via CiviDesk Sparkpost extension out of about 1500 contacts. Is the fix to modify lines 50-53 working? Have you contactacted CiviDesk on this issue?  
  > **username_3**: I have the same problem. I'd have much preferred to use my hosting provider to send email but that has other problems and at least Sparkpost is working in all other respects. Has anyone got a solution yet? In particular I am interested to know whether a dedicated IP address will help. Certainly don't want to move from the free to paid service unless I am sure it will solve the problem. Quite happy to pay if it does.  
  > **username_4**: @username_0 I think it would be dangerous to keep sending to emails that are returning errors 50 - 53 as that will affect the reputation of your domain as well as the SparkPost IP.  
  
  ---
  
  ## 0 answers
  
  