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
Postmark introduces easy inbound email processing for all accounts
41–50 of 65 posts
Re: Postmark introduces easy inbound email processing for all accounts
#42There are a subset of applications that imo could rely exclusively on email as the platform.
A few months ago I built such an app, a small side-project called betabrokers(email trade@betabrokers.com with subject:about to signup and learn more). The simplicity of the signup process for this type of app (simply sending an email) is a huge benefit.
Email-based apps especially make sense in a mobile context, which is somewhat ironic because the transactional nature of applications built on them would suggest that they are slower, therefore less likely to be used. In our case however, users keep coming back to it, probably because the email client is the single most used app on their phone, and receiving replies to your actions via email becomes addictive.
Re: Postmark introduces easy inbound email processing for all accounts
#43This is neat, but it's not too difficult to handle incoming mail yourself with postfix and a simple ruby/python script to process it. The learning curve is slightly steep due to postfix and some really bad suggestions, but the actual work is straight forward. 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 regexe…
You are correct, of course. Nothing stops you from doing this yourself. The basic functionality in SaaS is always easy to accomplish (hosting, email sending, dropbox, etc). Its the little things that get you and eventually drive you to the bottle.
Re: Postmark introduces easy inbound email processing for all accounts
#44$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.
Re: Postmark introduces easy inbound email processing for all accounts
#45Wouldn'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 is offered as either JSON strings or POST params: http://docs.sendgrid.com/documentation/api/event-api/
- Jacob
Re: Postmark introduces easy inbound email processing for all accounts
#46Parsing 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/
Lamson seems to be a solid framework, but after trying to use it for a project I dropped it. Two assumptions it makes didn't work for me.
First, it takes over port 25 as your default SMTP server. This is great in that it saves you from dealing with the messy world of aliases etc, but not great on a shared host that does other things with mail as well.
Second, the FSM routing, while convenient, was ultimately limiting. Lamson routes mail based on the state of the sender (for example, 'subscribed', 'new', etc). But this state storage is abstracted away -- so if you wanted to change an address's state outside of the email flow (for example via a web app) or append additional data to the state, you have to re-implement the model logic for the FSM. I wonder if this is the reason why librelist, Zed's mailing list server implemented in lamson, has no web interface for subscription or list creation.
Lamson doesn't help you with parsing email any more than Python's standard library does (which is pretty decent, if a little verbose), so if you can handle setting up routing/aliases of mail to your application and storing state yourself, it might not add much.
Re: Postmark introduces easy inbound email processing for all accounts
#47I can see how this would be helpful but it seems like the best way to do this would be with a POP/IMAP client in your code. But I'm guessing those libraries are probably not as user-friendly as one would hope?
Re: Postmark introduces easy inbound email processing for all accounts
#48Parsing 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…
At SendGrid, we offer watching a whole dedicated domain/subdomain. For instance, you set up the MX record for incoming.example.com to sendgrid.net, and we Parse everything and POST it to the URL of your choice.
Re: Postmark introduces easy inbound email processing for all accounts
#49Earlier quoted context omitted.
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/
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)
Re: Postmark introduces easy inbound email processing for all accounts
#50Wouldn'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're the only incoming mail API processor that generates proper bounces for 3rd party servers (spammers) trying to hammer you with non-existent addresses.