Postmark Blog

New Code Examples Postmark Inbound in PHP & Python

alexknows — Mon, 30 Jan 2012 11:26:16 -0500

Hot on the heels of the Node.js example we shared last week, we recently had two new “mitt” libraries contributed to make it easy to process JSON data sent in Postmark Inbound’s webhooks.

NEW PHP Mitt:
Joffrey Jaffeux has built a well documented PHP mitt, and has even included instructions for using this code to process inbound emails in CodeIgniter projects.

NEW Python Mitt:
Inspired by Joffrey’s contribution, Jose Padilla developed a similar project for using Postmark Inbound in Python.

And don’t forget that there is still the Postmark Inbound rails gem developed by Randy Schmidt.

Many thanks to both of them for their contributions!

We are actively looking for your contributions for other languages to add to our developer documentation. If you write a code sample or library for Postmark Inbound, please email us at support@postmarkapp.com. Contributions are appreciated and quality contributions are rewarded with free Postmark credits.

We have a low-traffic API developer email list that you can join as well.

Learn to use Postmark Inbound with Node.js & CouchDB

alexknows — Fri, 20 Jan 2012 18:49:27 -0500

Since our launch on Tuesday, we’ve gotten lots of great questions and comments on Postmark’s new inbound email parsing service. Since, Mark Headd made a great open source contribution that we’ll be adding to our docs: a Node.js listener for Postmark Inbound that stores emails parsed by Postmark in CouchDB.

Even cooler than just open sourcing the code, Mark went above and beyond and recorded a handy screencast to walk you through what he built and how to use it - including the handiness of the way CouchDB handles serving up attachments (watch the video, you’ll see what I mean).

Big thanks to Mark for his contribution, and going the extra mile with the screencast which I’ve embedded below.

If you’d like to earn some free Postmark credits, email me and let me know what you’ve built that can help other people use Postmark Inbound easier! Code samples, screencasts, walkthroughs - the more useful and creative your contribution is, the more credits you’ll get!

Discuss this on HackerNews.

Introducing Postmark Inbound: Easily parse replies & other incoming email into JSON for your app

alexknows — Tue, 17 Jan 2012 04:24:00 -0500

Postmark started by solving the pain of sending emails from your web applications. Today, we’re closing the loop by making it just as easy for everyone to be able to parse incoming emails.

You already know that if your web app sends email, it’s sending it more reliably with Postmark. But wouldn’t it be great if your web app knew how to listen for incoming emails? We thought so too, that’s why we created Postmark Inbound.

Every Postmark server now includes an inbound email address. We’ll turn anything you send to this address into a beautifully formatted JSON object and post it to your application over HTTP, complete with email contents, headers, even attachments.

Postmark inbound is perfect for:

Replying to in-app messages.
Analyzing and acting on email content.
Creating tasks, reminders, and posts.
Using email to upload files.
And more!

We’ve worked hard to keep Postmark simple, including how you pay for it. Just pay for what you use, starting at $1.50/1000 emails. The same Postmark credits can be used for outbound and inbound email processing.

Try Postmark Inbound today

Postmark Inbound is available for all Postmark customers and new accounts immediately. Our developer documentation is available to help you get started.

You can also learn how popular issue tracker Done Done and our own hosted version control system Beanstalk use Postmark Inbound every day.

Enjoy!

P.S. Are you as excited about this as we are? Share that excitement on HackerNews!

We should have an emissions check for ESPs

natalienagele — Wed, 14 Dec 2011 16:32:55 -0500

Chris’s posted yesterday about the problems with selling dedicated IPs and along with the comments, it got me thinking about what we, the industry of Email Service Providers, are responsible for. At Wildbit, we feel an obligation to rid this world of spam and junk mail. It’s not like it’s a higher calling, it’s just the right thing to do as an email service provider (ESP). ESPs are the gateway to a lot of junk mail, not just spam mail. It’s the junk mail that’s difficult to police but be believe can and should be done by every ESP.

Junk mail vs. Spam mail

We talk a lot about spam in the email industry, but we don’t talk much about what I consider “junk mail”.

Like the random take out restaurant flyers you get in your physical mailbox, junk mail is the catalogue equivalent for email. These are newsletters and announcements and marketing emails that are mostly useless to many people, but don’t necessarily fit the definition of spam. You probably signed up for a list at some point, but the list owner is overstepping with the quality or quantity of their mailings. We dealt with this a lot when we ran our email marketing service. What’s important is that ISPs are now taking a stance against this type of email by keeping track of whether these get opened, read, etc (engagement).

Now, this junk mail does generate some spam complaints, but often not tons. Therefore ESPs allow these emails to go out day after day. Why? Because it’s not causing global delivery issues (at least not right away). These emails just get marked as spam, but anyone else sending through that IP won’t necessarily get flagged as spam.

Our view

At Postmark, we don’t deal with this problem nearly as much as we used to with our email marketing service. Most transactional email is expected and triggered by a user’s specific action. Even with that we keep our spam threshold extremely low. Some emails still trigger spam complaints, commonly things like invite friend tools, auto-responders, etc. We keep a strict eye out for that kind of activity and ban it from Postmark if it becomes abusive.

Strict? Maybe. There’s a fine line between what the marketing department wants to accomplish and what a customer or recipient wants and expects. Sending the same automated email 3 times a week is probably going to piss people off.

That’s junk mail, and we don’t stand for it.

Emissions Testing For A Better (Emailing) Environment

