Vandelay import from zimbra using impersonation

Questions
1

Your question

In vandelay I need to authenticate using zimbra “impersonation”

I tested that I can impersonate in IMAP using the base64 string obtained with: python3 -c “import base64; print(base64.b64encode(b’[email protected]\x00admin\x00password’).decode())”

telnet imap.domain 143
A01 AUTHENTICATE PLAIN dXNlckBkb21haW4uY29tAGFkbWluAHBhc3N3b3Jk
A01 OK [CAPABILITY IMAP4rev1 …

How can I do such impersonation in vandelay? is it even possible?

What I’m trying to do is to migrate from zimbra, so vandelay connects via imap to zimbra, but for impersonation zimbra uses user@domain\x00admin@domain\x00admin_password syntax the \x00 is actually a null char, so can’t be used successfully in the --auth-basic parameter I tried all possible combinations, but it looks like vandelay stops processing the string when reaches the null char.
So i can’t import from zimbra in vandelay to export later to stalwart,
and I can’t force vandelay to use base64 encoded string instead the --auth-basic parameter… would be nice if i could do something like using a paremeter --auth-literal ‘dXNlckBkb21haW4uY29tAGFkbWluAHBhc3N3b3Jk’

Any suggestion other than not using impersonation but user@domain with its password?

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

Vandelay’s IMAP importer only supports two authentication modes, as documented: --auth-basic <USER> (SASL PLAIN/LOGIN with the password from --auth-password/VANDELAY_PASSWORD/prompt) or --auth-bearer with --auth-user (OAUTHBEARER/XOAUTH2). There is no flag for a separate authorization identity (authzid) or for passing a raw/base64 SASL PLAIN initial response, so the Zimbra-style user\x00admin\x00password impersonation string cannot be supplied through --auth-basic or any other documented flag.

In short: Zimbra-style master-user impersonation isn’t something Vandelay’s IMAP importer currently exposes a way to express. The only documented authentication paths are plain user+password (--auth-basic) or OAuth bearer (--auth-bearer/--auth-user), neither of which carries a separate authzid field.

Given that, your options are:

  • Authenticate per-mailbox with each user’s own IMAP credentials (--auth-basic <user>@domain --auth-password <their password>), running one vandelay import imap per account.
  • Check whether your Zimbra deployment can expose a dedicated “master” IMAP login name/password pair (distinct from the admin account) that maps directly to each user without requiring the null-separated authzid syntax; some Zimbra admin tooling can issue a per-user app-specific credential, which would work fine with --auth-basic.

Reference: IMAP | Stalwart

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

Vandelay is not following the RFC4616 section 2

As I can see in /src/imap/client.rs code line 195 only authcid is being used, but RFC specifies authzid exactly for the requested feature.

Im my opinion the function authenticate_plain should admit authzid too to allow impersonation

I think that this could be implemented as optional parameter --auth-superuser (or any other name for the parameter) to fill the authzid value in the function

4

Vandelay always sends an empty authzid, which RFC 4616 allows since the authzid is optional; what’s missing is an option to set one. A NUL byte can’t travel through a command-line argument or an environment variable, so putting one into --auth-basic or VANDELAY_PASSWORD won’t work either. Adding it is a small change: an authzid option passed into the PLAIN exchange, with the fallback to LOGIN turned off when it’s set, since LOGIN has nowhere to put one.

Zimbra admins usually handle this with temporary passwords. Save each user’s current hash with zmprov ga [email protected] userPassword, set a temporary password, run the migration, then restore the saved hash with zmprov ma [email protected] userPassword '<saved hash>'. I haven’t run that against Vandelay myself, so try it on one account first.

5

Thanks for your reply.

For my specific case I patched myself the src/imap/client.rs file
Is far away from ellegant, even I’d say it is aberrant but is functional for me. Never programmed in Rust before, I just modified slightly the function adding “admin” user to the payload, but i feel that right solution is adding a new parameter so that value can be defined by user in execution time, instead hardcoded in compilation time. But it works as proof of concept, i guess.

This is my patch:

$ diff -ruN client.rs client_patched.rs
--- client.rs   2026-10-02 22:41:14.225024862 +0000
+++ client_patched.rs   2026-10-02 23:31:10.094771872 +0000
@@ -193,10 +193,11 @@
     }

     pub fn authenticate_plain(&mut self, authcid: &str, password: &str) -> Result<(), ImapError> {
-        let mut payload = Vec::with_capacity(authcid.len() + password.len() + 3);
-        payload.push(0);
+        let mut payload = Vec::with_capacity(authcid.len() + password.len() + "admin".len() + 3);
         payload.extend_from_slice(authcid.as_bytes());
         payload.push(0);
+        payload.extend_from_slice(b"admin");
+        payload.push(0);
         payload.extend_from_slice(password.as_bytes());
         if self.has_capability("SASL-IR") {
             let cmd = command::authenticate_with_ir("PLAIN", &payload);

But I’d prefer an oficial generic solution instead this dirty custom tailored code for my specific use case.

Regards.

6

I’ll soon be in the same boat (migrate from Zimbra using vandelay), but can’t use this temp password trick because I delegate auth from Zimbra to my AD domain controllers (and this is a domain global setting, no per user). So being able to set a custom authzid would be the only sane option I think

7

Two migrations blocked on the same thing is enough reason to add it properly. It would be a run-time option that sets the authzid in the PLAIN exchange (with the LOGIN fallback disabled when it’s set), so nothing ends up hardcoded the way your patch has it. I’ll look at adding that. Your patch is fine for getting a one-off migration done meanwhile.

@dani, impersonation only needs the admin account to authenticate, so it should still work for you as long as that admin logs in against Zimbra’s own directory and not AD. For both of you: the authzid only exists in SASL, so this covers the IMAP and ManageSieve imports. Calendars and contacts go over HTTP Basic, where it doesn’t apply.