Jump to content

4.3 Removing SparkPost


goldmorphin

Recommended Posts

Posted
5 hours ago, Jacques Corby-Tuech said:

Yeah, but now my site can't send emails and I have to waste my afternoon trying to fix it. Sigh.

FWIW, a company I worked at sends ~2 million emails a day through Sparkpost, any issues with it tends to be user error with people not understanding technical email authentication more than anything else. Moving to Sendgrid won't help those people.

exactly, my site cant send emails in the current state... worked perfect as i stated in previous post. 

  • Replies 60
  • Created
  • Last Reply
  • Management
Posted

I'm really sorry a few of you have been inconvenienced by the decision to remove Sparkpost integration and SMTP isn't working for you. I hope I can better explain the decision. 

From our experience and that of our clients, Sparkpost was not always reliable unless you paid for a private IP pool. Otherwise, you're in the same range as spammers and many IPs would be on blacklists. So, the most common scenario is: 

Client: My users aren't getting notifications. 
Us: <20-30 minutes of investigation and testing> It appears the IP address these are being sent from are blocked by the recipient. You may have better luck if you get a private IP pool from sparkpost and enter it <here>.
Client: So I have to spend more money because your software can't send emails? 
Us: No, it's independent of the software. You've opted to use Sparkpost and the range they've allocated to you is shared with others and is blacklisted, which is why your end-users aren't getting their emails. 
Client: A range of what? 
Us: IP addresses. 
Client: I got the pool thing and my users were getting emails. Now Sparkpost cancelled my account and won't tell me why. 
Us: We wouldn't know why either, unfortunately. 
Client: I just want to send email! Why are you recommending a service that is such a pain to deal with? 
Us: <internally> Good question. 

While I understand "if you don't like Sparkpost, just don't use it" - it's not that simple. We provided the integration to provide an easy email gateway solution. When it reaches the point of where it's not so easy and we're hearing about it on a regular basis, it's time to reevaluate. 

We supported Sparkpost and Sendgrid simultaneously for some time and found Sendgrid to be the preferred solution. 

Once again, I recognize the inconvenience it may pose to some and I apologize. We did try to reach out to Sparkpost at one point to get a better solution for our clients, but we didn't get anywhere. This is generally why we're usually very selective at the type of integrations we provide. We only want to provide something that we fully trust and makes things better for the client. Sparkpost, in my opinion, missed the mark for us and was not something we wanted to continue supporting.  

Posted
1 hour ago, Lindy said:

I'm really sorry a few of you have been inconvenienced by the decision to remove Sparkpost

It is not only a few. Just read this topic and theres a lot. 

When a group of clients are happy with a solution, and it does not cost you a dime to keep it running, it would have been better you just left it like it as is. 

I notice that 7 (seven!) different IPS staff had to reply in this topic. That must be more time-consuming for IPS than keeping it up and running. 

Posted

Thanks for the response Lindy. I've read that you can buy a dedicated IP address and then find out afterwards that it has been blacklisted before, when it when previously allocated to a spammer. I guess that scenario could easily happen whatever email service provider you choose.

Posted
3 minutes ago, Kjell Iver Johansen said:

and it does not cost you a dime to keep it running

IPS Support time to respond to tickets costs money, just stating a fact you overlooked.

Posted

I like Sparkpost as well...very much so. I fully understand Lindy's reasoning. With the Sparkpost integration it costs IPS to support.

It would be nice if it could stay as is and a WARNING: added at the integration that all Support for Sparkpost will need to go through Sparkpost if this integration is chosen.

Posted
3 hours ago, Lindy said:

I'm really sorry a few of you have been inconvenienced by the decision to remove Sparkpost integration and SMTP isn't working for you. I hope I can better explain the decision. 

From our experience and that of our clients, Sparkpost was not always reliable unless you paid for a private IP pool. Otherwise, you're in the same range as spammers and many IPs would be on blacklists. So, the most common scenario is: 

Client: My users aren't getting notifications. 
Us: <20-30 minutes of investigation and testing> It appears the IP address these are being sent from are blocked by the recipient. You may have better luck if you get a private IP pool from sparkpost and enter it <here>.
Client: So I have to spend more money because your software can't send emails? 
Us: No, it's independent of the software. You've opted to use Sparkpost and the range they've allocated to you is shared with others and is blacklisted, which is why your end-users aren't getting their emails. 
Client: A range of what? 
Us: IP addresses. 
Client: I got the pool thing and my users were getting emails. Now Sparkpost cancelled my account and won't tell me why. 
Us: We wouldn't know why either, unfortunately. 
Client: I just want to send email! Why are you recommending a service that is such a pain to deal with? 
Us: <internally> Good question. 

While I understand "if you don't like Sparkpost, just don't use it" - it's not that simple. We provided the integration to provide an easy email gateway solution. When it reaches the point of where it's not so easy and we're hearing about it on a regular basis, it's time to reevaluate. 

We supported Sparkpost and Sendgrid simultaneously for some time and found Sendgrid to be the preferred solution. 

