Bug: lmtp proxy does not quote local parts with spaces

[David Zambonini]

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