By using a custom SMTP server, you run the risk of inadvertently creating security holes or violating the SMTP protocol in some way. With so many great SMTP servers out there (Postfix, exim, sendmail...), that doesn't sound like a good option to me.
The easiest way I can think of to solve that issue is to use Postfix to relay inbound and outbound e-mail. Inbound e-mail can be configured to be piped to an application, and outbound e-mail can be configured to be delivered by Postfix, either directly or relayed through a different server.
This way, you can use, instead of a custom SMTP server, an application that is able to parse RFC822-compliant message files. This is better than doing exactly the same thing, but with the overhead of having to implement the SMTP protocol.
This approach probably won't scale well should you need to receive a high volume of messages - every message will fork+exec a new process. If that is a requirement, a good approach would be to keep a custom SMTP server to do that job, but let Postfix relay it the messages - you will then benefit from Postfix's architecture in front of your parser.
Assuming you follow the approach of piping the messages to an application, all you need to do in Postfix is to
Configure Postfix's
alias_maps
' parameter to look for such a map:alias_maps = hash:/etc/aliases, hash:/etc/postfix/app-aliases
Then, configure the map to pipe messages sent to each address into an application:
test: "|/usr/local/bin/your-app"
As usual, don't forget to
$ postalias app-aliases
.
This will make a message sent to test@yourdomain
be piped into /usr/local/bin/your-app
, which acts as an e-mail gateway to your application.