3 sparkpost tools to improve productivity

Email Testing Tools: 3 Handy Tricks

Signing up for email newsletters is fun. I usually spell my email address correctly. Sometimes, when I don’t, someone else with a clever typo in their email doesn’t understand why they’re getting the messages I signed up for. With SparkPost’s handy testing tools (and double opt-in), be protected from Mayhem like me.

We protect our users by detecting negative feedback from email receivers and automatically suppressing future messages from your account to those addresses. It can be difficult to test your integration since SparkPost only emits the events in question under specific difficult to reproduce circumstances. Let’s see how to use a couple of simple tools that recreate those test conditions for you to avoid future Mayhem by testing to make sure you’re applying those suppressions to your list as well.

Negative Feedback

Two types of negative feedback (AKA Mayhem) that can be tricky to test are 1) out-of-band (OOB) bounces, where a receiver initially accepts the message then later sends a bounce notification and 2) feedback loop (FBL) reports which typically mean a recipient clicked a “this is spam” button.

Clicking “this is spam” on your own messages is dangerous because that can damage your sending reputation and composing an OOB bounce is tricky to get right. But don’t worry, we’ve got you covered with some, you guessed it, handy tools!

Simulating Negative Feedback

The first step of testing both types of Mayhem is to send yourself a message through SparkPost. We’ve got a tool for that too! Once you’ve got the message in your Inbox, save the message, including all of the headers, and deleting any blank lines at the very top. You’ll be using this file shortly.

Both of these tests will add the receiving address to your suppression list! Afterwards, you’ll need to manually remove the address to continue to receive emails from SparkPost. I usually use our Postman collection for this. Here are some instructions showing how to get that up and running.

Now, unless you’re connecting from somewhere that blocks outbound connections on port 25 (behind a firewall, residential ISP), you’re all ready to test! The install instructions for both tools suggest some ways to get around blocked ports.

Fake an FBL

The fblgen tool lets you generate and send an FBL report. Here’s a dry run:

Running the same command and adding the –send flag will attempt to deliver the message to the detected MX. This will trigger an FBL event of type spam_complaint, which will flow through to message events and any configured webhooks.  This tool will also cause an increase (of 1) in the count_spam_complaint metric and the “spam complaints” value shown in the SparkPost summary report.

Instead of waiting around for an FBL or risking damage to your sending reputation by triggering one yourself, this tool gives you a way to predictably trigger an FBL event from your own systems.

Bogus OOB Bounces

The oobgen tool lets you generate and send an out-of-band bounce message. Here’s a dry run:

Again, running the same command with the –send flag will attempt to deliver the message to the detected MX. This will trigger an OOB bounce event of type out_of_band, which will flow through to message events and webhooks.  This tool will also cause an increase (of 1) in the count_outofband_bounce metric and the “out-of-band” bounce value shown in the SparkPost bounces report.

Bonus Tool!

Once you’ve gotten a collection of events in JSON format, perhaps by using Postman and our message events endpoint, what’s the easiest way to do some analysis on that data? If you’ve made it this far, then you’re probably comfortable on the command line, and the answer is to use jq!

This handy tool can extract the parts you care about from a big blob of JSON, for example counting the number of events of each type that were received in the last two hours:

Conclusion

With these handy email testing tools, testing those uncommon, hard-to-trigger events is now easy. Making sure these types of events are handled correctly in your integration with SparkPost will help you prevent future Mayhem from striking, by keeping your list clean.

Did you get a chance to try out any of the tools mentioned in this post? Let us know if and how they fit into your testing processes, and feel free to create an issue or submit a PR on Github if there are any other features you’d like to see.

—Dave

leap day 2016

Happy Leap Day, friends! It’s that magical extra day that occurs on years divisible by 4… except if the year is divisible by 100. Oh, but if the year is divisible by 400, then we do celebrate Leap Day. So easy to remember, right? No? How about we make a function to determine if this year is a leap year.

So there you go. 2016 is a leap year. 2017 is not (it’s not divisible by 4). 1900 is not (it’s divisible by 4 and 100, but not 400). 2000 is (it’s divisible by 4, 100, and 400). It’s incredible how much code is required to determine if Leap Day William is bringing you candy this year. Sadly, we as developers can fall victim to errors in calculating dates, but it does make for some good stories. Here are a few of our favorite Leap Day bugs:

  • Back in 2012, there was a bug in Gmail where all chats saved on February 29th showed up as December 31st, 1969.
  • There’s a known bug in Microsoft Excel where it thinks the date 2/29/1900 is real! This means the WEEKDAY function too is incorrect for dates before 2/28/1900.
  • Users of Microsoft Azure experienced an outage on February 29th, 2012 because the service was creating certificates that expired on February 29th, 2013, which is not a valid date.

Fortunately, there are libraries such as moment.js that can help avoid these types of bugs. For instance, you can create dates and determine if they are valid just by doing the following:

However, sometimes you have to be careful with using libraries such as moment.js to calculate dates! One example is determining the monthly billing period for a customer, since days of the month can vary. We define a user’s billing period relative to the date of the month they signed up for a paid account. For instance, if you sign up for an account on January 15th, then you will be billed on January 15th, February 15th, and so on and so forth. Easy, right? But what happens if you sign up on January 31st? February 31st is not a valid date (not even in leap years). In this case, we decided the logical choice is for you to be billed on the last day of the month. So if you sign up on January 31st, you should be billed on January 31st, February 29th, March 31st, April 30th. We use moment.js to handle date calculation, but we have to be careful with it. Check out the following ways to calculate what February 31st might be. (Note: months range from 0-11 in JavaScript, which is why set the month to 1 for February).

In the last line, moment.js assumes you mean “31 days from February 1st,” which turns out to be March 2nd! Not the result we were looking for.

So on this Leap Day (or better yet, before Leap Day), we encourage you to take a moment and test your code for date-related bugs. Does your code know about February 29, 2016? What does it think the date is a year from now? Is that the result you expected? Or maybe it’s time for all of us to switch to that metric calendar system! Whatever happens, just don’t tell your users it’s December 31st, 1969.

–Nancy