search for: str_append_maybe_escap

...ere localpart contains a quoted @: dovecot-2.2.33.2-reverse-domaincut.patch 2. Fully decode local part on receipt in LMTP, and re-encode when proxying. This fixes the issue where quoted local quotes are stripped on proxy, preventing successful proxying, and some director hashing problems (exposes str_append_maybe_escape in message-address.h, some logging is still inconsistent, though, but would require a major rework): dovecot-2.2.33.2-quoted-local-proxy.patch -- David Zambonini -------------- next part -------------- --- dovecot-2.2.33.2/src/lib-mail/message-address.c 2017-10-05 18:10:44.000000000 +0100 +++ d...

...il/message-address.c], although likely I've missed some place this change should be made. 3. The third problem is then re-encoding the username in the envelope recipient when proxying, which was not done at all. I've added a function lmtp_client_rfc822_escape_address(), which is similar to str_append_maybe_escape() to escape the address at protocol time in lmtp_client_send_rcpts() [src/lib-smtp/lmtp-client.c], although I suspect it should be done earlier, this is just a working proof. The other reason I don't believe this patch is production quality is that I have not examined any interaction between...

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

...gh likely I've missed some place this > change should be made. > > 3. The third problem is then re-encoding the username in the envelope recipient > when proxying, which was not done at all. I've added a function > lmtp_client_rfc822_escape_address(), which is similar to > str_append_maybe_escape() to escape the address at protocol time in > lmtp_client_send_rcpts() [src/lib-smtp/lmtp-client.c], although I suspect it > should be done earlier, this is just a working proof. > > The other reason I don't believe this patch is production quality is that I have > not examined...