dovecot - Jun 2016 - Recipient delimiter and lmtp proxying

Hi,

I'm attempting to proxy lmtp using director to hash to the same backend 
as pop3/imap. My pop3/imap users are of the form:

username

and my lmtp users are of the form:

<username at domain>

Where domain is fairly redundant but does carry some useful information.

Now, I can proxy lmtp using user=%{username} and
destuser=%{orig_user},  and this all appears to work correctly.

However, if I also try to pass a detail part through to the backend the 
lmtp users now take the form:

<username+detail at domain>

I can still use user=%{username}
with recipient_delimiter = +, and the detail is correctly stripped, 
hashing works as expected.

However, I can no longer use destuser=%{orig_user}

Because recipient_delimiter = +, destuser becomes:

<username at domain>

And the detail part never reaches the backend.

There doesn't appear to be any variables suitable for the destuser 
expansion - %{auth_user} is unsupported (UNSUPPORTED_VARIABLE_auth_user) 
on override_fields and in the sql passdb driver.

Is there any "correct" way to do this? I can think of a couple of 
approaches that may work, but both seem like hacks to me:

1. Unset recipient_delimiter and manually strip the detail from the 
username in the passdb lookup.

2. Give up on passing detail via the login and instead pass the detail 
via a message header to sieve.

Any thoughts/suggestions?

-- 
Dave

On 16/06/2016 20:49, Dave wrote:
>
> Hi,
>
> I'm attempting to proxy lmtp using director to hash to the same backend
> as pop3/imap. My pop3/imap users are of the form:
>
> username
>
> and my lmtp users are of the form:
>
> <username at domain>
>
> Where domain is fairly redundant but does carry some useful information.
>
> Now, I can proxy lmtp using user=%{username} and
> destuser=%{orig_user},  and this all appears to work correctly.
>
> However, if I also try to pass a detail part through to the backend the
> lmtp users now take the form:
>
> <username+detail at domain>
>
> I can still use user=%{username}
> with recipient_delimiter = +, and the detail is correctly stripped,
> hashing works as expected.
>
> However, I can no longer use destuser=%{orig_user}
>
> Because recipient_delimiter = +, destuser becomes:
>
> <username at domain>
>
> And the detail part never reaches the backend.
>
> There doesn't appear to be any variables suitable for the destuser
> expansion - %{auth_user} is unsupported (UNSUPPORTED_VARIABLE_auth_user)
> on override_fields and in the sql passdb driver.
>
> Is there any "correct" way to do this? I can think of a couple of
> approaches that may work, but both seem like hacks to me:
>
> 1. Unset recipient_delimiter and manually strip the detail from the
> username in the passdb lookup.
What I will say is that LMTP proxying doesn't quite work in all cases:

director:

recipient_delimiter 
protocol lmtp {
	auth_username_chars 	...
	passdb {
		driver          = sql
		override_fields = proxy=y destuser=%{orig_user}
		...
	}
}

...
driver         = mysql
password_query = SELECT username AS user, \
                             NULL AS password, \
                              'y' AS nopassword \
                  FROM users WHERE
username=SUBSTRING_INDEX('%u','+',1)
...

This sucessfully accepts '<user+detail at domain>' and passes
through to
the backend, but still experiences problems where the local part is quoted:

<"user+Junk\ Email"@domain>

will extract user in director, but passes through the unescaped:

<user+Junk Email at domain>

to the backend, which leads to a 501 5.5.4 Invalid parameter.

%{login_user} gives a blank string, %{auth_user} is unsupported.

I supposed that %{orig_user} was unaltered, but it appears to be 
interpreted by both unescaping quoted local parts and removing detail if 
recipient_delimiter is set. I'm not suggesting this behaviour is 
changed, obviously it makes sense.

So I guess the question is is there any way to pass the original pure, 
unaltered login string through lmtp proxy to the backend, or for lmtp 
proxy to correctly use a quoted local part with escapes if the destuser 
contains non dot-atom characters, as per RFC?

-- 
Dave

On 17/06/2016 13:39, Dave wrote:
> On 16/06/2016 20:49, Dave wrote:
...
>         driver          = sql
>         override_fields = proxy=y destuser=%{orig_user}
...
> <"user+Junk\ Email"@domain>
>
> will extract user in director, but passes through the unescaped:
>
> <user+Junk Email at domain>
>
> to the backend, which leads to a 501 5.5.4 Invalid parameter.
Just following up on my (one-man) thread, in case it is of future use to 
anyone:

Eventually, setting:

destuser="%{orig_username}"@%{orig_domain}

worked around the issue mentioned above, allowing both 
recipient-delimiter'ed usernames and quoted local to be passed front to 
back without issue.

-- 
Dve