ESPs are polluting the environment allowing people to send this junk. There are so many groups and tools out there to block the spam after it happens, but I’m not seeing a lot of ESPs working on stopping the junk from being sent in the first place. The punishment to an ESP for sending junk just isn’t as high as sending spam, so everyone concentrates on keeping the African princes away, but not the retail newsletter that got sent out every day last week.

There’s a lot of money to be had in sending junk mail (both paper and electronic). We think that there should be more of an effort made by the ESPs to do better than the minimum requirements set by ISPs. Think of it like car companies getting awarded for having lower emissions than the minimum requirements. They are actually working to help the environment, not just keep it from getting worse.

The false promises of dedicated IPs

cnagele — Mon, 12 Dec 2011 15:01:25 -0500

I have to admit, I am disappointed in the false promises that companies are giving when it comes to offering dedicated IPs for their customers to “improve email delivery.” The reality is, dedicated IP addresses are not a sure way to improve delivery, and sometimes, can actually hurt email delivery. Before I jump in, let me first explain how IP addresses play a role in mail servers and sending email.

When confronted with the task of setting up an outbound mail server, there are a lot of things you have to consider. The first and foremost is making sure that all of your outbound emails are always sent from a consistent public IP address. This IP becomes the unique identifier that ISPs, accreditation services and blacklists use to track your activity and your reputation as you send. Once you have a dedicated IP, you can then continue the process of making sure you have proper reverse DNS records, adding it to your SPF records, setting up feedback loops and so on. I wrote a short guide on this back in 2007, most of which has stayed the same.

When it comes to Email Service Providers (ESPs) like Postmark, we go through this process on behalf of our customers and use a range of dedicated IP addresses that are shared amongst all of our customers. The other approach is to provide a dedicated IP address for each customer. I think this is a bad idea.

Why offer a single customer their own dedicated IP?

It’s pretty common for ESPs to offer dedicated IPs to a single customer. When we first launched Postmark this was one of the options (as a coming soon) when you created a new server. The idea behind a dedicated IP is to isolate reputation, throttling and blacklists to each customer. This helps with diagnosing issues and can avoid one customer killing the reputation of another if something goes wrong. The other advantage is that the customer can create a custom sub-domain for the dedicated IP, essentially looking like it is coming from their own servers.

From the ESPs side, it is a point of protection as well. If a customer decides to start spamming and the IP gets blocked, it will not hurt other customers on the system (only half true - covering this next).

Why offering dedicated IPs is a bad idea.

A dedicated IP sounds like something exclusive and attractive when customers look at what ESPs offer. In reality though, it’s a means of retreating from the overall responsibility of being an ESP.

By offering a dedicated IP for the majority of customers the ESP is basically saying “You do what you want, if you get blocked it’s your fault.” It also places a lot of heavy lifting on the customer, which defeats the purpose of paying for an infrastructure product in the first place.

In addition to this, new dedicated IPs are just as bad as IP addresses with a bad reputation, since it has no reputation at all. In order for an ISP (Gmail, Hotmail, etc) to trust email traffic, they need to know your history. If an ESP just gives you a new IP and you start sending a bunch of email through it, you’ll need some serious good luck. In most cases a new IP address get’s “warmed up” first. Basically you take a new dedicated IP address and send a small number of emails out over time, slowly increasing it each day until it has a good reputation. If the ESP does not do this for each new dedicated IP, the customer is going to have problems.

The other misconception with dedicated IP addresses is that each one is completely independent. For instance, if one customer gets blocked, all other IPs are fine, right? Wrong. ISPs and blacklists will monitor entire IP ranges and domains. If one IP causes enough problems, traffic from the entire subnet or domain could be blocked.

The final reason, and this one is important, is that ISPs are starting to place a lot of weight on domain reputation, not just IP reputation. My guess is that over time IP reputation will slowly fade away while more weight is given to domain reputation along with authentication standards like DKIM. This allows you to take your reputation with you and ties the reputation to the brand (your domain) which is a lot less disposable than an IP address. In a recent post from Laura Atkins, a highly respected consultant in the industry, she stated:

Domain reputation is where delivery is going. And I think a lot of senders are going to struggle with delivery as they find that IP reputation is not enough to get into the inbox.

We feel the same. And that is why we push DKIM and SPF so much in our setup process. It’s also why we are thrilled that over 60% of our customers use DKIM or SPF on our service, a huge accomplishment for us.

Why we decided to stick with shared IP addresses.

For the reasons above, we decided earlier this year to remove dedicated IPs as a feature. Our goal at Postmark is to make email delivery dead simple. Developers, designers and system administrators already have enough to deal with and email delivery should not be one of them. We also have a very acute focus on our email delivery rates. If emails are not getting to the inbox, using Postmark is not justified, no matter what additional features we offer.

To make sure our delivery is rock solid it’s our job to take 100% accountability of our IP addresses and our reputation as a sender to the ISPs. So instead of offering a dedicated IP address to a customer and send them off, we carefully and cautiously monitor a set of shared IP addresses for all customers. This helps in several ways:

We have a very high volume across each IP address, which gives a proven history of good sending practices with each ISPs. High volume with great sending practices means fantastic inbox rates.
We avoid the problem of constantly warming up new dedicated IPs, risking delivery issues for new customers. A customer can hit the ground running.
We take full responsibility for the reputation of our IPs, giving us extremely high reputation and delivery rates.
We can encourage our customers to use DKIM to focus on domain reputation, instead of IP reputation.

This also means we actively kick customers out if they are not following our sending guidelines or terms of service. We have a very low tolerance for spam complaints, 10 in 10,000 emails. If a customer throws any alerts and does not clean up the problem we act fast. Some might think our tolerance is too low. However, spam complaints should be almost non-existent for most transactional email, and anything that could hurt our reputation is not worth the extra money that the spammy customers bring us.

