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@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@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@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@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:

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