Blogroll: Postmark

I read blogs, as well as write one. The 'blogroll' on this site reproduces some posts from some of the people I enjoy reading. There are currently 4 posts from the blog 'Postmark.'

Disclaimer: Reproducing an article here need not necessarily imply agreement or endorsement!

Subscribe to Postmark feed
Updated: 3 hours 1 min ago

My file is not small, it’s fun-sized!

Wed, 13/02/2019 - 14:00

Your message file size matters. Some may think it’s great to send a ton of content in one fell swoop, but most ESPs limit the size of the message you can send through their service. That’s likely because they’re sending bulk messages, so they have to keep an eye on the processing power and time it takes to send a lot of very large messages at once.

Even though Postmark doesn’t have any specific requirements on message size, it’s still something we worry about—or, I guess, I worry about—because message size is directly related to email deliverability.

Generally speaking, most messages under 100KB see the same acceptance rates to all mailbox providers. Any larger, however, and we start spotting some alarming trends. I can specifically see at least Apple Mail, Outlook, Google Apps domains, and Yahoo routing these larger messages to spam. Maybe that's because they see too much spam trying to trick their filters with a ton of content? Or perhaps they don't consider the message worth their processing power to filter correctly? Or maybe they think it’s another one of those long emails from your Aunt Bess that you just “sigh” over and immediately delete? #sorrynotsorry

At any rate, if I spot a large message having delivery issues through Postmark, you might get an email from me with some recommendations. I promise it’ll be short! 😉

Categories: Technology

Feature announcement: more useful weekly account digests

Fri, 08/02/2019 - 19:57

We know from our open rates and follow-up questions that users rely heavily on the information in the email we send every Monday morning with statistics of selected servers. These weekly digest emails have always been useful, but we knew they could be better. So starting next week, you’ll see a new design and some additional information to help you manage your account better.

Here’s an overview of the changes and additions.

Outbound/Inbound Stat Summaries

Sends, bounces, and spam complaint totals will now be displayed side-by-side so it’s easier to get a quick overview of the health of your outbound activity. We color code the stats to help you visually identify problems, and we’ll also display an additional warning message if the server has a high spam rate.

Parsed and failed inbound totals now look similar to the outbound stats, and will also show a list of recent failures.

Bounces

The bounce section now features a color-coded bar which helps to visually identify which types of bounces are happening most frequently.

Deliverability Recommendations

We’re most excited about this one. The weekly digests now features a deliverability recommendations checklist. The goal of this section is to provide you with a simple, actionable list of tasks you can complete to improve the delivery of your emails.

This list differentiates between urgent actions like investigating a high bounce or spam rate, and best practices like setting up DKIM or Return-Path.

News & Updates

Finally, we will now display both recent blog posts and product updates at the bottom of the email. This will help to highlight those smaller improvements that we make to Postmark that don’t warrant a full blog post.

If you don’t currently receive weekly digests for your servers, head over to the profile section of your account, and turn them on! As always, we look forward to hearing your feedback.

Categories: Technology

Filtering changes at Gmail

Thu, 07/02/2019 - 14:00

In the past couple of weeks, we’ve seen multiple customers report that their messages to Gmail/GSuite recipients are suddenly delayed, ending up in the spam folder, or just missing entirely.

As I’ve been working with Google to understand the issue, yesterday they posted an update. It publicly confirms the widespread changes they've made to substantially increase spam blocking, which were rolled out at the end of January.

I've been personally tracking and testing these cases affected by the changes, and here’s what I know so far:

  • It affects senders indiscriminate of high or low volume/reputations.
  • There’s no identifiable trend in the messages' sending settings or content.
  • In many cases, we see the same delivery issues when testing in other ESPs.
So why aren't other ESPs talking about this?

First, Postmark is unique in that we have a pretty strict transactional-only message policy. We even have actual humans vetting each new account to ensure our sending reputation is top-notch. That means we're not used to seeing Gmail issues, so just a handful of these cases makes a pretty big blip on our radar. Second, Google is specifically targeting spoofing/phishing, so it makes sense transactional traffic would be hit the hardest with false-positives. Stuff like password-resets, invoices, etc. are more likely to be modeled for these kinds of attacks.

What can you do about it?

At the moment we just need to wait for Gmail to update their systems. As always, submitting examples of messages incorrectly routed to spam could help improve these filters faster and more effectively.

I'll also mention that a handful of Postmark customers had success getting back into the inbox by changing their authentication (sub)domains. We already know that domain reputation is a huge deliverability factor, so I think in these specific cases the reputation shift temporarily minimized the significance of other flags in the message, making it less susceptible right now to these new filters.

It's important to note this issue only seems to be affecting specific senders, not everyone nor every message. The best way to tell if your own messages are affected is to watch your Gmail engagement rates. Opens and clicks are directly tied to inbox placement, so noticeable shifts there could indicate an issue. If you'd like some assistance analyzing your traffic, give our Customer Success Team a shout. In the meantime, I’ll keep you updated here if anything else develops.

Categories: Technology

How to send and track the status of email using Python and the Postmark API

Mon, 04/02/2019 - 14:00

