Postmark introduces easy inbound email processing for all accounts
11–20 of 65 posts
Re: Postmark introduces easy inbound email processing for all accounts
#12Re: Postmark introduces easy inbound email processing for all accounts
#13Remember, 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.
Re: Postmark introduces easy inbound email processing for all accounts
#14Interestingly we just had to build this type of processing into one of our applications, and I would have much rather sent this through a simple API. Alex are there high volume discounts?
Our credits work for inbound and outbound and never expire.
* 500,000+ - $1/thousand ($500) * 1MM+ - $0.75/thousand ($750) * 2MM+ - $0.50/thousand ($1,000)
Sending even more? Email me - alex@wildbit.com and we can talk.
Re: Postmark introduces easy inbound email processing for all accounts
#15$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.
Re: Postmark introduces easy inbound email processing for all accounts
#16So 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 questions I had when I hit their new member ceiling within the first few hours.
The things that convinced me on MailJet were real-time outbound stats and meaningful data (recipient + subject), API of status notifications (who bounced), and the fact that they do campaign emails at a cost so low that MailChimp ruled themselves out (one of my email lists has over 23,000 members).
I need inbound handling (currently using /etc/aliases and piping), but would love all the reporting and info which centralisation from an external provider could deliver.
My only concern would be resilience. Email is really good at re-delivery when your end is down or something prevents delivery, would a HTTP REST interface offer the same level of re-try and timeouts to ensure it got through eventually. Would the provider queue for me?
Re: Postmark introduces easy inbound email processing for all accounts
#17Try EmailYak. It is simple and elegant http://www.emailyak.com/ It is my friend's but I'd still recommend it otherwise. See: http://docs.emailyak.com/quick-start-guide.html
Re: Postmark introduces easy inbound email processing for all accounts
#18$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.
You could always use Postmarks spam checker service to monitor emails and if you get say 2 or 3 from the same email address that flag up as spam block the email? http://spamcheck.postmarkapp.com/
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.
Re: Postmark introduces easy inbound email processing for all accounts
#19As an aside, I've begun to think that email is/should become a platform for app development. Some sites are already using incoming email for active user engagement (posterous, idonethis, etc)
I think it's a great avenue to fight app/user fatigue. Most people constantly check their email no matter what, but few are making it past the app download to regular usage. The assumptions of emails limitations should be rethought.
Re: Postmark introduces easy inbound email processing for all accounts
#20Wouldn'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 far as stats go, that's on our list as well.