Is there any plan to support managing require_authz users from a database or external source, instead of hardcoding them in queues.toml?
For example, being able to define auth users via init.lua using SQLite or calling an API would be a huge improvement — especially when managing a large number of users. Editing queues.toml manually or via bash scripts with regex feels a bit hacky and not ideal for scaling.
Has this kind of feature been considered before? Or is there already a workaround we might be missing?
Second: the helpers are just premade Lua scripts that users can edit or use as a jumping off point for their own implementation. There’s nothing stopping someone from writing their own Lua implementation where they check auth credentials while processing messages.
i see, i just don’t want to touch any module and lose any upcoming update for kumomta, i was trying to manage everything from init.lua and toml/json files
if tenant_config.require_authz then
local authz_id = msg:get_meta ‘authz_id’
if not authz_id then
kumo.reject(
500,
string.format("tenant '%s' requires SMTP AUTH", tenant)
)
end
-- First check if the user is in the explicit list
if utils.table_contains(tenant_config.require_authz, authz_id) then
-- User is explicitly authorized, allow
return
end
-- If not in explicit list, check SQLite database
local username = authz_id
local authorized = false
-- Connect to SQLite database
local sqlite = require 'sqlite'
local db_file = os.getenv("SQLITE_AUTH_DB") or '/opt/kumomta/etc/policy/users.db'
local db, err = sqlite.open(db_file)
if db then
-- Query to check if the user exists and is active
local user_check = db:execute('SELECT COUNT(*) FROM users WHERE username = ? AND active = 1', username)
if user_check and user_check[1] and tonumber(user_check[1]) > 0 then
authorized = true
end
db:close()
else
kumo.log_error("Failed to open SQLite database: " .. (err or "unknown error"))
end
-- Reject if not authorized
if not authorized then
kumo.reject(
500,
string.format(
"authz_id '%s' is not authorized to send as tenant '%s'",
authz_id,
tenant
)
)
end
end
The suggested path is using a well-established config management solution (chef, ansible, or some other gitops thing) to generate your queues.json file.
While you could pull from a database, you need to carefully consider what your strategy is if the datasource is unavailable, test and account for that circumstance.
I’ll also note that deploying sqlite files from automation can be fraught with complications: you cannot simply copy and replace those files, and making updates requires locking the sqlite database which can impact the service.
In the end, it is often very much simpler and more robust and reliable to generate queues.json as part of your established config/change management solution.