Joining Postmark is like being part of the “good senders club”, with all the benefits of emails to the inbox.

When dedicated IPs make sense.

Obtaining a dedicated IP (or many of them) can still make sense, but the decision is directly related to volume. For instance, we can’t just send on a single IP address. There is a point where too much volume can cause throttling at the ISPs, so you need to spread out that traffic across multiple IP addresses. In some cases we will recommend a dedicated IP address for customers who send an extremely large volume. This only works when the customer sends a lot of emails to all of the major ISPs. If you send a ton to Gmail but not Hotmail, you’re going to have issues delivering to Hotmail. Each ISP can only build a reputation on what they receive. Another benefit of a dedicated IP is getting accredited from services such as Return Path and ISIPP, allowing customers to track their individual reputation. In reality though, the majority of customers never have to worry about this. They leave it to us and we take care it.

Summing it up

While a dedicated IP address for an email service might sound sexy, it’s not a true solution for getting to the inbox. ISPs only care about proper sending practices and a solid reputation. Instead of requiring every customer to build that reputation from scratch we feel it is better to allow approved customers to leverage our reputation, helping them get to the inbox immediately and without the hassle or care of how it works. Sure, this means we spend more time policing our customer’s sending practices and kicking the trouble customers out, but that just means better email delivery for the rest of you.

Over 61% of Postmark customers authenticate their emails. Do you?

natalienagele — Wed, 07 Dec 2011 12:51:33 -0500

I don’t think we can stress enough the importance of authentication in sending email.

Every day we find customers who have delivery issues that are instantly solved by updating SPF records or signing their emails with their own Domain Keys. Because we know how critical it is, we’ve built it right into the Postmark setup process. Interestingly, we actually have customers who think it’s a required step to use Postmark, and we don’t think that’s a bad thing.

Amazingly, over 60% of all Sender Signatures of our customers have DKIM and/or SPF setup correctly.

And of course, custom DKIM comes with any account for free, whether you are using the first 1000 credits or you’re a high volume sender.

Sign your emails, remove the doubt

ISPs have a lot of tools at their disposal to check if what you’re sending to them is legitimate mail. As they continue to evolve, they get smarter and smarter at making that important distinction.

The new word of the day is engagement, the idea of ISPs watching what customers actually do with your email. For instance, whether they open it or send it to trash right away. If they open it, how long does it stay open?

All of this is meant to protect the recipient from not only Viagra email, but also useless junk mail. You can avoid a lot of delivery problems by simply telling the ISP who you are. Engagement, content scanning, etc are tools that ISPs use if they have doubts.

Your job, remove the doubt. And we’ve designed Postmark to help you do that.

The “why” to signing your emails

When an email is sent to the ISP, they:

check the IP reputation
check the domain reputation
check the content

We’ve got the IP reputation covered for you, but you are in control of the other two.

Content is the really tricky one, so you at least want to make sure the other two are rock solid. Your domain reputation is 2 parts being a good sender and 1 part making sure the ISP knows who you are. When you use an ESP, that means telling them that you have allowed us to send emails on your behalf.

What’s nice about transactional email, our speciality here at Postmark, is that most times you don’t need to worry about the tests of engagement, so long as you’ve shown the ISP that you are following the rules. Signing your email is key here, because once it’s signed, you’ve taken a lot of the doubt away. For example, a spammer can try to spoof @adobe.com. What they can’t do is access Adobe’s DNS, so they’ll never be able to sign their emails. When AOL sees an email from Adobe that’s not signed, it’s easier to make the decision to trash it.

“But I need to send on behalf of my customers”

If you’ve been whitelisted to send from many domains, you probably heard from our team that we don’t recommend it, but we’ll do it if you need it. The reason we advise against it is that you end up sending email without authentication.

When you send from your customer’s email address, you’re not going to be able to sign that email with DKIM. Instead we’ll sign it with our own DKIM, but that comes with issues as well - like GMail’s “via” tag for example.

Our recommended approach is to send from your own email, and then change the From Name and Reply To to be the customers. For example:

"Bob Smith" info@yourcompany.com, reply to: "Bob Smith" bob@smith.com

Takeaway

Getting to the Inbox is really hard already. As a company, we want to make it easier, but we can’t do it all for you. We take a really strong stance on recommending email authentication to our customers in Postmark and we’ve designed it into our workflow to make it simple. With what we’ve seen, you’re doing yourself a huge injustice without it. ISPs, even smaller ones, are starting to make this a requirement for getting through.

Do yourself and your recipients a favor and just follow the simple rules. It’s already a difficult job. Not using DKIM yet? Go to your sender signatures page and follow the steps or sign up for a Postmark account and see how easy it is.

Postmark Spam Score API in the Wild - Spamscore.me and Christmas is Saved on Reddit

alexknows — Wed, 16 Nov 2011 11:03:00 -0500

A few weeks ago we released a free API for checking the spamscore of a message. The folks on HackerNews loved it, and it’s been really great to see people find ways to get more value from this API.

Some of our favorite usages have shown up in just the last week!

Spamscore.me

We released our Spam Checking API with an easy and beautiful UI, but it does require that you grab the full email contents including the headers. Simple as this is, it’s work. Wouldn’t it be great if you could just forward an email somewhere, and moments later, get back a nicely formatted report about your email’s spamscore?

That’s exactly what Jim Carter built with spamscore.me. The cool thing about spamscore.me is there’s no interface other than your email client! Just forward any email to go@spamscore.me and get one of these bad boys back.

