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:<t...@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:<t...@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:<t...@testdomain.com>\r\n
RCPT TO:<deemzed.uk+Junk E-mail@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