Once again, I recognize the inconvenience it may pose to some and I apologize. We did try to reach out to Sparkpost at one point to get a better solution for our clients, but we didn't get anywhere. This is generally why we're usually very selective at the type of integrations we provide. We only want to provide something that we fully trust and makes things better for the client. Sparkpost, in my opinion, missed the mark for us and was not something we wanted to continue supporting.  

The same could be said of SendGrid. This was with their paid service. We were testing it as an alternative to SparkPost on our Beta site, and had paid the $9.95 for the month. Their solution? Upgrade to our 79.95$ package You can get a dedicated IP with that. Why would I want to do that, when I haven't had any issues at all with sending through SparkPost. Even if we were to suddenly start having issues with SparkPost, they offer a far better alternative ($50 for a dedicated IP) than SendGrid.:

image.thumb.png.1eebe22e442a85c4cf2e01a5e51860a9.png

Posted
2 hours ago, sobrenome said:

Will bouncer work with Sparkpost on smtp?

@stoo2000

afaik it should, since its using a webhook during initial setup (if you setup before 4.3 messed things up)... but stoo would be best to answer that one officially. 

5 hours ago, Lindy said:

Otherwise, you're in the same range as spammers and many IPs would be on blacklists.

When I started sending through Sparkpost; free and i dont use a dedicated IP from them. Yes, I was on a few blacklists because of their shared IP range, but after working with their support and getting all my ducks in a row. I am off blacklists and I still dont pay a dime. Instead I now have a broken integration, since the conversion to SMTP; which Tier 3 is trying to figure it out. It shouldnt be this way.

 

I do agree with @PacmanDo, it should be where those integrations support is passed onto SparkPost or SendGrid support. Until the issue is deemed IPS caused. Then their support would inform the client to open a ticket with IPS.

4 hours ago, The Old Man said:

Thanks for the response Lindy. I've read that you can buy a dedicated IP address and then find out afterwards that it has been blacklisted before, when it when previously allocated to a spammer. I guess that scenario could easily happen whatever email service provider you choose.

Exactly... this is a universal issue. So why not just drop support for all email services?

  • Management
Posted

 

2 hours ago, MADMAN32395 said:

When I started sending through Sparkpost; free and i dont use a dedicated IP from them. Yes, I was on a few blacklists because of their shared IP range, but after working with their support and getting all my ducks in a row. I am off blacklists and I still dont pay a dime. Instead I now have a broken integration, since the conversion to SMTP; which Tier 3 is trying to figure it out. It shouldnt be this way.

Yes, that is the biggest issue - by default, they dump you into public ranges that are blacklisted. That's not helpful to our customers at all. One shouldn't have to jump through hoops to reliably use a service and as I've noted many times in the past, our demographic choose us to avoid having to get their hands dirty and unnecessary barriers. We're not going to provide an integration and in the next block of text "you'll likely either have to buy a private IP pool or bounce around with support and hope for the best for it to actually work correctly." 

 

2 hours ago, MADMAN32395 said:

I do agree with @PacmanDo, it should be where those integrations support is passed onto SparkPost or SendGrid support. Until the issue is deemed IPS caused. Then their support would inform the client to open a ticket with IPS.

Firstly, there are legitimate issues with users not getting notifications - sometimes preferences, sometimes user error, sometimes a bug. Unlike other third party items, it's not as simple as disabling all modifications and testing. We have to investigate, it's time consuming and Sparkpost caused us (and clients) more drama and headaches than Sendgrid. It's really as simple as that. 

I know you're frustrated and I'm sorry for your displeasure. We have no affiliation with Sparkpost nor Sendgrid. We get no revenue from either. Our decisions are made in the best interest of the client-base at large and efficiency in providing support. You can argue Sendgrid also experiences similar issues and you're not entirely wrong, but it's to a much lesser and infrequent extent and most importantly, clients have reported more positive experiences and support interactions with Sendgrid. 

Regarding your current issue, I know it's stressful and frustrating to have your emails stop working. Respectfully, this is the point of a beta cycle. The developers are doing a remarkable job and 4.3 is amazingly stable, but some quirks and concerns will take longer than others. If it's a show-stopping issue, you can restore to 4.2 for your production site, use localhost to send mail, use any other SMTP provider or use Sendgrid. 

Finally, we do appreciate anyone taking the time to provide feedback. In many cases, such as the MySQL wait timeout being displayed and folks expressing their concern about it, we can easily say "yeah, that can definitely be done better - we're on it." Or "search sucks, make it better!" Yup, we agree, here you go! Sometimes, though the picture may not be entirely clear from browsing the forum, we make decisions you won't agree with and while we won't reject feedback, we're not interested in arguing back and forth. 

We're open to and are exploring other integration options in the future - mailgun is a possibility. At this juncture, there's nothing further to be gained in this topic. If you have any transitional issues from Sparkpost API to SMTP, please feel free to open a support request.

Sorry again for any inconvenience this may have caused and we appreciate the feedback and understanding.

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...