I've used the Postmark API in many projects, for both inbound and outbound email. Given the complexity of many cloud-based services these days, it's great to be able to hand off the email part to a dedicated provider.

Like many cloud developers, I have been creating several new apps using Python. The beauty of Python is in its visual simplicity and the many powerful libraries that abstract essential functions like JSON encoding and sending HTTP requests. Postmark's API allows us to send emails with very few lines of code, and it also allows us to track the status of those email operations. In this blog post, I'll be showing the steps to take to get that going.

Authentication

Postmark allows you to create one or more authorization tokens that can be associated with different apps. This is an approach that is easy to work with, and it allows you to revoke a token at any time if it will no longer be used or has been compromised. To create a token, select the server in your Postmark account, and under credentials, press the button 'Generate another token' to create tokens that you can use in your app. This token has to be added as a header in the REST request to the server (typically a GET or POST).

In Python it looks like this:

headers = { 'Content-Type': 'application/json', 'X-Postmark-Server-Token': 'b9654a7f-8ed5-4d13-af41-f77e95d3d055', 'Accept':'application/json'}

This Python dictionary contains any HTTP headers needed by the request, here specifying the token (as required by the Postmark API) and the content-type, which, as we'll see in a moment, tells Postmark how to interpret the data body we are about to send.

Building the request

To send an email via Postmark, we have to send a REST 'POST' with a body containing the details of the email request. At a minimum, we need to specify who the recipient is ('To') and to provide an email message body ('HtmlBody'), but of course it's also conventional to provide the sender email ('From') and an email 'Subject'. Again, when using Python, it's typical to use a dictionary:

parameters = {'From': 'martyn@postpush.info', 'To': 'recipient@postpush.info', 'Subject': 'Poem', 'HtmlBody': '<b>The boy stood on the burning deck</b>'}

Note that the 'From' field cannot just specify any random address that the Python program wants. In the Postmark console, each authorized sender address (or sender domain) needs to be set-up in the Postmark console under 'Sender Signatures'. In this way, Postmark can ensure that the platform cannot be subverted and used to generate spam emails.

Earlier, we specified the content-type as JSON. We need to make sure that this is how Python will send it, so we use the 'json' library to encode it:

import json data = json.dumps(parameters)

And now we are ready to send the data using the Python 'requests' library:

import requests r = requests.post('https://api.postmarkapp.com/email', headers=headers, data=data )

This sends a POST with our JSON body and the authentication key that we have set up. There is only one more thing to do, which is to get the response from the Postmark API (which is coded in JSON) and extract certain interesting information from there, notably the ErrorCode that tells us that the send to Postmark is successful, and the MessageID, which is the unique ID of that email in the Postmark system:

response = json.loads(r.text) if response['ErrorCode'] == 0: print('Message ID = %s' % response['MessageID']) else: print('Message not sent')

The MessageID is useful because we can use it to programmatically check what happened after we queued our message to be sent. We can also use this ID when looking at the Activity logs in the Postmark console, which is an excellent tool to help reconstruct 'what happened' for support purposes when something goes wrong on a live system.

Checking for status

So far, we have queued an email to be sent by Postmark, but of course, for an email, this is only the start. Once an email is sent, it may be rejected for security purposes, or because the email address is no longer active, or for other different reasons. Therefore, we need another API that reads back the status of a queued email, which we can do using the MessageID that we got when we first sent the message:

messageID = 'f5f69627-xxxx-xxxx-xxxx-xxxxxxxxxxx' r = requests.get('https://api.postmarkapp.com/messages/outbound/%s/details' % messageID, headers=headers)

Here, 'headers' will be the same as the earlier example, with the 'Accept' parameter ensuring that the answer that we get back from this GET will be in JSON so that we can easily handle it. We can then read the response back, convert from JSON back to dictionary format, which allows us to access interesting fields (like 'Status' and 'MessageEvents') efficiently.

response = json.loads(r.text) status = response['Status'] if status == 'Sent': for event in response['MessageEvents']: print(event['Type']) # 'Delivered', 'Bounced' print(event['ReceivedAt']) else: print('Status = %s' % status)

Assuming that the status is 'Sent', we can expect that in time that the email will either be successfully delivered or will bounce. Some receiving email servers make several attempts to get an email to a user, so it can be minutes or hours before Postmark can definitively report that an email has been rejected. Here, we're showing the way that you can poll the Postmark API for an updated status on a send. You can also setup Postmark with a 'webhook' to call a public URL in your system when the status changes, but that is a topic for another day.

In the example code above, we iterate over all the entries in MessageEvents (which is an array), and this allows us to see any historical events for our message until we see that the message has definitively either been delivered successfully or bounced. We also get a 'ReceivedAt' timestamp, which may be useful to write to a log or database in our app, so that in a live environment when we get a failure, we have both MessageID and timestamp that allows us to map events in our app to events in the Postmark logs. In my experience, this has proved to be very valuable in providing the level of confidence that customers want when they ask for an explanation of what happened with their application-generated emails.

Finally

I've posted the complete code on my Github page. Take it, experiment with it, and have fun with it.

Categories: Technology
Additional Terms