Postmark introduces easy inbound email processing for all accounts • Hacker News Board

Re: Postmark introduces easy inbound email processing for all accounts

#51

Post by cypriss » Tue, Jan 17, 2012, 7:16 PM UTC

old-gregg wrote: post #50

buro9 wrote: post #16

Wouldn't it be great if there was a standard JSON representation of an email, and that multiple providers (SendGrid, AWS SES, MailJet, ElasticEmail, etc) all then provided such an interface. So not only could you choose (swap out very very quickly) your outbound provider, but also your inbound provider. After the thread the other day on outbound email, I ended up choosing MailJet who have been wonderful with the ques…

Everything you're asking for (and much more) is handled by Mailgun (full disclaimer - I work there): http://blog.mailgun.net/day/2011/11/07 Moreover, our incoming mail parsing doesn't stop at simple MIME parsing, we're dig deeper into the meaning of those characters and extract user signatures, quoted parts, etc. Moreover, we retry inbound POST, allow you to filter incoming traffic on the server and (very important)…

We use Mailgun at UserVoice.com for incoming mail.

Of particular help to us:

- All emails are converted to UTF-8

- There's always a 'plain' (text only) version of the email sent to us, even if the original email only included HTML.

- They offer a 'stripped-text' field, which lets us easily see the new part of an email thread.

- Pretty great support

Re: Postmark introduces easy inbound email processing for all accounts

#52

Post by old-gregg » Tue, Jan 17, 2012, 7:20 PM UTC

amix wrote: post #41

Lamson makes email processing easy - it is a very modern framework for writing email applications. I have used it for a while now (almost a year) and have not had huge problems. I have written about it here (including code samples): http://amix.dk/blog/post/19608

Lamson is a great project but it has a number of issues with handling international emails, try handling mails that have subjects in two different languages, or have To/Cc fields with non-ASCII names in them. Basically if you're using it you'll have to guard it with some additional code.

Re: Postmark introduces easy inbound email processing for all accounts

#53

Post by necro » Tue, Jan 17, 2012, 7:43 PM UTC

We use google for our domain email. In order to handle uploads via email on this same domain we simply create a new account and send emails to this account. You then can have a hook (imap push) in google imap to detect when an email is received per account/box and process is right away. Or you can just run a cron every minute the check if new emails have been received. We then fire a script that pulls the email via imap, and then processes the emails/images into json format for use.

This allows us to keep everything on google and we do not need move our MX somewhere else. Also we keep our "upload" email on the same domain.

Pretty simple solution with no additional costs.

Re: Postmark introduces easy inbound email processing for all accounts

#54

Post by alexknowshtml » Tue, Jan 17, 2012, 8:22 PM UTC

peterwwillis wrote: post #49

alexknowshtml wrote: post #18

Earlier quoted context omitted.

We actually include spamscore information in the parsed emails. http://developer.postmarkapp.com/developer-inbound-parse.htm... Also, if you use Gmail forwarding to foward emails into Postmark, you get the benefits of their spam filtering before it even hits our system. That said - we watch for spam-like activity across our entire system.

Assuming I could craft messages which did not look like spam (to your system), and I could do it really really fast, do you have any throttling options to allow your customer to prevent an excess of mail from adding up too quickly or an alert based on a threshold? (Maybe i'm overthinking it, but I like services that put me in control of how much money i'm spending instead of being at the mercy of botnets)

"Unusual" send activity is pretty easy to spot, especially if it's going to put our customer at risk in any way. We're extremely proactive about making sure that you're aware of anything that might be considered a "surprise" to your service or your wallet.

Re: Postmark introduces easy inbound email processing for all accounts

#55

Post by alexknowshtml » Tue, Jan 17, 2012, 8:26 PM UTC

thebigshane wrote: post #44

brador wrote: post #13

$1.50/1000 seems steep and could hurt should a spam attack occur...Someone needs to package charged outgoing, with free incoming. Kinda like the cell messaging systems they have in the UK... Remember, you can add value by combining valuable services. Sell one as a loss leader to bring in the users and the other is your revenue stream.

My first thought: How would this service handle 100k forged emails sent from china? The recurring payments is okay if you set maybe a daily max, example: charge me indefinitely but no more than a dollar a day. If my daily quota is hit then cut that email address off until the next day. Do they (or a similar provider) already offer a better solution? I didn't find anything in their docs but I might have overlooked it.

