Bug: lmtp proxy does not quote local parts with spaces

[David Zambonini]

On 26/10/2017 19:33, David Zambonini wrote:
> 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:
> 
> 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.

My apologies for not adding your address on my initial response, Alexander - not
sure if you noticed what I replied with or not.

Nope, this isn't going to happen. I'm not familiar with the dovecot internals
but lmtp uses just the address string in the form of "full address with quotes
stripped from local part but otherwise not decoded" and nothing else throughout,
which touches on quite a bit of code. It makes it indeterminate and not always
possible to reassemble the original, it's a bit of a trainwreck.

The sanest option to me seems to me to be to store a decoded local part and
domain in addition to the detail in mail_recipient, and keeping a now properly
rfc822 encoded address in sync with it. However, this would cause a deviation
from existing behaviour for the full original user (the quotes would be seen).

I'm between a rock and a hard place here - at the very least I'd like this bug
to be officially recognised.

-- 
David Zambonini