dovecot - Sep 2022 - Custom post login scripting variables via ID command

> 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_authentication/#authentication-lua-based-authentication),
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).

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_authentication/#authentication-lua-based-authentication),
> 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.