It’s free (but no less awesome), so please be kind to Jim’s servers. Have other ideas for useful mashups with our spamscore API? Let us know in the comments, or better yet email me once you’ve launched so we can write about it here!

Christmas is saved on Reddit

Our hearts were warmed to find that someone recommended our spamscore checker to a Reddit user whose christmas eCards were being sent to spam.

Chris was able to jump in and do a quick analysis of the person’s spamscore report, recommending the following to help with the resolution:

Set your Return-Path header to a domain and address that you control. Then, add an SPF record to that domain with the permitted SMTP servers.
Do not use your user’s email as the from address. This is spoofing and you can’t control the DKIM or SPF. Instead, use their “From name” but your email address.
Make sure Reverse DNS is setup for your SMTP server.

While we can’t promise personal spamscore report interpretation for every problem, we’re thrilled to see that this tool is being used to help solve real world problems in people’s applications.

Have you used the spamscore API to successfully track down a problem? Let us know in the comments.

New Postmark System Status Dashboard

alexknows — Wed, 02 Nov 2011 12:34:00 -0400

We work very hard to keep Postmark reliable and available for our customers, but sometimes things go wrong that are out of our control. We do our best to communicate the details of any issues we’re having, and make it a priority to prepare you for any planned maintenance or downtime.

Not everybody follows us on Twitter, and emailing our entire customer base isn’t always the best solution either. So today, we’re launching our new Postmark System Status page.

We’ll continue to post updates to Twitter and provide our in-app notices. We’ll still email you ahead of time for planned maintenance. But if you’re ever experiencing a problem and want to know if you’re the only one, you can now visit status.postmarkapp.com and look for recent updates about any known issues. If something is going on, the big banner on top will make that clear and the status updates below will provide more detailed information.

You can also subscribe to these updates via RSS in your favorite RSS reader, or even subscribe to email updates in your inbox if you prefer.

This is just one more step we’re taking to make sure that you know we’re working hard to provide an easy, fast, and reliable service for delivering your transactional emails to the inbox!

What Happened This Morning

cnagele — Thu, 20 Oct 2011 15:39:47 -0400

This morning at about 8:15am EDT we had an outage on our primary MySQL server. It affected sending, the API and our web interface. No emails were lost, but you would have noticed delays. I want to give a brief overview on what happened, how we recovered and where we are now.

The outage occurred when our primary server ran out of disk space. We have systems that monitor for things like this on each server to alert us. In this case, the space grew much quicker than normal, so by the time the alerts were noticed MySQL was already struggling.

In most cases when we have an issue with MySQL the impact is minimal. We run a high availability environment with MySQl-MMM, which usually detects any problems and automatically fails over to a healthy server. Unfortunately in this case MySQL was still running - it was just having issues writing certain data to disk, so it never got the trigger to fail over.

We struggled a bit to free up some logs and space and after about 30 minutes decided to just fail over to the second server. In hindsight we should have done that right away, but we wanted to make sure replication was healthy first.

Once we failed over manually, things were back to normal and we just had to recover any failed jobs. We have a nice fail safe in Postmark where if the DB is unavailable we queue emails locally on each server so we can successfully send them when we recover. This came in handy today!

Moving forward, we’re working on some upgrades to the cluster that will focus on availability and performance. We’re also going to make the alerts a bit more sensitive to make sure we catch potential issues sooner.

I’ve very sorry for the early morning chaos. It was definitely not the way I wanted to start my day and surely not how we wanted all of you to start your day either. As always, we’ll work hard to minimize issues like these and improve reliability. We know you depend on us, and thank you for your patience and trusting us with your email delivery needs.

Checking Spam Scores is now as easy as Postmark

alexknows — Mon, 17 Oct 2011 11:10:00 -0400

Postmark’s sending infrastructure works to carefully, quickly, and accurately deliver your transactional emails to your customers’ inboxes. The most common problems that occur outside of our configurations are related to content, and our customer service team often works with customers to improve dodgy email content that’s causing emails to land in the spam filter.

Today we’re announcing a new easy and free API to help you score the quality of your outbound (and inbound) emails. This JSON API provides easy and fast programmatic usage of the spam filter tool SpamAssassin.

Simply POST an email’s contents, all headers included, against our API and we’ll return a score. If you want, we can also return a full report in your call.

Not API savvy? No problem! Our landing page for the API provides a fully functional scoring & reporting tool for you without having to ever write a line of code.

Write an API wrapper, Get Free Postmark Credits

This API is silly-simple, but we want to make sure that it’s useful. One way to do that is to make sure that there’s a simple interface to it in everyone’s favorite programming languages & frameworks.

We’ll give 10,000 free Postmark credits to the first person to write and open source a complete API wrapper for our Spam Score API in a given language/framework. We’ll compile a directory of the wrappers and publish them along with the API.

Our own Oren Mazor (who wrote the API) has provided an example library in Python, if you’re looking for patterns to follow.

To submit an API wrapper, email a link to your repository to alex@wildbit.com. We’ll provide the free Postmark credits to one winner per language/framework, based on the timestamp of the submission.

HackerNews Discussion

We “soft” released this on Friday night and there was some great discussion on HackerNews, spending most of the weekend on the home page. Jump over to the comments thread to see what people think!

Major Performance Fix in Postmark's Activity Search

natalienagele — Tue, 27 Sep 2011 13:24:00 -0400

As too many of our customers know, we’ve had an ongoing battle going on with our search functionality in the Postmark Activity pages. With the rapid growth of Postmark compounded with storing more days of “Sent” message activity (we’re now storing 15 days instead of 10 days), we’ve been working hard to refactor our activity search to - well, actually work quickly and consistently, for quite a while.

