Use Case:
A client wants me to forward certain mail domains via an authenticated SMTP to get improved delivery of the mails via certain whitelisted IPs.
So I thought I create a separate port on the kumomta server and then use the received_via meta info to set the tenant. So this client is only using that tenant, which could mean I can configure alternate routing_domains for this tenant only. But the routing_domain config is never set using the queue.toml. I know you guys want full configs, btu I will try to debug this a bit more. But I also want to check if I am doing something conceptually wrong.
And to be honest. Using lua only in the init.lua I did make it work based on the received_via meta, but I figured that the helper setup should be able to do the same and it failed.
init.lua section for queue helper apply:
kumo.on('smtp_server_message_received', function(msg)
local my_received_via = msg:get_meta('received_via')
if my_received_via == "10.30.30.213:2634" then
msg:set_meta('tenant', 'trnsp')
end
queue_helper:apply(msg)
If I then try to set the routing_domain in the queue.toml it doesn’t work as the queue.lua shows me while debugging with print statements that the message has the default-tenant and not the trnsp tenant.
In the queue.toml I configured this. The trnsp tenant does have a working source pool using haproxy.
Weirdly enough if I set the tenant using the same lua code AFTER the
queue_helper:apply(msg) and NOT before, then the message actually seems to have the tenant setting when sending the mail.
The resolv_config print info:
resolve_config#011domain.com#011trnsp#011nil
But still in the queue.lua code I don’t see the ‘trnsp’ tenant at all if I use
I am trying to debug and see what is happening here. But I am fairly confused. My guess is for that since the meta data on tenant is maybe cached and still default-tenant it will not use the setting from the queue.toml correctly.
Am I missing something conceptually? I mean my setup works if I use the following code in init.lua and not only set the tenant meta but also the routing_domain.
if my_received_via == "10.30.30.213:2634" then
msg:set_meta('tenant', 'trnsp')
if mydomain == 'domain.com' then
msg:set_meta('routing_domain', 'smtp-relay.domain.com')
end
And mail is then send for domain.com via the smtp-relay.domain.com via the haproxy IP. So any suggestions for better debugging are welcome
There are users who combine the helper with a manual set_meta where they have a special use case not covered by the helper. As you discovered, you need to do your set_meta after the helper call or else the helper will overwrite your set_meta.
Hmm yeah, but then the routing_domain setting is not applied… that is the problem tbh. Adding the header does fix the issue.. but it doesn’t make sense that the set_meta tenant is not honored properly
I tried both ways… and the setting it after does work better, but it still does not make the mail to be send over the smtp auth where adding the header does. Doesn’t make sense to me at all. but I have a solution for the quick implementation, but I would rather manage this kind of stuff using the helper.
oh hmm that sounds a bit weird to me… I also could define in the init.lua that if I send with mydomain.com that it should be sending with the ‘mydomain’ tenant and then it doesn’t work with a set_meta… but it does work with add_header. Either way the latter is a working solution, but not how I expected it
I did re-read this document and I guess it might be good to state that when using the helper tenants and campaigns must be set using headers if you want to make direct use in the queue.toml files.
I was under the impression that if you set the tenant using set_meta that it would honor that in the queue_helper:apply(msg).
So what works is:
local my_received_via = msg:get_meta('received_via')
if my_received_via == "10.30.30.213:2634" then
msg:append_header('X-Tenant','trnsp')
end
queue_helper:apply(msg)
With that configured stuff for the tenant are executed as they should.