As I mention here: http://news.ycombinator.com/item?id=3476311

We use a combination of algorithms and humans to determine "unusual" activity (not just spam or forged emails) and act accordingly.

We're even proactive about finding customers who break into new send volume thresholds and offer them discounts. We'd much rather have high quality senders in our network for a LONG time than just keep the highest billing rate on autopilot.

Re: Postmark introduces easy inbound email processing for all accounts

#56

Post by alexknowshtml » Tue, Jan 17, 2012, 8:28 PM UTC

anderspetersson wrote: post #26

alexknowshtml wrote: post #2

We've got more in store for this feature set, but we're really excited about this as a start - we use it ourselves at beanstalkapp.com and I know that a number of people HN were using the beta. I'm happy to answer any questions, or field any ideas you might have.

Hey, finally it launched, will definitely come in handy. I found a bug in the docs: On http://developer.postmarkapp.com/developer-inbound-parse.htm... the link named 'API developer email list' links to 'file://localhost/Users/alexhillman/Sites/wildbit/postmark-design/docs/groups.google.com/group/postmark-api-developers/'

Good thing I don't keep docs in my pr0n folder. That would've been embarrassing.

Re: Postmark introduces easy inbound email processing for all accounts

#57

Post by jazzychad » Tue, Jan 17, 2012, 8:33 PM UTC

Some feedback: This is a nice addition to a mail-provider API service, but the way it works is way too complicated. All email I want to parse needs to be forwarded to my special postmark inbound email address? This might be nice for people that have their email setup through google apps (which kindly forwards on all headers, etc when an email is auto-forwarded with a filter), but for other mail systems they might not play so nice with forwarding headers, etc (I know this from running my own email servers for Notifo and dealing with incoming and outgoing email on my own).

With this solution I still have to setup an intermediate mail server solution to first receive the emails from users, and then forward it along. Can't you take that step away from me?

Other providers (mailgun, sendgrid, etc) let me do that and let users send emails directly to my inbound mailboxes (which are then POSTed to my endpoint).

Also, this excerpt from the documentation lowers my confidence that you know what you're doing:

"Rather than leaving this information in plaintext, we recommend using SHA1 or MD5 to encrypt the information after the + sign and include the encrypted value after the +. This will avoid unintentionally exposing any sensitive information."

Re: Postmark introduces easy inbound email processing for all accounts

#58

Post by alexknowshtml » Tue, Jan 17, 2012, 8:52 PM UTC

jazzychad wrote: post #57

Some feedback: This is a nice addition to a mail-provider API service, but the way it works is way too complicated. All email I want to parse needs to be forwarded to my special postmark inbound email address? This might be nice for people that have their email setup through google apps (which kindly forwards on all headers, etc when an email is auto-forwarded with a filter), but for other mail systems they might not…

Thanks for the feedback, Chad.

Regarding forwarding: that step is already being taken away - it's in beta for a number of our customers, and we'll be adjusting workflow then releasing to everyone.

There's lots of people who don't have access to their DNS records but still want a tool like this. We want this utility to be simple for more them, too!

As far as SHA1/MD5 encryption - we know better than to use weak encryption on any TRULY sensitive information. In the context of the walkthrough, we're talking about internal IDs and other things that you might want to be obvious to your customers, not things that pose a security risk to you or them. If you even thought about using something like that as part of a unique identifier in your email replies - I think there would be bigger problems at hand than choosing SHA1 or MD5 to obfuscate that information. :)

Re: Postmark introduces easy inbound email processing for all accounts

#59

Post by alexknowshtml » Tue, Jan 17, 2012, 8:54 PM UTC

jeremybell wrote: post #12

We've been using Postmark for quite a while now (maybe 2 years now?) and it's fantastic. We recently began using the inbound processing while it was in beta, and it too is fantastic. The API is great and it's absolutely painless to setup and begin using quickly...

Thanks for the kudos, Jeremy. If you can share where you're using the inbound API, I'd love to see it in action!

Re: Postmark introduces easy inbound email processing for all accounts

#60

Post by alexknowshtml » Tue, Jan 17, 2012, 8:54 PM UTC

bthomas wrote: post #33

I'd love an email API that you could forward an email thread to, which would be parsed into a set of linked emails with contacts attached. Email to JSON is great, but not when the body is the text of 20 forwarded emails. Seems like a gimme for a CRM app -- does anybody provide this?

This is a cool idea, we'll keep it in mind!