move HTTP server to haraka-httpd

[msimerson]

Back when I added the web server to Haraka there was a lot of conversation regarding regarding the implementation and its pros and cons.

@smfreegard was right about the potential security and performance aspects of having the web server running on the same event loop as the mail server. Nobody disagreed, it was just the only way for the watch plugin to collect a real time view of mail as it transited the server (it did so by "hooking the world").

There are a couple other plugins using the web server and at least one planned one (a config file editor) but years later, the watch plugin is still the primary user of the web server.

Since then, watch only barely requires integration with Haraka proper. I developed haraka-results and updated many plugins and Haraka itself to publish most of the data watch needed to Redis. Today watch listens only on the deny and queue_ok hooks. All other data is collected via Redis pub/sub. With a bit more work, those dependencies could be erased, permitting watch to function with only access to the same Redis instance as Haraka.

This Issue is to track the intention, potential issues, and progress of moving Haraka's HTTP server out of Haraka and into a separate module: haraka-httpd.

• Do you use Haraka's built-in web server?
• Would this change affect your use of it?

[lnedry]

I plan to use Watch.

[msimerson]

Watch will continue to work, it'll just be a separate Haraka module that runs under a separate node.js process.

[soncodi]

I use the built-in HTTP server to wrap Haraka with an API-based batch email queue (no SMTP). It listens for an email bundle and then queues emails directly with outbound.send_email(). Plugin approach works as long as I have access to internals for manually pushing emails into the send queue - while taking advantage of e.g. nodes=2 load balancing.

[msimerson]

Moved to wiki