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:
<user+Junk Email@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
