Hi
I'm finally getting round to taking up Aki's suggestion here to look into lua. The original requirement was to check the ip reputation giving an OK or KO before proceeding to the login. I'd be interested in any feedback on the dovecot.conf settings and lua script. Also I've encountered a strange caching issue.
https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/E5FLX3...
To do this I've added a new passdb before the existing sql passdb. I am assuming that I will need to reverse the defaults (in 2.3.21.1) for result_success and result_failure.
passdb { driver = lua args = file=/etc/dovecot/passdb.lua blocking=yes result_success = continue result_failure = return-fail }
This is my lua test script.
function auth_passdb_lookup(req) dovecot.i_info("login request from " .. req.remote_ip .. " user=" .. req.user) if (req.user == "user_to_deny@example.com") then dovecot.i_info("deny login") return dovecot.auth.PASSDB_RESULT_USER_UNKNOWN, "" end return dovecot.auth.PASSDB_RESULT_NEXT, "" end
I am trying to get this working with this very simple logic before developing the real logic. But basically I am considering two responses from the lua script, one which is OK (returning dovecot.auth.PASSDB_RESULT_NEXT) in which case the next passdb should be consulted for the real password lookup. The other case is a KO (returning dovecot.auth.PASSDB_RESULT_USER_UNKNOWN) where this should be taken as an immediate failure without proceeding to password lookup in the next passd.I have passdb caching disabled.
While testing the KO case which seems to be working, if I modify the script changing the user_to_deny@example.com so it no longer matches, the script still outputs "deny login". It's not a passdb caching issue since it is going through the "deny login" code despite the user not matching. Could it be that lua scripts are being cached by dovecot?
John