[Dovecot] plus addressing bug in dovecot 1.1.x?
I had recently upgraded from Dovecot 1.0.14 to 1.1.0, and then to
1.1.1. Ever since the upgrade to 1.1.0, I noticed that "plus
addressing" has failed. In case I'm using a foreign phrase, this is
the concept of sending an e-mail to "user+spam@domain.com", and having
dovecot (dovecot LDA, specifically), deliver this to the "spam"
submailbox to "user@domain.com". I've been using this successfully
since 1.0.3.
When I upgraded to 1.1.0, I noticed that e-mails were no longer being
delivered to the submailboxes as they had been (though they would
arrive in the central INBOX). I checked the "dovecot-deliver.log", and
I noticed that, ever since I had brought up 1.1.0, I would see:
save failed to spam: Unknown namespace
("spam" is the submailbox)
After the upgrade to 1.1.1, I still would see these messages (and
behavior). I have since installed 1.0.15. The plus addressing now
works again, as it had been.
With all of these "upgrades" and "downgrades", the config file has
remained exactly the same. There have been no other changes to any
components on the host system (i.e., new OS-es, new postfix, etc.).
Thoughts? Is this a known issue?
- Jon
On Sun, 2008-06-22 at 21:25 -0600, Jon Fullmer wrote:
When I upgraded to 1.1.0, I noticed that e-mails were no longer being
delivered to the submailboxes as they had been (though they would
arrive in the central INBOX). I checked the "dovecot-deliver.log", and
I noticed that, ever since I had brought up 1.1.0, I would see:save failed to spam: Unknown namespace
The difference is that nowadays deliver supports namespaces. How have you configured them? For example if you have INBOX/ prefix for all your private mailboxes, you'd have to save the mail to INBOX/spam, not spam.
Now, how to do this automatically? Well, the choices would be:
a) Remove the namespace prefix.
b) Call deliver with -m INBOX/$mailbox from your MTA. But this is probably tricky, because if there is no + in the address you'd get -m INBOX/. Although it still gets saved to INBOX, you'll get "invalid mailbox name" logged.
c) Perhaps there could be a new "default namespace prefix" setting that applies to -m parameter if it's specified. Or perhaps -m <namespace prefix> should silently just save the mail to INBOX. Hmm. Perhaps the latter.
Anyone else have any better ideas?
On Mon, 23 Jun 2008, Timo Sirainen wrote:
The difference is that nowadays deliver supports namespaces. How have you configured them? For example if you have INBOX/ prefix for all your private mailboxes, you'd have to save the mail to INBOX/spam, not spam.
That's funny. I had figured that deliver 1.1 didn't fully support namespaces since I couldn't get it to work. Silly me.
On our setup, postfix pipes to "deliver -d ${user}@${nexthop} -n -m ${extension}" and this works as expected so long as the mailbox is in the private namespace. If we try user+shared.test@domain, deliver logs "save failed to shared.test: Mailbox doesn't exist: test" and "saved mail to INBOX". Is there something that should be changed with the config below to get deliver to deliver to other namespaces?
Now, how to do this automatically?
As for the original question about 1.0 > 1.1 transition for configs with non-empty prefixes for their inbox namespaces: Why not have deliver prepend the prefix of the inbox namespace to the extension when the extension does not contain any separator characters?
This would preserve the old 1.0 behavior without changing anything when the namespace is specified as part of the extension.
Here's my dovecot -n output: # 1.1.1: /etc/dovecot/dovecot.conf protocols: imaps imap managesieve listen(default): 127.0.0.1:143 listen(imap): 127.0.0.1:143 listen(managesieve): 127.0.0.1:2000 ssl_listen(default): *:993 ssl_listen(imap): *:993 ssl_listen(managesieve): ssl_cert_file: /etc/ssl/dovecot/imapd.crt ssl_key_file: /etc/ssl/dovecot/imapd.key login_dir: /var/run/dovecot/login login_executable(default): /usr/libexec/dovecot/imap-login login_executable(imap): /usr/libexec/dovecot/imap-login login_executable(managesieve): /usr/libexec/dovecot/managesieve-login login_greeting_capability(default): yes login_greeting_capability(imap): yes login_greeting_capability(managesieve): no valid_chroot_dirs: /var/mail first_valid_uid: 206 last_valid_uid: 206 first_valid_gid: 206 last_valid_gid: 206 maildir_copy_preserve_filename: yes mail_executable(default): /usr/libexec/dovecot/imap mail_executable(imap): /usr/libexec/dovecot/imap mail_executable(managesieve): /usr/libexec/dovecot/managesieve mail_plugins(default): acl mail_plugins(imap): acl mail_plugins(managesieve): mail_plugin_dir(default): /usr/lib/dovecot/imap mail_plugin_dir(imap): /usr/lib/dovecot/imap mail_plugin_dir(managesieve): /usr/lib64/dovecot/managesieve imap_client_workarounds(default): outlook-idle imap_client_workarounds(imap): outlook-idle imap_client_workarounds(managesieve): sieve_storage(default): sieve_storage(imap): sieve_storage(managesieve): ~/sieve sieve(default): sieve(imap): sieve(managesieve): ~/.dovecot.sieve namespace: type: private separator: . location: maildir:~/Maildir inbox: yes list: yes subscriptions: yes namespace: type: public separator: . prefix: shared. location: maildir:/var/mail/shared list: yes auth lda: user: postmaster passdb: driver: ldap args: /etc/dovecot/lda-ldap.conf userdb: driver: static args: allow_all_users=yes user=%Lu uid=206 gid=206 home=/var/mail/%Lu sieve_dir=~/sieve socket: type: listen master: path: /var/run/dovecot/deliver-auth mode: 384 user: vmail group: vmail auth default: mechanisms: PLAIN LOGIN user: postmaster passdb: driver: ldap args: /etc/dovecot/default-ldap.conf userdb: driver: static args: user=%Lu uid=206 gid=206 home=/var/mail/%Lu socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix plugin: acl: vfile
On Tue, 2008-06-24 at 13:19 -0700, Andrew Roberts wrote:
On Mon, 23 Jun 2008, Timo Sirainen wrote:
The difference is that nowadays deliver supports namespaces. How have you configured them? For example if you have INBOX/ prefix for all your private mailboxes, you'd have to save the mail to INBOX/spam, not spam.
That's funny. I had figured that deliver 1.1 didn't fully support namespaces since I couldn't get it to work. Silly me.
On our setup, postfix pipes to "deliver -d ${user}@${nexthop} -n -m ${extension}" and this works as expected so long as the mailbox is in the private namespace. If we try user+shared.test@domain, deliver logs "save failed to shared.test: Mailbox doesn't exist: test" and "saved mail to INBOX". Is there something that should be changed with the config below to get deliver to deliver to other namespaces?
Set mail_debug=yes and see what it logs. Does it show that deliver reads all the namespaces correctly?
Now, how to do this automatically?
As for the original question about 1.0 > 1.1 transition for configs with non-empty prefixes for their inbox namespaces: Why not have deliver prepend the prefix of the inbox namespace to the extension when the extension does not contain any separator characters?
This would preserve the old 1.0 behavior without changing anything when the namespace is specified as part of the extension.
That's kind of a partial solution since it doesn't fix if there are subfolders. Also this kind of a behavior change feels like it could break things and cause all kinds of unwanted behavior..
On Tue, 2008-06-24 at 13:19 -0700, Andrew Roberts wrote:
On Mon, 23 Jun 2008, Timo Sirainen wrote:
The difference is that nowadays deliver supports namespaces. How have you configured them? For example if you have INBOX/ prefix for all your private mailboxes, you'd have to save the mail to INBOX/spam, not spam.
That's funny. I had figured that deliver 1.1 didn't fully support namespaces since I couldn't get it to work. Silly me.
On our setup, postfix pipes to "deliver -d ${user}@${nexthop} -n -m ${extension}" and this works as expected so long as the mailbox is in the private namespace. If we try user+shared.test@domain, deliver logs "save failed to shared.test: Mailbox doesn't exist: test" and "saved mail to INBOX". Is there something that should be changed with the config below to get deliver to deliver to other namespaces?
Bug, fixed: http://hg.dovecot.org/dovecot-1.1/rev/75736a4b7f45
I saw the release notes to Dovecot-1.1.2. Some of the fixes imply that
this plus addressing anomaly that I experienced with 1.1.0 (and 1.1.1)
might have been resolved with 1.1.2. Has it been?
- Jon
On Jun 22, 2008, at 9:45 PM, Tim Sirainen wrote:
The difference is that nowadays deliver supports namespaces. How have you configured them? For example if you have INBOX/ prefix for all your private mailboxes, you'd have to save the mail to INBOX/spam, not spam.
Now, how to do this automatically? Well, the choices would be:
a) Remove the namespace prefix.
b) Call deliver with -m INBOX/$mailbox from your MTA. But this is probably tricky, because if there is no + in the address you'd get -m INBOX/. Although it still gets saved to INBOX, you'll get "invalid mailbox name" logged.
c) Perhaps there could be a new "default namespace prefix" setting that applies to -m parameter if it's specified. Or perhaps -m <namespace prefix> should silently just save the mail to INBOX. Hmm. Perhaps the latter.
Anyone else have any better ideas?
On Jun 22, 2008, at 9:25 PM, Jon Fullmer wrote:
I had recently upgraded from Dovecot 1.0.14 to 1.1.0, and then to
1.1.1. Ever since the upgrade to 1.1.0, I noticed that "plus
addressing" has failed. In case I'm using a foreign phrase, this is
the concept of sending an e-mail to "user+spam@domain.com", and
having dovecot (dovecot LDA, specifically), deliver this to the
"spam" submailbox to "user@domain.com". I've been using this
successfully since 1.0.3.When I upgraded to 1.1.0, I noticed that e-mails were no longer
being delivered to the submailboxes as they had been (though they
would arrive in the central INBOX). I checked the "dovecot- deliver.log", and I noticed that, ever since I had brought up 1.1.0,
I would see:save failed to spam: Unknown namespace
("spam" is the submailbox)
After the upgrade to 1.1.1, I still would see these messages (and
behavior). I have since installed 1.0.15. The plus addressing now
works again, as it had been.With all of these "upgrades" and "downgrades", the config file has
remained exactly the same. There have been no other changes to any
components on the host system (i.e., new OS-es, new postfix, etc.).Thoughts? Is this a known issue?
- Jon
On Fri, 25 Jul 2008 16:01:34 -0600, Jon Fullmer <jon@jonfullmer.com> wrote:
I saw the release notes to Dovecot-1.1.2. Some of the fixes imply that this plus addressing anomaly that I experienced with 1.1.0 (and 1.1.1) might have been resolved with 1.1.2. Has it been?
Plus addressing and sieve delivery to namespaces with subscriptions=no are working perfectly for me now (thanks Timo).
On Jul 25, 2008, at 6:01 PM, Jon Fullmer wrote:
I saw the release notes to Dovecot-1.1.2. Some of the fixes imply
that this plus addressing anomaly that I experienced with 1.1.0 (and
1.1.1) might have been resolved with 1.1.2. Has it been?
v1.1.2 supports this:
b) Call deliver with -m INBOX/$mailbox from your MTA.
I don't know/remember if this solves your problem though.
participants (4)
-
amr＠noom.org
-
Andrew Roberts
-
Jon Fullmer
-
Timo Sirainen