4.3 Removing SparkPost

[beeurd]

On 17/03/2018 at 12:20 PM, MADMAN32395 said:

Even the alternative port?

Yes, and I'm on shared hosting so I don't stand much chance of getting any unblocked.

[Daniel Simoes]

Send "Bulk Mail" with Spark Post by SMTP... is so so frustrating... (too slow)

Please maintain Sparkpost API support available... as you can see on these post... this is already a VERY used and important feature to Invision/SparkPost users...

Remove these already working feature will be a huge mistake

[MADMAN32395]

Agreed, the free tier was awesome with Sparkpost, nice and quick... and it worked.

now if i look at the alternative... 100/emails per DAY. that's too slow for something thats time limited for an email I would send (such as contests). The paid version imo is too much for how many emails I do send per month... which is little compared to when I do send a mass mailing.

[sound]

 

On 10/03/2018 at 8:02 AM, Kjell Iver Johansen said:

I just like to chime in and say I'm also happy with Sparkpost on my sites. No issues what so ever.. 

Topics like this one makes me doubt that I will change to Sendgrid in a while..

 

4

 

same here, another customer happy  with sparkpost and disapointed that invision are dropping what seemed to be a good working solution

I have used sendgrid, wasn't happy with it so switched back to sparkpost

another factor not mentioned - one that adds up

$79 per month for a dedicated ip account  with sendgrid 

$50 per month for dedicated ip account for sparkpost 

 

 

 

 

[AlexWebsites]

I am using Sparkpost on 3 of my sites and still maintain their free tier. This will be an issue for me if the SMTP version is slow or other. I only signed up for sparkpost because it was free so I'll end up testing smtp to see how it goes but otherwise will revert to standard mail if I have to. At that point I can just smtp amazon ses or other I suppose.

I am using mail bouncer which has been working well with sparkpost.

https://invisioncommunity.com/files/file/6877-mail-bouncer/

[Mark]

As I said before...

On 02/03/2018 at 1:34 PM, Mark said:

As noted, it will still work (though SMTP) and you are not forced to switch. While this will be a little slower, it actually won't be much. Because of the issue with their API being so slow we had already significantly reduced the amount of emails we send per cycle to 100. For SMTP we do 50 per batch, but you can change this with the BULK_MAILS_PER_CYCLE constant if you like. For comparison, for Sendgrid we send 1000 per cycle and it handles that fine.

In other words, if you add this line to constants.php:

define( 'BULK_MAILS_PER_CYCLE', 100 );

It will do exactly the same number per cycle through SMTP as it is currently doing through the native API.

[The Old Man]

Thanks Mark.

A few tips if anyone's interested on sending via Sparkpost with SMTP vs their API...

The Differences Between Using SMTP or API with SparkPost:

https://www.sparkpost.com/blog/differences-sending-smtp-api/

SMTP and REST API Injection Best Practices:-

https://www.sparkpost.com/docs/tech-resources/smtp-rest-api-performance/

Sending limits at your end to consider...

If you're on Shared Hosting, you're webhost or ISP may limit you to 250 emails per hour, some like my web host allow you to make a request for bulk sending and they'll raise and amend your settings for you.

If you're on a VPS (or Dedicated Server), check your host still doesn't still apply limits for anti spam reasons, but you have more control.

You can check current settings in WHM >> Home >> Server Configuration >> Tweak Settings > Mail:

Look for Max hourly emails per domain (The maximum number of emails each domain can send out per hour) and Number of emails a domain may send per day before the system sends a notification (The system will send a notification when any domain sends more than the specified number of emails in a day.)

https://confluence1.cpanel.net/plugins/servlet/mobile?contentId=2449459#content/view/2449459

[sound]

14 hours ago, Mark said:

As I said before...

In other words, if you add this line to constants.php:

define( 'BULK_MAILS_PER_CYCLE', 100 );

It will do exactly the same number per cycle through SMTP as it is currently doing through the native API.

 

