Sendgrid's Event API (http://docs.sendgrid.com/documentation/api/event-api/) does something similar to this. Their mail servers act as a gateway to allow your app server to both send and recieve email over HTTP. I've used it at work as part of a not-yet-released feature of our product.

Real men write their own email servers ... kidding ;P I think most people want the parse api. That is doing something when an email received. We were going to use that and the event api ourselves but I ended up writing my own custom email server with subethasmtp (in hindsight the lost opportunity cost was probably not worth it.)

If you want to be part of the e-mail pipeline, your application should use SMTP for both sending and recieving.

Use a spam service such as spamhero.com or google postini as the MX for your domain so you do not have to do spam filtering yourself, have the spam filter service deliver the mail to your application (over SMTP). Your app can do whatever processing it needs to do, and then deliver the mail to the MX server of the ISP you're using to host your mail.

This way you can use your app without any changes as a local smtp filter as well (e.g. if you're using something like amavis).

I'm not sure I agree. Integrating into an existing server, such as Exim/Postfix will give the security benefits with a much lower latency and lower bandwidth costs.

I wrote an email server to do this but I highly recommend instead of using a RESTful POST you consider using a message bus like RabbitMQ. That is what we do. We have our custom email server push it to a Rabbit queue and then our app picks it up. That way if you shutdown the app you won't loose any emails.