feature request/idea: configurable additional hook callbacks (HTTP, websocket, redis pubsub, etc.)

[PAStheLoD]

Hello!

I hope it's okay that I'm not using the mailing list for pitching this idea. (I think lack of web archives would make linking this to others a bit problematic.)

So, basically, we'd like to implement mail delivery status notification on a web-based system. Of course all we can do is provide a rough good/bad metric based on the SMTP transaction, but that'd be more than enough in 99+% of the cases (typo in email address, mailbox full, or rejected because of whatever reason).

Naturally, implementing just that as a Haraka plugin seems quite doable, (using the delivered, deferred, bounce, deny hooks - though I'm not yet familiar with the source, so maybe I'm wrong), but I have a hunch that this is not a completely unique problem, so I dare to ask about this config-file based thing.

To make it a bit clearer, I'd like to do something like this:

event_callbacks.ini

[events]
remote_denied = http://inter.nal/emails/callbacks
any = redis:pubsub://10.0.0.99:6379/whate-ever-topic
any = ws://10.0.0.101:5000/email-stream

that'd mean a HTTP POST request, with a JSON payload describing the whatever reason the remote SMTP server denied the queueing of the mail, and push on any event to a Redis PubSub topic and a send to a websocket stream.

Of course it could be more directly tied to the registered hooks, but I'm simply not sufficiently familiar with them.

Any transport mechanism would need its own plugin, so there needs to be a way for them to register an URL/URI parser. (Or the configured event callbacks need an explicit tag, e.g. using the <transport>:<transport_specific_URI>.) It'd be best to check this on startup and fail loudly if something is missing.

There could be config settings for specifying what should happen if delivering these events fail. (E.g. abort the process, log, or just do nothing), preferably per-callback.

Thanks for considering this!

[baudehlo]

Why not just use the elasticsearch plugin and use kibana as your web interface?

On May 28, 2016, at 8:50 AM, Pas notifications@github.com wrote:

Hello!

I hope it's okay that I'm not using the mailing list for pitching this idea. (I think lack of web archives would make linking this to others a bit problematic.)

So, basically, we'd like to implement mail delivery status notification on a web-based system. Of course all we can do is provide a rough good/bad metric based on the SMTP transaction, but that'd be more than enough in 99+% of the cases (typo in email address, mailbox full, or rejected because of whatever reason).

Naturally, implementing just that as a Haraka plugin seems quite doable, (using the delivered, deferred, bounce, deny hooks - though I'm not yet familiar with the source, so maybe I'm wrong), but I have a hunch that this is not a completely unique problem, so I dare to ask about this config-file based thing.

To make it a bit clearer, I'd like to do something like this:

event_callbacks.ini

[events] remote_denied = http://inter.nal/emails/callbacks any = redis:pubsub://10.0.0.99:6379/whate-ever-topic any = ws://10.0.0.101:5000/email-stream that'd mean a HTTP POST request, with a JSON payload describing the whatever reason the remote SMTP server denied the queueing of the mail, and push on any event to a Redis PubSub topic and a send to a websocket stream.

Of course it could be more directly tied to the registered hooks, but I'm simply not sufficiently familiar with them.

Any transport mechanism would need its own plugin, so there needs to be a way for them to register an URL/URI parser. (Or the configured event callbacks need an explicit tag, e.g. using the :.) It'd be best to check this on startup and fail loudly if something is missing.

There could be config settings for specifying what should happen if delivering these events fail. (E.g. abort the process, log, or just do nothing), preferably per-callback.

Thanks for considering this!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[PAStheLoD]

We want to make something that's a tiny bit fancier, maybe even mark invalid addresses in a database, send a notification perhaps, and so on, you know :)

[msimerson]

Closing this.

Extending Haraka a bunch to do this in the manner you suggest is not something we're interested in.

What we've already done to approximate these results in Haraka is having plugins and hooks storing results in ResultStore. When results are saved, they are automatically published to Redis and then other plugins can in turn subscribe to that Redis feed. That's how the watch plugin works, by subscribing to the ResultStore for each connection and then publishing the results to WebSockets.