On 2022-09-22 16:24, Brendan Braybrook wrote:

...

I wonder if dovecot would consider this feature request. In post login scripting, given USER, IP, LOCAL_IP, and userdb lookup fields, are only available, I want to push additional variables from web mail to dovecot using ID commands yet I looked at the source in imap-login-cmd-id.c and script-login.c it seems to be possible while I'm not an expert in C and IMAP standards and not sure if its something would break the standards.

i think this can do what you need. this little bit of config:

# trusted networks that can use the extended ID data we use for auth now login_trusted_networks = 192.168.0.10 # retain these so we can log client names (when provided) imap_id_retain=yes

makes connections from 192.168.0.10 trusted so that the imap ID fields get passed around during the auth/userdb processes.

if you then use the new lua scripting for the userdb lookup (https://doc.dovecot.org/configuration_manual/authentication/lua_based_authen...), you can get the value of the imap client id via auth_request#client_id

here's a little snippet to get you started:

package.path = package.path .. ";/usr/share/lua/5.1/?.lua" package.cpath = package.cpath .. ";/usr/lib/x86_64-linux-gnu/lua/5.1/?.so" require 'lfs'

function auth_userdb_lookup(req) dovecot.i_info("dovecot-auth.lua: authdb client_id = [" .. req.client_id .. "]") ret = {} ret.client_id = req.client_id // ret.homedir = ...etc... // need the rest of the userdb lookup bits return dovecot.auth.USERDB_RESULT_OK, ret end

---

you'll want to update that to return everything you need from the userdb lookup, but the data returned by userdb should get pushed to your post_login script. you should see $CLIENT_ID as an env variable with the example code above.

also note: make sure your post login script explicitly calls bash and don't get burned by /bin/sh pointing at dash (as happened to me recently

• otherwise some environment variables might not show up with dash).

Thanks so much for this, very much appreciated.

Anyhow, for anyone looking for quicker and easier solution, I was able to overwrite x_connected_ip using id command thats returning the value of LOCAL_IP, since I wanted to block some client apps from using my IMAP server yet your reference to login trusted networks, doubted me if I've done things right. Probably I need to make sure restricted client apps cant just perform id command and overwrites LOCAL_IP and bypass the restriction likewise my webmail and I hope this is what trusted login networks is for, and as per doc, it seems to be like so.

On 2022-09-26 07:03, Aki Tuomi wrote:

...

On 22/09/2022 23:05 EEST hi@zakaria.website wrote:

On 2022-09-22 16:24, Brendan Braybrook wrote:

...

...

I wonder if dovecot would consider this feature request. In post login scripting, given USER, IP, LOCAL_IP, and userdb lookup fields, are only available, I want to push additional variables from web mail to dovecot using ID commands yet I looked at the source in imap-login-cmd-id.c and script-login.c it seems to be possible while I'm not an expert in C and IMAP standards and not sure if its something would break the standards.

i think this can do what you need. this little bit of config:

# trusted networks that can use the extended ID data we use for auth now login_trusted_networks = 192.168.0.10 # retain these so we can log client names (when provided) imap_id_retain=yes

makes connections from 192.168.0.10 trusted so that the imap ID fields get passed around during the auth/userdb processes.

if you then use the new lua scripting for the userdb lookup (https://doc.dovecot.org/configuration_manual/authentication/lua_based_authen...), you can get the value of the imap client id via auth_request#client_id

here's a little snippet to get you started:

package.path = package.path .. ";/usr/share/lua/5.1/?.lua" package.cpath = package.cpath .. ";/usr/lib/x86_64-linux-gnu/lua/5.1/?.so" require 'lfs'

function auth_userdb_lookup(req) dovecot.i_info("dovecot-auth.lua: authdb client_id = [" .. req.client_id .. "]") ret = {} ret.client_id = req.client_id // ret.homedir = ...etc... // need the rest of the userdb lookup bits return dovecot.auth.USERDB_RESULT_OK, ret end

---

you'll want to update that to return everything you need from the userdb lookup, but the data returned by userdb should get pushed to your post_login script. you should see $CLIENT_ID as an env variable with the example code above.

also note: make sure your post login script explicitly calls bash and don't get burned by /bin/sh pointing at dash (as happened to me recently

• otherwise some environment variables might not show up with dash).

Thanks so much for this, very much appreciated.

Anyhow, for anyone looking for quicker and easier solution, I was able to overwrite x_connected_ip using id command thats returning the value of LOCAL_IP, since I wanted to block some client apps from using my IMAP server yet your reference to login trusted networks, doubted me if I've done things right. Probably I need to make sure restricted client apps cant just perform id command and overwrites LOCAL_IP and bypass the restriction likewise my webmail and I hope this is what trusted login networks is for, and as per doc, it seems to be like so.

Hi!

You should use the login_trusted_networks to enable passing variables over ID command. You can then use the supported ways there to set original IP and such without needing to touch the source code.

Currently supported ID values are: x-originating-ip, x-originating-port, x-connected-ip, x-connected-port, x-proxy-ttl, x-session-id, x-session-ext-id, x-forward-<some_variable_name>.

Usage:

1 ID ("x-originating-ip" "1.2.3.4" "x-originating-port" "3133"...)

Aki

Thanks so much for clarifying this.

Zakaria.