Our largest senders, and even some of our medium sized senders, have consistently seen time outs when doing a search on their Postmark Activity pages.

This morning we released the newly improved search algorithm, and it’s performing extremely well. Searching our largest accounts takes just a few seconds, which means most accounts respond to search queries almost instantly.

What Changed?

Milan, who’s responsible for all of the improvements, will provide more details on how the search parameters have changed in a future post. For the most part, there are no differences to what you are used to. Just like before, you are able to search for a recipient, as well as the subject of the email. This is very helpful for troubleshooting delivery issues, inactive recipients, etc. Searching your Activity checks for successfully sent emails along with, bounces, spam complaints and SMTP API errors.

Speaking of SMTP API errors, we did include a small change to the way we will be storing these in your accounts. Prior to today, we would store SMTP API Errors indefinitely. These are generated when you use the SMTP endpoint, informing you that we didn’t send your email. The 2 main causes of this are: invalid Sender Signature or you’re trying to email someone that has been marked inactive (due to a hard bounce or spam complaint).

In both of those cases, you don’t need to know about these errors forever. We actually got a lot of requests to remove these from accounts to clean them up. So, from today on, we will be removing SMTP API Errors from the Activity feed after 15 days, just like sent emails. This will help with the UI as well as the search functionality.

Thanks!

We’re really excited about this update because we rely on search just like our customers. Having it reliable is crucial to troubleshooting, which is what we’re here for as a service. We just want to thank our amazing customers for their support while we completed this important fix.

Thanks so much, you are so awesome!

Wordpress Plugin Updated!

alexknows — Tue, 20 Sep 2011 11:48:55 -0400

We’ve updated our Wordpress plugin that was announced last month to incorporate a number of important bug fixes, including proper support for HTML emails. Thanks to the customers who reported these bugs.

We’ve also added a standard Wordpress license to our plugin to comply better with community standards and expectations.

And of course, a big thanks to our plugin maintainer - Andy Yates - for all of his hard work.

The plugin can be easily auto-updated from within Wordpress or installed from the Wordpress plugin codex.

Wordpress SMTP Problems are solved with Postmark.

alexknows — Thu, 11 Aug 2011 10:08:00 -0400

If you’ve ever been responsible for a Wordpress site but not been in control of the server you’re hosting it on, you might have run into issues where important emails - welcome emails, password resets, comment notifications, and more - didn’t send at all. This is usually because the server’s admin has disabled the default SMTP server, or perhaps disabled the PHP mail() method that Wordpress uses to send mail.

Or if you’re on shared hosting, you may have found these emails were sending after all - they were just going to your spam folder.

Today, we’re launching a Postmark Approved Wordpress plugin to make all of these problems a thing of the past.

Simply download our plugin from the Wordpress Plugin Directory or search for “Postmark Approved” from inside your Wordpress admin for the easy one-click install.

Once installed, simply plug in your Postmark API Key and the email address of a verified sender signature, and you’re ready to go. We’ve even made it easy to send a test email to make sure it’s working before you click enable.

Why go “approved” when there’s other options out there?

The biggest challenge in having “unofficial” plugins in the wild is debugging problems when they arise. It’s also hard for us to know about how people are using the plugins, and what’s good or missing. We’re hoping that being closer to an “approved” plugin will allow us to keep a closer eye on the problems that Wordpress developers have, and evolve the plugin as well as Postmark to better serve the massive and growing Wordpress community.

As Postmark features evolve, we can help keep the plugin fresh as well.

Postmark has grown in part thanks to the support of dozens of the people who’ve created and shared Plugin & API wrappers for their favorite languages and platforms. We’re thankful for everyone’s hard work, and continue to work with third party developers to help deliver the best tools for working with Postmark.

Feature requests? Hit us up in the comments, or email us.

A Special Thanks

We invited Andy Yates, who we knew from his work on Magic Bean (a 3rd party iPhone/iPad app for our other product, Beanstalk), to lead the development of this plugin with our guidance and assistance. Always vocal supporter of Wildbit products, we’re immensely appreciative of Andy’s effort dedicated to this project.

Postmark design updates & multiple API keys

alexknows — Thu, 21 Jul 2011 13:53:00 -0400

Over the last few days we’ve rolled out some design enhancements to the Postmark web application, and we wanted to make sure you got to check them out!

First and formost, every server’s “Overview” screen has been renamed to a more descriptive “Statistics” screen. This view provides you an “at-a-glance” way to see what your sending statistics are looking like on a month-by-month basis, either as a graph with daily sending volume or as a table that also shows cumulative bounces and spam complaints for the month. The graph and the table now display information from the same month, making it less confusing to look at your sending statistics.

If you visit your Credentials screen, you’ll notice that you can now create additional API keys for every server in your rack, and even delete old API keys if you need to take them out of rotation. This will allow Postmark customers to follow better security practices. If somebody were to get ahold of your API key, they could send emails as you. Now, it’s easy to periodically create and install new keys, and since we allow you to run more than one key at a time, you can slowly and carefully phase the expired ones out.

We think that these improvements to UI and the secure use of the Postmark API will come as helpful & welcome additions to all new and existing Postmark customers!

Who's side are you on, anyway?

natalienagele — Wed, 13 Jul 2011 16:41:57 -0400

I recently had a discussion with a company that wanted to use our service, and we sent them away (amicably, I promise). We weren’t a good fit because of Spam and bounce rates. They weren’t sending spam, but they were using third-party acquisition of users.

The conversation was lengthy, and one point really stuck out. The customer asked me,

“So you’re not on the side of your paying customer’s, but instead working for the ISPs?”

