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