21–30 of 65 posts
I'm currently using Exchange to get real-time mail notifications and nice parsing, but am looking for other options.
Also, encoding attachements as base64 is an interesting choice. I'd prefer a URL where they can be downloaded instead.
I read though the docs and couldn't tell: is delivery reliable? If my app is down and I miss some POSTs, will I be able to tell? Will they be re-delivered? I'm currently using Exchange to get real-time mail notifications and nice parsing, but am looking for other options. Also, encoding attachements as base64 is an interesting choice. I'd prefer a URL where they can be downloaded instead.
We're working on the workflow for retries, it's coming soon.
Thanks for the feedback about the download URLs. Any particular reason for this preference that I can share with the team?
For a real world example, at my startup https://zapier.com/ we have "new email received" or "new email tagged in Gmail" as one of the many, many inputs which you can map to any other write (IE: Tweet something, add a note to Basecamp, add a contact to Highrise, etc...). However, this means I need to log into a IMAP account, not receive an email at a predetermined address. Parsing that raw email is an absolute bear (even with Python's built in IMAP and parse libraries).
Anyone heard of a service or library like that?
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…
I read though the docs and couldn't tell: is delivery reliable? If my app is down and I miss some POSTs, will I be able to tell? Will they be re-delivered? I'm currently using Exchange to get real-time mail notifications and nice parsing, but am looking for other options. Also, encoding attachements as base64 is an interesting choice. I'd prefer a URL where they can be downloaded instead.
Your activity feed will show that there was an HTTP error. We're working on the workflow for retries, it's coming soon. Thanks for the feedback about the download URLs. Any particular reason for this preference that I can share with the team?
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.
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/'
I setup a simple ruby program to pipe the postfix email into a resque queue (redis backed ruby jobs system) to be handled by my work pool...a couple easy regexes determine what the email is: bounces get auto-delisted after 2x, unsubscribes delist immediately, replies get shoved into the correct in-site comment thread or conversation, etc. This is a day of work....
Parsing email is a real pain point, kudos to Postmark for trying to solve it. However, I need this functionality in a more abstracted way, not locked to a email address. I'm thinking about taking a swing at it myself and GPL'ing it. (Basically full fledged IMAP->JSON.) For a real world example, at my startup https://zapier.com/ we have "new email received" or "new email tagged in Gmail" as one of the many, many input…
Earlier quoted context omitted.
Your activity feed will show that there was an HTTP error. We're working on the workflow for retries, it's coming soon. Thanks for the feedback about the download URLs. Any particular reason for this preference that I can share with the team?
Photos and other large content. Most web stacks don't nicely handle large requests like that, and to the best of my knowledge streaming JSON parsers are both young and rare.
Parsing email is a real pain point, kudos to Postmark for trying to solve it. However, I need this functionality in a more abstracted way, not locked to a email address. I'm thinking about taking a swing at it myself and GPL'ing it. (Basically full fledged IMAP->JSON.) For a real world example, at my startup https://zapier.com/ we have "new email received" or "new email tagged in Gmail" as one of the many, many input…
http://lamsonproject.org/