I think this is a really important question that email service providers need to answer clearly. I can totally see how it looks this way, so let me debunk.

We are on YOUR side, first and foremost. You, being our customer, and also you, a person who receives email.

Our job is to prevent spam or unnecessary/unwanted email from reaching the ISPs. This job is not easy, because while a Viagra email is obvious, unwanted email is hard to identify.

Nobody likes to admit it, but ISPs have a really tough job sorting through email. The bulk of what they process is spam, and they do their best (some better than others) at keeping those messages away from your inbox. In an effort to make their jobs easier, they ask us, the ESPs, to be vigilant about what we allow our customers to send. Luckily for them, they are very good at persuasion, since they have all the control. They have a great set of punishment tools:

Email throttling/delays
Sending the email to the spam folder
Discarding the email completely

These responses are what our customers pay us to help them avoid, and we do that by supporting the ISPs. At Postmark, our spam threshold is extremely low, because we want the ISPs to love us (and in turn, love your emails).

We monitor bounce rates as much as spam, because sending to an old/nonexistent subscriber looks like spamming and upsets ISPs, not to mention there may be a hidden spam trap. And when we do “fire” some of our customers, no matter how much we love them, it’s because our relationship with the ISPs is important for the customers who are playing by the rules that the ISPs enforce.

The answer, though, is that we’re always on your side, but to be on your side, we have to also be on the ISPs side. We need to help and support them, so they help and support you. We want your emails to fly through quickly instead of sit in queues, so we register as transactional senders and don’t allow bulk mail. We keep our emails going to the inbox, similarly, ensuring only the best content is being sent.

The care we take is what makes us a good partner in your email delivery.
The ESPs that don’t care, don’t deliver.

DKIM and the "via" label in Gmail

cnagele — Wed, 29 Jun 2011 13:07:00 -0400

Gmail made a recent change to help people identify spoofed email and verify the identity of senders in your Inbox. It’s a great addition, especially knowing how easy it is to send email pretending to be someone else. As part of this change, Gmail added a subtle but important label in the ‘From’ address field for emails called “via.” This is added for any emails that are sent from third-party senders like Postmark or Newsberry. Here is what it looks like:

What is pm.mtasv.net?

This is the return-path domain that Postmark uses to send emails. We use it to identify ourselves, build a reputation and process bounce messages. If emails did not come from a domain we owned we would not have the control we need over delivery, reputation and bounce statistics that help us run the service.

Wait! But I don’t want people to see that!

Of course not. And neither does Gmail, if your sending is optimally configured. To make sure this bit of information does not show up in emails you send to Gmail, all you have to do is make sure you are signing your messages with DKIM. We make this process very easy. Once you start signing with DKIM, that “via sender” does not display anymore. If you visit the “Signatures” tab in your Postmark account, you’ll see tools to configure and even verify the optimal DKIM configuration. It does require access to your DNS configuration, so you may need some assistance. Email support and we can guide you through it.

What if I send on behalf of other customers?

If you can’t add DKIM records to your DNS, then the “via pm.mtasv.net” will still display. This is how Gmail intends it, as the message is not coming from your own domain (it’s also why we strongly encourage other methods when you want to make it look like emails are coming from your customers directly). To make the process less confusing for recipients, we have a simple HTML page that explains “pm.mtasv.net”, showing that you, our customers, are serious about email delivery.

[Customer Stories] Carbonmade gives Postmark a big stamp of approval

alexknows — Fri, 24 Jun 2011 10:17:00 -0400

This is a guest post penned by Carbonmade co-founder Spencer Fry. Thanks Spencer!

At Carbonmade, an online portfolio service for artists, every conversation about picking a new service provider begins with “Who does it the best?” and “Are they people we want to work with?”

We ran our own internal transactional email system for the longest time, but growth and time constraints meant figuring out who could handle it better. After lots of research, chatting with industry friends, and repeatedly getting “Postmark” in response, we made the change.

Doing email right is a complicated business but Postmark just works. And it’s pretty! We’re a design first company and truly appreciate the sweet aesthetics in the graphs and such. Postmark is stupidly easy to use and completely rock-solid. No downtime whatsoever.

As far as features go, we dig the notifications of bounces and emails that get marked as spam. It allows us to reach out to folks through another channel or simply removing their email address from our mailings. It clears a bunch of headaches that would otherwise get in the way of the cool stuff we’re busy building on any given day.

Simply put - working with Postmark is a no-brainer and we recommend it highly.

Thanks Spencer! If your company uses Postmark, we’d love to hear how it makes your life better. Write to: alex@wildbit.com, I can’t wait to hear your story!

API Wrapper Roundup!

alexknows — Mon, 20 Jun 2011 12:34:24 -0400

In the last couple of weeks we’ve added a few new API wrappers to our developer docs!

We’ve now got over 30 languages/frameworks supported, and are adding more all the time.

Haskell - https://github.com/dbp/email-postmark
Symfony2 - https://github.com/miguel250/PostmarkBundle
Classic ASP - http://code.google.com/p/postmark-classic-asp/

Also, if you’ve ever used Zoho Creator for creating “mini-apps”, there’s now a way to use Postmark for sending Zoho Creator app emails very easily!

All of these plugins were contributed by a member of our API developer community. You can join and participate in our new developer email list to learn, contribute, and help make Postmark available for more developers around the world.

Don’t see the library you’re looking for?

We’re building a wishlist of Postmark plugins, libraries, and integrations. If you’ve got something you’d like to see, or would like to contribute, let us know!

Port25’s Authentication and Spam Assassin Tool

cnagele — Tue, 14 Jun 2011 15:41:00 -0400

