Phew, that was a busy several weeks. We have been hard at work improving the way we handle bounces on Postmark. The newest additions to our service are support for tagging emails and disabling delivery to addresses that do not want your email.
Tagging
How many times have you wanted to tag your outgoing email and check if it gets delivered, or just get statistics about that category of emails? Would you reconsider your email delivery strategy if all your spam complaints get triggered for the “Mr. X wants to be your friend” invitation email that you send from your social networking site? Now you can see this right in the interface and optimize your email delivery. To start tagging emails, see the new property in the Postmark Developer Docs.
Automatically blocking delivery for certain bounces
We realized that most of the time people do not want to send email to a nonexistent mailbox just to have the target SMTP server bounce the message back. Imagine a bunch of emails hitting the same addresses every day and achieving nothing. It’s both a waste of bandwidth and Postmark credits. Not to mention that ISP’s don’t like that at all and at the extreme you can end up degrading reputation and delivery.
The above situation is not even the worst thing that can happen. Say a user doesn’t want to receive email from you, and clicks the “Report spam” button in his email client. If you fail to handle that, you will keep delivering email, effectively annoying him or her even more. That can have mild consequences like bad email karma resulting in maybe you getting more spam than usual, or, if you are particularly obnoxious at sending those emails, it could result in getting blocked by the ISP and Postmark.
To help with that we decided to start rejecting email that you try to deliver to an address which has previously bounced back. We will do this only for hard bounces since those are guaranteed to represent mailboxes or servers that do not exist, and for spam complaints – those always mean that the user does not want to hear from you. The algorithm is simple — whenever we receive a hard bounce or a spam complaint sent through a server you configured, we will deactivate the recipient address and will not let you deliver email to it. The cool part is that you will not waste credits on those messages either.
Important: Right now we are still allowing emails to be delivered. On Monday March 29th we will flip the switch and stop sending to bounced and spam emails.
But I insist on sending to that address!
Do not worry! The delivery issues interface will allow you to reactivate an email address that has generated a hard bounce, so that you can send email to it again. Spam complaints are different. We feel that nobody should have to put up with continuously getting email he or she feels is spam, so we will not allow you to reactivate an address that has been deactivated because of a spam complaint.
I have several applications. Will deactivating an address for one of them affect the others?
Inactive addresses are associated with a Postmark server. Your applications should follow the recommended practice of using a different server for every application, so that a spam complaint for your WWE fans social network does not hurt your other apps’ delivery.
How will you reject my email? Will I get an error?
Yes, the plan is to eventually get an error back at you. Since that email will not reach anybody, we think it is best that you get an early notification and do something about that. This might cause some problems with your existing code though. Imagine the following pseudocode:
actionA();
sendEmail();
actionB();
If sendEmail() throws an exception because you sent to an inactive email address, actionB() will never be executed. While I think this is not a typical situation (You are doing proper error checking when calling an external service over the network, right? Right?!), we still have to do the right thing and provide a grace period until people check their code. For the time being you will get a warning when you try to send to an inactive address, if you check the Message property of the JSON response. In a week or so, we’ll flip the switch that will start generating real errors.
As a conclusion, I’d like to say that I’m pretty excited about the new features. I hope they are useful for you and your apps. As usual, feedback is welcome.
9 Comments
Regarding spam complaints…what happens if someone reported the email as spam but then later on remembers “Oh wait, I DID sign up for that and I DO want to keep getting emails from example.com”!!!!
How would we re-enable that email address?
Josh — March 22, 2010, 4:14 pm
Hi Josh, for now you can ask us directly and we will figure out a solution. We don’t want to allow people to reactivate these from the start since it can be abused. We’d rather watch it and learn.
Chris Nagele — March 22, 2010, 5:03 pm
I echo Rosh’s question.
Perhaps the ability to choose a “send reactivation email” which sends an email to the user asking if they want to opt back in to the service?
Adrian — March 22, 2010, 5:07 pm
Ooops. For Rosh read Josh.
Adrian — March 22, 2010, 5:07 pm
CodeIgniter library version 2.1 (not master) has been updated to support tagging.
Also, can we get the tag data from bounces only? Or is there a way to see what percentages of each email go out?
Zack Kitzmiller — March 22, 2010, 5:35 pm
Thanks Zack! Tags will be added to the volume stats as well. Toward the end of the week we are opening up the bounce API, which will allow you to access bounce data. This way you can build in tools into your app to help people update or change their profile.
Chris Nagele — March 22, 2010, 9:52 pm
Adrian, that would make sense. We’ll discuss it.
Chris Nagele — March 22, 2010, 9:53 pm
Opening up the Bounce API!? Sounds like I’m going to have a busy weekend. Unless you wanna share early :p
Zack Kitzmiller — March 22, 2010, 11:51 pm
Chris — Agree with the premise that now one should have to put up with spam they don’t want, but Josh is right that there has to be a way to reactivate a spam complaint. There are definitely users that do this accidentally on occasion because they are confused about what the email is or because they accidentally hit the “report spam” button (I’ve done it in GMail before meaning to hit “Archive” — they are right next to each other!)
If the user has to do it themselves that is ok too — but there has to be a way to handle it.
Looking forward to the bounce API — this is a must have especially with bounces getting blocked at this point.
So far, as you know, we have been very pleased! :)
Bradley Batt — March 24, 2010, 11:52 am
Write a comment