You might have been one of the “lucky” few that tried to pass a comma separated list of email in the To field of a Postmark message just to get back the “Multiple recipients not supported” error. Or maybe you are one of the guys that have been wondering “How come they don’t support Cc?” We have been reluctant to add that feature because of two reasons:
- It seemed to us it was not a typical usage scenario for transactional email, so it was a safe choice to delay implementing it.
- It was hard to implement. Apart from having to parse the almost free-form format of email addresses that mail servers accepted, we had to deal with finding out exactly which recipient triggered a bounce or a spam complaint.
We wanted to solve this problem anyway because the alternative for customers is pretty bad. To send an email to three recipients, you’d have to generate three Postmark messages. That means three HTTP requests to our service. I wouldn’t do that in a web request handler in my web app because it would degrade the user experience. The alternative is to queue a background job and process it asynchronously... which adds a lot of complexity to a seemingly simple task. That is why we just went ahead and added the feature. You can now pass multiple addresses in the To field and optionally include a Cc field with one or more additional recipients.
But What about Bounces?
Didn’t I just say it was hard to find out which recipient is invalid and triggers a bounce or represents a trigger-happy user that hates your guts and won’t think twice before clicking the “Report Spam” button? Yes, it is not only hard, but it sometimes is just impossible. The tricky part for us was to parse bounces that we get back and try to extract the original recipient from there. That is especially hard to do with spam feedback reports. Some ISP’s (looking at you, AOL!) explicitly redact every occurrence of the original recipient in their reports, and you can literally do nothing about it.
Our solution to that problem was to try and do our best in finding the original recipient. If we fail, we log a bounce or spam complaint with an empty email address. Pretty soon we’ll provide the UI to let you review the full text of the bounce, so that you have some idea what really happened and why. Of course single-recipient emails will use our proven mechanism of detecting the recipient, and in that case we should always be able to infer the bounced address.
I Am Using Client Library X – Does It Support the New Features
I think client libraries will not need any changes to support multiple To recipients. Your code should just work. As far as Cc is concerned, libraries will need to be changed, so that they add the Cc field to the JSON they send to our servers. Library authors, please consult the developer docs for details. We will update the Ruby gems shortly.
You support Cc, but not Bcc. How come?
Frankly we can’t think of a good use for Bcc in a web application. The only times people were trying to use it were when they wanted to have some sort of delivery tracking for their emails and we already offer that through our application. We are working on better bounces tracking and statistics, and to us the most logical way to implement that is to build it in Postmark instead of requiring customers to do Bcc hacks. Of course, we may be completely wrong here – in that case, please contact us.