When it comes to email authentication (SPF, DKIM, SenderID) it can be pretty confusing. We try our best to make the process easy, but we still get some support cases about setting up DNS records. As we have said before, using DKIM and SPF can go a long way with reputation and delivery. Most of our customers use DKIM and SPF in Postmark, which means we are helping people with delivery and helping the industry as a whole by supporting and adopting these standards.

When it comes to troubleshooting DKIM, SPF, DomainKeys and SenderID there are a number of tools out there. My favorite is Port25’s testing service. We’re huge fans of Port25. In addition to a great mail server, they also offer some of the best support I have ever had from a vendor. We’ve been using PowerMTA for about six years now, mainly due to their early stance and support of email authentication in their software.

So, back to the testing tool. There is a little known page on their site where they offer a special email address that you can send a test email to, which will then send back a report on your authentication results and SpamAssassin score. You can see the details on their site at http://www.port25.com/auth/. Here is how it works:

Send a test email to
check-auth-jsmith=yourdomain.com@verifier.port25.com where jsmith=yourdomain.com is the address where you want the report sent (jsmith@yourdomain.com).
Wait for the results to be sent to that address. That’s it!

What you get in return is something that looks like the report below. I sent this email from Postmark and received the report to my personal address. As you can see, there is a detailed report showing that all tests passed and SpamAssassin did not mark it as spam. You also get all sorts of nice information like the SPF and DKIM records it pulled and MX records. If you look at the SpamAssassin score you might notice that it is a negative result, which is fantastic. This is partly due to our listing with IADB (isipp.com).

So, if you ever need to do some geeky email testing, now you are armed with a nice tool. Big thanks to Port25 for making this available. Another nice tool for DNS lookups is mxtoolbox.com.

==========================================================
Summary of Results
==========================================================
SPF check:          pass
DomainKeys check:   pass
DKIM check:         pass
Sender-ID check:    pass
SpamAssassin check: ham

==========================================================
Details:
==========================================================

HELO hostname:  m1.mtasv.net
Source IP:      74.205.19.136
mail-from:      pm_bounces@pm.mtasv.net

----------------------------------------------------------
SPF check details:
----------------------------------------------------------
Result:         pass
ID(s) verified: smtp.mail=pm_bounces@pm.mtasv.net
DNS record(s):
   pm.mtasv.net. SPF (no records)
   pm.mtasv.net. 1800 IN TXT "v=spf1 include:spf.mtasv.net include:_spf.google.com ~all"
   spf.mtasv.net. SPF (no records)
   spf.mtasv.net. 3600 IN TXT "v=spf1 ip4:74.205.19.136/29 ip4:204.232.132.1 ip4:69.20.52.160/27 ~all"

----------------------------------------------------------
DomainKeys check details:
----------------------------------------------------------
Result:         pass
ID(s) verified: header.From=info@postmarkapp.com
DNS record(s):
   pm._domainkey.postmarkapp.com. 1800 IN TXT "k=rsa; p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKVO12rs2ofFYktu3zMjh50Ep28U1EbA7/AHVJO8FWG1ydUqF7eXmjbPyjYlZ9YNGIxuyTLaIv56+nssmoDnid2YA9AskDTloAqyPpapFdOyprT1xEcWdiO69SmmeHqbvwIDAQAB"

----------------------------------------------------------
DKIM check details:
----------------------------------------------------------
Result:         pass (matches From: info@postmarkapp.com)
ID(s) verified: header.i=info@postmarkapp.com
Canonicalized Headers:
   from:'0D''0A'
   to:"check-auth-cn=wildbit.com@verifier.port25.com"'20''0D''0A'
   date:Fri,'20'10'20'Jun'20'2011'20'12:52:23'20'-0400'0D''0A'
   subject:PowerMTA'20'Test'0D''0A'
   mime-version:1.0'0D''0A'
   content-type:text/plain;'20'charset=UTF-8'0D''0A'
   content-transfer-encoding:quoted-printable'0D''0A'
   message-id:<245236-MAIL693df81ac0de43ed915385fa7556ff8f@245236-mail>'0D''0A'
   dkim-signature:v=1;'20'a=rsa-sha1;'20'c=relaxed/relaxed;'20's=pm;'20'd=postmarkapp.com;'20'h=From:To:Date:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;'20'i=info@postmarkapp.com;'20'bh=TaDIeSHprfVsHOsSuywR607TILo=;'20'b=

Canonicalized Body:
   Hi,'20'this'20'is'20'a'20'test'20'email'20'from'20'Postmark=2E=0D=0A=0D=0AChris'0D''0A'


DNS record(s):
   pm._domainkey.postmarkapp.com. 1800 IN TXT "k=rsa; p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKVO12rs2ofFYktu3zMjh50Ep28U1EbA7/AHVJO8FWG1ydUqF7eXmjbPyjYlZ9YNGIxuyTLaIv56+nssmoDnid2YA9AskDTloAqyPpapFdOyprT1xEcWdiO69SmmeHqbvwIDAQAB"

NOTE: DKIM checking has been performed based on the latest DKIM specs
(RFC 4871 or draft-ietf-dkim-base-10) and verification may fail for
older versions.  If you are using Port25's PowerMTA, you need to use
version 3.2r11 or later to get a compatible version of DKIM.

