search for: mail_recipient

...ded" 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 recognise...

...le in this thread from 2011: http://www.dovecot.org/list/dovecot/2011-May/059009.html) I noticed (using LMTP) that Dovecot handles 'no space left on device' just like an 'over-quota', if I read this part of method "static int client_deliver(struct client *client, const struct mail_recipient *rcpt, struct mail *src_mail, struct mail_deliver_session *session)" "lmtp/commands.c" correctly: --- cut --- [...] else if (storage != NULL) { error = mail_storage_get_last_error(storage, &mail_error); if (mail_error == MAIL_ERROR_NOSPACE) {...

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

...gt; 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...

...e 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 > t...