search for: message_detail_address_parse

quota-status.c: In function ?client_handle_request?: quota-status.c:98:10: warning: passing argument 4 of ?message_detail_address_parse? from incompatible pointer type [enabled by default] &detail); ^ In file included from quota-status.c:14:0: ../../../src/lib-mail/message-address.h:38:6: note: expected ?const char **? but argument is of type ?char *? void message_detail_address_parse(const char *delimiter_...

...mes ambiguous if the > local-part contains an @ (regardless of whether or not the first fix is applied > or not). I've worked around this by using strrchr() instead of strchr() on the > username string to split the domain out in mail_user_hash() > [src/lib-mail/mail-user-hash.c] and message_detail_address_parse() > [src/lib-mail/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_rf...

...re the username becomes ambiguous if the local-part contains an @ (regardless of whether or not the first fix is applied or not). I've worked around this by using strrchr() instead of strchr() on the username string to split the domain out in mail_user_hash() [src/lib-mail/mail-user-hash.c] and message_detail_address_parse() [src/lib-mail/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...

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