----------------------------------------------------------
Sender-ID check details:
----------------------------------------------------------
Result:         pass
ID(s) verified: header.From=info@postmarkapp.com
DNS record(s):
   postmarkapp.com. SPF (no records)
   postmarkapp.com. 1800 IN TXT "v=spf1 a mx include:spf.mtasv.net include:_spf.google.com ~all"
   postmarkapp.com. 1800 IN A 173.230.141.181
   postmarkapp.com. 1800 IN MX 10 postmarkapp.com.s9a1.psmtp.com.
   postmarkapp.com. 1800 IN MX 20 postmarkapp.com.s9a2.psmtp.com.
   postmarkapp.com. 1800 IN MX 30 postmarkapp.com.s9b1.psmtp.com.
   postmarkapp.com. 1800 IN MX 40 postmarkapp.com.s9b2.psmtp.com.
   postmarkapp.com. 1800 IN MX 50 aspmx.l.google.com.
   postmarkapp.com.s9a1.psmtp.com. 14400 IN A 74.125.148.10
   postmarkapp.com.s9a2.psmtp.com. 14400 IN A 74.125.148.11
   postmarkapp.com.s9b1.psmtp.com. 14400 IN A 74.125.148.13
   postmarkapp.com.s9b2.psmtp.com. 14400 IN A 74.125.148.14
   aspmx.l.google.com. 14 IN A 74.125.113.27
   spf.mtasv.net. SPF (no records)
   spf.mtasv.net. 3600 IN TXT "v=spf1 ip4:74.205.19.136/29 ip4:204.232.132.1 ip4:69.20.52.160/27 ~all"

----------------------------------------------------------
SpamAssassin check details:
----------------------------------------------------------
SpamAssassin v3.2.5 (2008-06-10)

Result:         ham  (-2.7 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
-2.6 BAYES_00               BODY: Bayesian spam probability is 0 to 1%
                           [score: 0.0000]
-0.0 RCVD_IN_IADB_LISTED    RBL: Participates in the IADB system
                           [74.205.19.136 listed in iadb.isipp.com]
-0.1 RCVD_IN_IADB_SPF       RBL: IADB: Sender publishes SPF record
-0.0 RCVD_IN_IADB_SENDERID  RBL: IADB: Sender publishes Sender ID record

An update on email sending delays

cnagele — Mon, 06 Jun 2011 11:45:00 -0400

As you may have noticed, last week we ran into some issues on Postmark that caused email sending delays and even some API timeouts for people. It was a rough week. This weekend we did some maintenance on MongoDB, our primary data store, which we hoped would resolve some of the issues. This morning we experienced delays again and got it under control within about two hours. I want to give a status update and some background on what is going on.

First, some background

When we designed Postmark’s infrastructure the idea was that if all else fails, make sure we can at least recover and send the email. Of course we have redundancy on our servers, but we also wanted recovery mechanisms inside the application. For instance, if the DB fails and our API can’t save messages we have a redirect to store them temporarily on each local API instance. When the DB comes back, they are instantly recovered. Our thought is, as long as the API instance are accepting messages we can ensure nothing is lost. So far this has worked really well for us.

We use MongoDB for storing and archiving our email activity, such as send, in queue, bounces and spam messages that you view and search in Postmark’s web app. When we launched this feature, we approached it with the same logic: If all else fails, make sure the email is sent. When we launched the activity page it was more of an experiment for us. We wanted to see what we could track and how many messages could be stored as we grow. Since then, it’s become one of our most important features when it comes to tracking delivery issues and viewing the status of your emails. So when we have issues related to MongoDB, it’s noticeable.

We’ve been experiencing issues with MongoDB for months. We’ve also come to rely on it quite a bit for things like our bounce processing and internal statistics. When it works, it’s awesome, but when it doesn’t the sky is falling. Earlier this year we made the decision to try CouchDB, mainly for the replication features it offered compared to MongoDB. It looked very promising for our needs so we started to rewrite the MongoDB code to use CouchDB. It took a lot more time than we thought, but that’s not the worst part. When we have some of the core code in place for Couch, we needed to do some performance benchmarks. Compared to MongoDB it was pretty bad. There are a lot of technical reasons for this and tradeoffs to consider, but after a lot of testing we reverted back to MongoDB. Since then we’ve been full force on optimizing and upgrading MongoDB.

Jumping back to now

Let’s get back to last week and today. Essentially what happens is that when MongoDB is under higher load than normal, a large portion of our dataset starts hitting disk instead of indexes in RAM (currently 64GB). This causes huge iowait on the servers, which then slows down every query on Mongo. Since we rely on MongoDB to update things like in queue and sent status, it starts to get delayed. In addition, slower queries mean our processes that grab and send emails start to slow down as well. This caused some pretty severe delays in sending email from around 6am to 9am EST. While all of that was going on, and since we built things to accept failure, a lot of the activity pages might not have loaded or might have showed messages as in queue. So while the emails were sent, it skipped updating the record from “in queue” to “sent.” Again, we’d rather send the emails than wait for MongoDB to recover.

What are we doing about it?

Running a service that is an extension of your infrastructure is serious, and we treat it that way. We’ve been working our asses off to not only get things back to normal but to improve our datastore so we can grow into it. We don’t have time to mess around, so we’re working with 10gen, the developers of MongoDB, as well as upgrading some our infrastructure at Rackspace. By using tools like Server Density we’ve been able to spot some trends and understand where we can optimize. It will take a little more time to figure out the real bottlenecks and plan a better layout for our MongoDB servers. In the mean time we are going to migrate our replica sets to some better hardware, away from the slower I/O of EC2 and on to physical servers. At the moment everything has stabilized and we will continue monitoring it closely through the day.

Finally, I just want to say I am sorry. It’s been pretty stressful here and I know that the stress gets pushed down to our customers as well. Everyone has been great through this tough process and we really appreciate it. Please make sure to follow us on Twitter for the latest updates.