4 ms·

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 forwar

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."

alexknowshtml 15y ago
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. :)
- jazzychad 15y ago
  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).
  - deleted 15y ago
    [deleted]
  - alexknowshtml 15y ago
    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.

alexknowshtml 15y ago

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. :)

jazzychad 15y ago
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).
- deleted 15y ago
  [deleted]
- alexknowshtml 15y ago
  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.