Weekly product update: Better handling of non-ASCII characters in routes
Routes are one of our most popular features because it allows you to handle all those replies to your marketing and transactional emails.
This week, we’ve rolled out an enhancement, ok, we’ve fixed a bug, in our email parsing API, which is part of our incoming email handling system called Routes. Routes are one of our most popular features because it allows you to handle all those replies to your marketing and transactional emails. Some customers also use this incoming email handling feature to do cool things like let their customers use email to create tasks in a project management app or take part in an online discussion board via email.
Which leads us to better support for non-ASCII characters
When a user asks Mailgun to parse their incoming emails and POST to their app via HTTP, we parse quotations, signatures, and attachments and then post them to a webhook. If a message doesn’t have an HTML part (e.g. it was sent as plain text only) we still try to build an html part from the provided text part and post it as a stripped-html parameter (we also create the stripped-text part when an HTML-only email is received).
Recently a bug was found for this particular use case if the text part included non-ASCII characters. When this happened, they were corrupted in the stripped-html, so for example, “日本語” was transformed into “æ—¥æœ¬èª ž”. Now the bug is fixed and Mailgun properly creates proper html from text, even with non-ASCII characters.
Tell me more about Routes
This seems like a good a time as any to go over what Routes enable because they are really powerful. Routes allow you to set up a series of rules on how to handle incoming messages. Specifically:
Which messages to act on (e.g. messages from a particular person or with a particular subject or even all messages)
What you want to do with those messages (e.g. forward it to another email address or POST it to your app)
When you elect to post the message to your app, Mailgun will either send you the entire unparsed MIME message (if that’s your thing) or parse it for you and POST the parsed parameters. In both cases, we’ll transcode the message to UTF-8 because we love our customers.
Below is a list of the parsed parameters that we will POST to your app when using Routes.
Accepting incoming webhooks
You’ll need to set up your app to receive the parsed parameters. Here is a little flask app that shows you the basics so if you aren’t already, you can start using Routes to handle incoming messages!
And finally our new blog…
If you’re a long time Mailgun reader, you’ll notice that we have a new blog. Some of the new things we think you’ll like are:
It’s responsive so you can read it easily on any device
You can subscribe now to get updates when a new blog is posted (and absolutely no other emails you don’t want)
Each post has related docs so if you read a post about a customer using Mailgun Routes to do something cool, you’ll be able to find the docs most closely related to that topic directly from the post.
We hope you like the new blog. Let us know what you think.
Build Laravel 10 email authentication with Mailgun and Digital Ocean
When it was first released, Laravel version 5.7 added a new capability to verify user’s emails. If you’ve ever run php artisan make:auth within a Laravel app you’ll know the...
Here’s everything you need to know about DNS blocklists
The word “blocklist” can almost seem like something out of a movie – a little dramatic, silly, and a little unreal. Unfortunately, in the real world, blocklists are definitely something you...