rather than x amount of customers having to do this would it not be simply easier for you invision to just keep the current native api in place ?

why drop something that was working ?

 

 

 

[bfarber]

12 hours ago, sound said:

 

rather than x amount of customers having to do this would it not be simply easier for you invision to just keep the current native api in place ?

why drop something that was working ?

As has been explained, it doesn't always reliably work, yet we still have to provide technical support so long as we offer such integration.

In other words, we have clients come to us telling us that the API is not working reliably or they're encountering issues, and we have no way to resolve those issues or concerns. The only recourse we have in this situation is to no longer offer native integration with Sparkpost (*beyond simple SMTP integration which will still work fine), and to shore up our other integration offerings.

[sound]

3 hours ago, bfarber said:

As has been explained, it doesn't always reliably work, yet we still have to provide technical support so long as we offer such integration.

In other words, we have clients come to us telling us that the API is not working reliably or they're encountering issues, and we have no way to resolve those issues or concerns. The only recourse we have in this situation is to no longer offer native integration with Sparkpost (*beyond simple SMTP integration which will still work fine), and to shore up our other integration offerings.

 

Sorry but that could quite easily apply apply to sendgrid as well

I left sendgrid due to issues such as  hotmail.com yahoo.com and yahoo.co.uk emails bouncing, which you could  argue is very similar to saying sendgrid 'doesn't always reliably work'

I then signed up for  a paid service with sparkpost which included a dedicated ip and all seemed to work well

I have also invested in two expensive invision apps - mailbouncer and newsletter and while an expensive solution it seemed worthwhile as the apps, invision and sparkpost all seemed to work well together handing a lot of daily email sends and weekly newsletters with good results and less bounces

so where does all this leave me and other customers now?

choice of a lesser service at a greater cost ?

will the invision apps work with other non-sendgrid email solutions?

sure less support for invision but more work/cost for customers

ah well

 

 

[The Old Man]

 

3 hours ago, bfarber said:

As has been explained, it doesn't always reliably work, yet we still have to provide technical support so long as we offer such integration.

Thanks, I understand what you're saying, but in fairness you only have to support the actual integration, just like Sendgrid, Facebook, Google APIs, AWS etc. The intergration itself seems pretty straightforward, though I'm no expert. If admins haven't followed published best practice, or followed the recommendations and guidelines, or are affected by issues caused by restrictions of their host, or have incorrect server configurations by their host, the API would be blamed unfairly and we get an inaccurate picture. 

I can't understand how massive enterprises like PayPal, Twitter, Pinterest, LinkedIn and organisations like The New York Times would bother using Sparkpost if their API was so unreliable.

There seems far more admins  in support of keeping the API going than losing it here on the forums, and people generally don't post when things are okay or running fine, but when they are having problems.

 

 

 

 

 

[opentype]

51 minutes ago, The Old Man said:

If admins haven't followed published best practice, or followed the recommendations and guidelines, or are affected by issues caused by restrictions of their host, or have incorrect server configurations by their host, the API would be blamed unfairly and we get an inaccurate picture. 

That is irrelevant, because it wasn’t the argument. The complaints about the problems itself were the argument, not what caused them specifically. 

Quote

There seems far more admins in support of keeping the API going than losing it here on the forums

That is logically flawed. The people who had serious trouble with the Sparkpost API just stopped using it and the people who never used it never used it. Both groups have no motivation to argue FOR a removal. They just don’t care either way because they don’t use it. So comparing who is for and against it makes no sense. 

Quote

, and people generally don't post when things are okay or running fine, but when they are having problems.

Yes. So feel free to look up the many posts of people reporting they got banned completely on Sparkpost or had other issues. ? 

[sound]

15 minutes ago, opentype said:

That is irrelevant, because it wasn’t the argument. The complaints about the problems itself were the argument, not what caused them specifically. 

