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

Re: Postmark introduces easy inbound email processing for all accounts

#61

Post by bengl » Tue, Jan 17, 2012, 9:03 PM UTC

orenmazor wrote: post #39

epicviking wrote: post #37

This got me thinking... Are there any startups that are doing something similar with physical mail? I can picture a large centralized mail room with a bunch of industrial sized scanners, mail gets opened, scanned, and uploaded. Customers could access pdfs of their daily mail through a Web interface and could search through archives. Through in some super OCR and I think you'd really have something...

You know, when I started working on Postmark I thought that would make a fantastic April Fools joke. then I discovered there really is a company that tries to do that. I can't remember the name though…

Earth Class Mail?

http://www.earthclassmail.com/

Re: Postmark introduces easy inbound email processing for all accounts

#62

Post by jazzychad » Tue, Jan 17, 2012, 9:16 PM UTC

alexknowshtml wrote: post #58

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 encryp…

Thank you for the reply!

Regarding the md5/sha1 stuff: The documentation as it stands is both wrong and misleading. MD5 and SHA1 are _hash_ functions (not _encryption_ functions), so while trying to suggest that people could encrypt information to put after the + sign is a good idea, you will utterly confuse newbies by giving examples of hash functions. Of course you could use a unique hash value after the +, but then you need a reverse hash lookup table in your app to correlate the hash and the internal app state/data you need (but that is a whole other beast and not nearly as simple as "just encrypt it in the to address, decrypt on receipt, et voilà!").

In the end it is confusing for beginners and outright wrong for people that know the difference.

Now for the constructive part of the criticism: Please change or improve that portion of the docs, since docs are arguably the second most valuable asset to an API-provider (right behind the service itself).

Re: Postmark introduces easy inbound email processing for all accounts

#63

Post by [deleted] » Tue, Jan 17, 2012, 9:43 PM UTC

jazzychad wrote: post #62

alexknowshtml wrote: post #58

Earlier quoted context omitted.

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 encryp…

Thank you for the reply! Regarding the md5/sha1 stuff: The documentation as it stands is both wrong and misleading. MD5 and SHA1 are _hash_ functions (not _encryption_ functions), so while trying to suggest that people could encrypt information to put after the + sign is a good idea, you will utterly confuse newbies by giving examples of hash functions. Of course you could use a unique hash value after the +, but the…

[deleted]

Re: Postmark introduces easy inbound email processing for all accounts

#64

Post by alexknowshtml » Tue, Jan 17, 2012, 9:43 PM UTC

jazzychad wrote: post #62

alexknowshtml wrote: post #58

Earlier quoted context omitted.

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 encryp…

Thank you for the reply! Regarding the md5/sha1 stuff: The documentation as it stands is both wrong and misleading. MD5 and SHA1 are _hash_ functions (not _encryption_ functions), so while trying to suggest that people could encrypt information to put after the + sign is a good idea, you will utterly confuse newbies by giving examples of hash functions. Of course you could use a unique hash value after the +, but the…

I 100% agree about the importance of clear and accurate docs, and we'll work on an improvement to this quickly. Thanks for your time and insight, Chad.

Re: Postmark introduces easy inbound email processing for all accounts

#65

Post by Omni5cience » Wed, Jan 18, 2012, 11:20 PM UTC

JacobSG wrote: post #45

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…

As a SendGrid Support Technician, I can tell you our Parse API retries for 72 hours, same as our outbound mail management. We use POST params, not JSON: http://docs.sendgrid.com/documentation/api/parse-api-2/ Our Parse API is complimentary, and doesn't use any credits. We also have POST pushing of live data such requests received, deliveries, bounces, clicks, and opens down to address/link/time-specific detail. This…

My only problem with your model is that it requires me to be already paying you a non-trivial amount of money (for a brand new app) to get started with your Inbound API.