clintavo

We and our customers, for many legacy reasons are stuck with using Rackspace Email as our email solution. It works fine, but has the most atrocious spam filtering. Despite over a decade of complaining, Rackspace never fixes it. It sends obviously legit emails to spam (like Amazon order confirmations) and delivers the most obvious spam messages to the inbox.

We'd like to turn off their spam filtering and rely on a third party solution like https://www.cudamail.com/. We don't know anything about these services and I found Cuda Mail just by Googling for "Outsourced Spam filtering service"

Has anyone here used such a solution and, if so, which one seems to be the "best" that members of this community might recommend?

Aside - we can work around the problem for our own internal emails by simply forwarding emails to Gmail and relying on Gmail's filtering, however, our customer base is VERY un-savvy technically and we'd like a third party solution to simply solve this problem for our less technical users.

Any help or recommendations would be much appreciated. Thanks in advance!

We are seeing all kinds of network problems seemingly related to cloudflare but there is no incident on their status page. Is anyone else seeing issues?

Hi HN,

Hoping someone else has seen and resolved this issue. We've been testing moving some email sending load over to Mailgun from our current provider. One of our main goals is to improve performance and speed by utilizing Mailgun's batch sending api with recipient variables.

We've run into an interesting issue and aren't sure how to resolve it (or if we can resolve it).

When we submit the batch, Mailgun does indeed send all the messages in the batch, whether it's one or 1,000. However, Mailgun assigns them all the exact same "Message-Id" header.

This causes strange and undesirable behavior in the email clients. Specifically, if an email client receives two or more messages from the batch, it simply drops all but one of them. It's as if they don't exist. That's because the Message-Id header is supposed to be, according to the RFC, unique for each and every message. That's why it appears to exist. Mailgun APPEARS to be violating the RFC by setting the Message-ID header as the same for each message in the batch. We were able to "resolve" the issue by passing the messages to Mailgun's api one at a time, but that is not a real solution. That worked for testing a dozen messages, but what about when we're sending 300,0000 or 1,000,000? That's part of the reason we wanted to use the batch api. Our opt-in newsletter is around 70,000. We'd rather make 70 api calls instead of 70,000 for obvious reasons.

here is the actual RFC: https://tools.ietf.org/html/rfc2392

It states, "the message-id of an email message to refer to a SPECIFIC message." and "Both message-id and content-id are required to be globally unique. That is, no two different messages will ever have the same Message-ID "

Has anyone else seen this? And (please), if you have, has anyone else come up with a way to resolve it?

Hi HN. We've used Pingdom for over a decade but in the past year the alerts have become increasingly unreliable. I never get alerts on my phone anymore despite triple checking every setting and interacting several times with their support people (who kinda just stop responding).

We added Slack webhook integration and started using a Slack channel as the alerting piece, which is OK, but Pingdom doesn't seem to honor their "Alert only after down for more than 10 minutes" setting when sending webhooks to Slack. So we get bombarded with tiny up/down up/down alerts when any minor glitch happens (even network connectivity glitches), which is why we set the "Alert only after down for more than 10 minutes" in the first place. We opened a support ticket, but given past support responses from them, we are not hopeful for a solution.

Long winded intro to the question - what would you recommend as an alternative to Pingdom? Looking for someone who's stable, established and not going anywhere obviously.

Thanks in advance.