That is logically flawed. The people who had serious trouble with the Sparkpost API just stopped using it and the people who never used it never used it. Both groups have no motivation to argue FOR a removal. They just don’t care either way because they don’t use it. So comparing who is for and against it makes no sense. 

Yes. So feel free to look up the many posts of people reporting they got banned completely on Sparkpost. ? 

2

how many is many nowadays

last year or so seen a few vocal members in a couple of topics, search doesn't drag many more out

https://invisioncommunity.com/search/?q=sparkpost banned&sortby=relevancy&search_and_or=and

[opentype]

10 minutes ago, sound said:

how many is many nowadays

At least as many as those writing in this topic against the removal. See the confirmation from the CEO: 

For a full picture you would need to dig a little deeper than just throwing two words a the search function. 

Quote

last year or so seen a few vocal members in a couple of topics

That too would describe both sides. ? 

[Aiwa]

On 3/17/2018 at 4:56 AM, beeurd said:

Never had a problem with Sparkpost, and the hosting I'm using has blocked the SMTP ports so that method is not going to work for me.

Most hosts block port 25, but I've never seen a host block 25, 587 AND 465.

[The Old Man]

1 hour ago, opentype said:

That is irrelevant, because it wasn’t the argument. The complaints about the problems itself were the argument, not what caused them specifically. 

You've lost me, I'm afraid! We all have differing opinions. I'm not saying Sparkpost is 100%. Nothing is. Somethings about SP bug me too. For me personally, the complaints against SP API just don't carry enough credence. Some undoubtably will be genuine, but I can't believe they were all genuine, justifiable, valid complaints and SP was always to blame.

I recall one admin saying he was banned for sending spam through the SP network which technically did happen because a notification email containing posted spam links went through their network but only because he took the risk of allowing guests to post in the first place. I'm sure I read some admins admitting they had fallen foul of the T&Cs (whether knowingly or not) but were miffed they were suspended or banned.

One admin was critical of Sparkpost's guidelines for unreasonably asking for a postal mail address be included, but in fairness that has been a requirement for US anti-spam legislation for years (since 2003), so it's hardly Spark Post's fault (see point 4):

https://www.ftc.gov/tips-advice/business-center/guidance/can-spam-act-compliance-guide-business

So if the reasons resulting in the complaints are not all valid, the argument and therefore the justification behind the decision to remove it carries less water or is less valid.

Setting up a third party email provider isn't straight forward, so how with any reasonable certainty blame the provider Sparkpost? How can the decision to remove the service be based partly or more so on the assumption that most or all of the complaining IPS clients did everything reasonably required or complied 100%, without really knowing to any reasonable extent whether they definitely took the time to warm up their bulk mail sending IP's, correctly honed and validated their SPF, DKIM, DMARC settings, had no other web-host restrictions or other third party issues, never sent any spam or malware, that they included a postal addresses, had unsubscribe links (although IPS takes care of them on the IPS side of a website), or had correctly set up bounce domains etc.

