Hey gang. I have a use-case where I need to route messages via HTTP (like described here: https://docs.kumomta.com/userguide/policy/http/). My catch is the API requires ALL recipients (not 1 recipient / message). The “hacky” way I’m planning on accomplishing this is pushing all recipients into a Lua table (or redis), by connection, during the smtp_server_rcpt_to events and then pulling that data out on smtp_server_message_received. For the first smtp_server_message_received, the message will be routed to the HTTP API along with the array of recipients, and for each subsequentsmtp_server_message_received, the message will be routed to the null queue. I think that should work, albeit wonkily. Just wanted to see if that’s the least hacky approach or am I missing a more straightforward way of accomplishing this?
Yeah, Kumo converts multi-recipients into individual messages, so having them then send out as a batch will be a challenge.
You may want to look at Add batching support for log hooks · KumoCorp/kumomta@5e1ae20 · GitHub
Wez modified the log hook for batching support and you may be able to leverage some of that.
But I haven’t reviewed it enough to say for sure.
Hey Mike 
Nice - I’ll look into that. I figured my use-case is a departure from the way kumo is designed to work. Just trying to avoid having to use something like Haraka (which makes me want to throw up in my mouth) for this project. I bet I can make it work on Kumo 
With Lua, anything is possible. 
we don’t formally expose the recipient list, but you could accumulate it yourself by setting up an array metadata value in the connection metadata during smtp_server_rcpt_to - KumoMTA Docs using object: connectionmeta - KumoMTA Docs
you could then assign the null queue to every recipient but the first one of these, and you’d end up with a single message whose envelope is set to the first message and which has the full list of recipients in its metadata.
if you feed that into an http dispatcher, you can then build up an appropriate request using that metadata for your recipient list.
Thanks Wez. At first blush I got derailed by that approach since smtp_server_rcpt_to contains conn_meta data where I can enumerate recipients but the queues don’t seem to have access to conn_meta - only domain, tenant, campaign. But perhaps the conn object is accessible inside queue events?
the connection metadata is copied into the message metadata prior to calling smtp_server_message_received. You have access to the message in your function sender:send(message) implementation, which is where you’d construct your http request.
ah! great so I can access my recipients array in the message metadata once I’m in sender:send(). Well that seems like that’ll work pretty well then
Yep! Was able to make that work. That’s darn near a perfect way for my use case. Thanks!
