dovecot - Oct 2017 - Bug: lmtp proxy does not quote local parts with spaces

There seems to be a bug with RFC822 processing in ltmp proxying that doesn't
quote local parts that, for example, contain spaces.

director config:

director_username_hash = %Ln
lmtp_proxy             = yes
recipient_delimiter    = +

protocol lmtp {
        auth_socket_path       = director-userdb
        auth_username_chars            auth_username_format   = %Ln
        passdb {
                driver                 = sql
                args                   = /etc/director/sql.d/lmtp.ext
                result_failure         = return-fail
                result_internalfail    = return-fail
        }
}

lmtp.ext:

password_query = SELECT 'y' AS proxy, NULL AS password, 'y' AS
nopassword FROM
users WHERE userName='%Ln'

from exim -> director LMTP network dump:

MAIL FROM:<test at testdomain.com>\r\n
RCPT TO:<"deemzed.uk+Junk E-mail"@mailbox.localhost>\r\n
DATA\r\n
(etc)
.\r\n

501 5.5.4 Invalid parameters\r\n

QUIT\r\n

from director -> dovecot LMTP network dump:

MAIL FROM:<test at testdomain.com>\r\n
RCPT TO:<deemzed.uk+Junk E-mail>\r\n

501 5.5.4 Invalid.parameters\r\n

I'll try to pare down a full config for doveconf that displays this
behaviour if
required, as currently I have sensitive/extraneous information in there, but
this seems fairly cut and dried as a bug to me.

-- 
Dave

Am 26.10.2017 um 12:20 schrieb David Zambonini:
> 
> There seems to be a bug with RFC822 processing in ltmp proxying that
doesn't
> quote local parts that, for example, contain spaces.
Newer related RFCs are RFC 5321 and 5322.

[ ... ]
> MAIL FROM:<test at testdomain.com>\r\n
> RCPT TO:<deemzed.uk+Junk E-mail>\r\n
> 
> 501 5.5.4 Invalid.parameters\r\n
That recipient address is totally invalid. It is neither just a local 
part without a domain, nor a plussed address destination.

Check your setup with i.e.

RCPT TO:<"Junk E-mail"@deemzed.uk>

or

RCPT TO:<"test+Junk E-mail"@deemzed.uk>

Alexander

On 26/10/2017 18:38, Alexander Dalloz wrote:
> Am 26.10.2017 um 12:20 schrieb David Zambonini:
>>
>> There seems to be a bug with RFC822 processing in ltmp proxying that
>> doesn't
>> quote local parts that, for example, contain spaces.
> 
> Newer related RFCs are RFC 5321 and 5322.
Typo, meant to say RFC2822, which they still supercede, not that the
local-part spec has changed. :)
> 
> [ ... ]
> 
>> MAIL FROM:<test at testdomain.com>\r\n
>> RCPT TO:<deemzed.uk+Junk E-mail>\r\n
>>
>> 501 5.5.4 Invalid.parameters\r\n
> 
> That recipient address is totally invalid. It is neither just a local
> part without a domain, nor a plussed address destination.
> 
> Check your setup with i.e.
> 
> RCPT TO:<"Junk E-mail"@deemzed.uk>
> 
> or
> 
> RCPT TO:<"test+Junk E-mail"@deemzed.uk>
Apologies, I was attempting to cut the config down at the time the dump
was taken. Correcting (I can provide config privately, but not share to
list), I still get:

MAIL FROM:<test at testdomain.com>\r\n
RCPT TO:<"deemzed.uk+Junk E-mail"@mailbox.localhost>\r\n
DATA\r\n
(etc)
.\r\n

501 5.5.4 Invalid parameters\r\n

QUIT\r\n

from director -> dovecot LMTP network dump:

MAIL FROM:<test at testdomain.com>\r\n
RCPT TO:<deemzed.uk+Junk E-mail at mailbox.localhost>\r\n

501 5.5.4 Invalid.parameters\r\n

The problem is that dovecot is interpreting/unquoting the local part of
the address to insert into the username, but the client code in
client_proxy_rcpt()/address_add_detail() [lmtp/commands.c] then inserts
the username and detail directly into lmtp_rcpt.address with no attempt
whatsoever to requote that string regardless of what characters it
contains, leading to the situation where a straight-through proxy fails
as director is generating addresses that dovecot doesn't like. It can be
corrected manually using:

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

which kind of "fixes" the issue, which I had thought sufficient last
year for the limited range of inputs I have, but it turns out to break
director hashing as the username is then hashed containing quotes (not
to mention fun with recipient_delimiter).

Looking through RFC2822 any non-atext character in username, detail or
delimiter is enough for the local part to be converted to quoted-string.
Now I've traced it through in the source, I could have a look at
starting to get a fix together tomorrow with an aim to providing a pull
request, if it turns out there are no side-effects to treating
lmtp_rcpt.address like this and you'd like an example of what I mean.

-- 
David Zamboninini