It's easier to not use and simply ignore the Sparkpost facility if you don't want to use it (just like many don't use Viglinks) rather than losing a facility you are actually quite happy with, have never had a problem with, or especially have paid towards (buying dedicated IPs, purchasing higher sending allowances etc). 

1 hour ago, opentype said:

The people who had serious trouble with the Sparkpost API just stopped using it and the people who never used it never used it. Both groups have no motivation to argue FOR a removal.

A percentage of the ones who had the trouble complained in the forums or via tickets are being used as part of the justification to remove it though. That's why there are links to their topics being used to clarify the decision to remove it.

1 hour ago, opentype said:

So feel free to look up the many posts of people reporting they got banned completely on Sparkpost or had other issues. 

Sorry, I can't take seriously someone who posts they have removed the free tier when they clearly haven't or that posts a topic saying Sparkpost is a worthless pile of manure, as much as someone who says they've not personally had any problems, or were satisfied enough to invest in higher service SLAs or dedicated IP addresses, or spent a while configuring DNS settings or addressed some things they missed and want to retain the service.

For me the other points and aspects relating to the support issues carry more weight. Of course IPS are totally free to include what they want and are comfortable with. 

If a person is unhappy with Sparkpost or doesn't use it, they simply don't have to, but I don't see why such a person would be against anyone asking for the facility to remain, so they can continue making use of it.

I really don't want to type Sparkpost again!

[opentype]

38 minutes ago, The Old Man said:

So if the reasons resulting in the complaints are not all valid, the argument and therefore the justification behind the decision to remove it carries less water or is less valid.

But even if you can demonstrate that, it wouldn’t change what happened from IPS’ point of view (unhappy customers/support tickets and so on) and so it wouldn’t revert the decisions already made, implemented and rolled out. It’s the classic case of beating a dead horse. 

[sound]

1 hour ago, opentype said:

But even if you can demonstrate that, it wouldn’t change what happened from IPS’ point of view (unhappy customers/support tickets and so on) and so it wouldn’t revert the decisions already made, implemented and rolled out. It’s the classic case of beating a dead horse. 

think this 'decision'  reinforces the 'need to shout' on here

anyway now  bowing out of sparkpost and off to try amazon ses email service - which at first look may save me some money once up and running

cue every cloud has a .....

[-FP]

I understand IPS's point... but considering sparkpost worked just fine for so many people, it seems odd to just remove it.

Maybe many of those with issues weren't following the guidelines correctly... like those who claim the software is not working correctly and they have a misconfiguration in the software itself or their server environment.

I think using it with SMTP opens the gate for even more issues, but yeah I get your point people won't be able to complain to you if you don't "officially" have a checkbox for sparkpost.

#BringSparkpostBack

[MADMAN32395]

22 hours ago, bfarber said:

, it doesn't always reliably work, yet we still have to provide technical support

Mine worked great until it was forced into smtp. 

Submitteda ticket and I'm blaimed for misconfigured/restricted. There's nothing to misconfigure if it's going from API to smtp automatically and the key has smtp access. Also there's nothing to restrict when you have full control of the box and a unrestricted connection in and out.

16 hours ago, The Old Man said:

knowing to any reasonable extent whether they definitely took the time to warm up their bulk mail sending IP's, correctly honed and validated their SPF, DKIM, DMARC settings,

Exactly, and steps that we're misconfigured or not setup. I was sent easy to understand guides on setup. Their customer service is pretty good. Even on free, they want to make sure you can use their service.

[The Old Man]

23 hours ago, opentype said:

But even if you can demonstrate that, it wouldn’t change what happened from IPS’ point of view (unhappy customers/support tickets and so on) and so it wouldn’t revert the decisions already made, implemented and rolled out. It’s the classic case of beating a dead horse. 

Well yes, that's unfortunately pretty much what has happened in this topic. I'm a firm believer in trying, even if it's just to say that, just like there are people miffed with Sparkpost, there are also folks reasonably or fully satisfied with SP, also people who have checked to see if the grass is greener on the proverbial other side in Sendgrid/Mandrill-land, some of whom are saying it's not been so lush in their experience.

[ChurchOfPop]

We use sparkpost without issues too, seems like the minority that complains won again with invision removing this useful integration.

[Jacques Corby-Tuech]

On 20/02/2018 at 1:49 PM, Charles said:

You can of course still use SparkPost, or any other email provider, using the SMTP options.

This has been broken since the beta, I get connection refused errors whenever my site tries to send an email.

?‍♂️

[MADMAN32395]

14 minutes ago, Jacques Corby-Tuech said:

This has been broken since the beta, I get connection refused errors whenever my site tries to send an email.

?‍♂️

At least you havnt been told by support to buy SendGrid to fix the issue of sparkpost not working after they did what they did.... What a slap in the face.

[Jacques Corby-Tuech]

11 minutes ago, MADMAN32395 said:

At least you havnt been told by support to buy SendGrid to fix the issue of sparkpost not working after they did what they did.... What a slap in the face.

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.