[Dovecot] How do I use plus-addressing in Dovecot 1.1.x?
I'm using Postfix, Amavisd-new/SpamAssassin, and Dovecot. They all run
on the same server (running Linux). The mailboxes are stored on the
same server in maildir format.
The logical path for incoming messages (as I understand it) is:
- received by Postfix; handed off to Amavisd-new
- Amavisd-new checks to see whether or not it's spam/undesirable;
hands off to Dovecot deliver - Dovecot deliver delivers the message to the local mailbox
Under each of my user's mailbox is a submailbox called "spam". Just so
I don't confuse terminologies (I'm no IMAP/maildir expert), for
example, we have someone@domain.com. My configured mail_location is
"maildir:/srv/mail/%d/%n", so this person's mailbox is located here: /
srv/mail/domain.com/someone/ Within this directory is another
mailbox: /srv/mail/domain.com/someone/.spam/
The plan is to have Dovecot deliver send a message (which has been
labeled by Amavisd-new as spam) directly to the ".spam" submailbox,
instead of the INBOX (/srv/mail/domain.com/someone/). With Dovecot
1.0.x, I used "plus addressing". Amavisd-new was configured so that,
if a message was found to be spam, it delivered the message to Dovecot
deliver, but changed the delivery address. Now, instead of "someone@domain.com
", it was "someone+spam@domain.com". Dovecot deliver took this message
and delivered it correctly to the ".spam" submailbox (/srv/mail/
domain.com/someone/.spam/). Just to emphasize, this process does work
(using Dovecot 1.0.x).
With Dovecot 1.1.0, this process is broken. Now, spam messages are
delivered to the INBOX instead, and, when checking the dovecot-
deliver.log, I'm seeing "save failed to spam: Unknown namespace".
As best as I can tell, the answer seems to lie in "namespaces" as a
feature added in Dovecot 1.1.0. The problem is that I don't understand
how I could use them to resolve this situation. I've read the
documentation. I've looked at as many example configurations as I
could find.
Please help. I want to get this working again. I'm sure it's something
very straight-forward, but I don't understand. How must I change my
Dovecot 1.1.x configuration so that my "plus addressing" set up
(detailed above) will work again?
Or is there a better way?
Thanks so much for your help, and thanks for a great product!
- Jon
Can you post your conf files ? I could try it on one of my setups. I have no idea how to make + addressing tho >.<
Jon Fullmer wrote:
I'm using Postfix, Amavisd-new/SpamAssassin, and Dovecot. They all run on the same server (running Linux). The mailboxes are stored on the same server in maildir format.
The logical path for incoming messages (as I understand it) is:
- received by Postfix; handed off to Amavisd-new
- Amavisd-new checks to see whether or not it's spam/undesirable; hands off to Dovecot deliver
- Dovecot deliver delivers the message to the local mailbox
Under each of my user's mailbox is a submailbox called "spam". Just so I don't confuse terminologies (I'm no IMAP/maildir expert), for example, we have someone@domain.com. My configured mail_location is "maildir:/srv/mail/%d/%n", so this person's mailbox is located here: /srv/mail/domain.com/someone/ Within this directory is another mailbox: /srv/mail/domain.com/someone/.spam/
The plan is to have Dovecot deliver send a message (which has been labeled by Amavisd-new as spam) directly to the ".spam" submailbox, instead of the INBOX (/srv/mail/domain.com/someone/). With Dovecot 1.0.x, I used "plus addressing". Amavisd-new was configured so that, if a message was found to be spam, it delivered the message to Dovecot deliver, but changed the delivery address. Now, instead of "someone@domain.com", it was "someone+spam@domain.com". Dovecot deliver took this message and delivered it correctly to the ".spam" submailbox (/srv/mail/domain.com/someone/.spam/). Just to emphasize, this process does work (using Dovecot 1.0.x).
With Dovecot 1.1.0, this process is broken. Now, spam messages are delivered to the INBOX instead, and, when checking the dovecot-deliver.log, I'm seeing "save failed to spam: Unknown namespace".
As best as I can tell, the answer seems to lie in "namespaces" as a feature added in Dovecot 1.1.0. The problem is that I don't understand how I could use them to resolve this situation. I've read the documentation. I've looked at as many example configurations as I could find.
Please help. I want to get this working again. I'm sure it's something very straight-forward, but I don't understand. How must I change my Dovecot 1.1.x configuration so that my "plus addressing" set up (detailed above) will work again?
Or is there a better way?
Thanks so much for your help, and thanks for a great product!
- Jon
On 11/2/2008 3:33 PM, Jon Fullmer wrote:
How must I change my Dovecot 1.1.x configuration so that my "plus addressing" set up (detailed above) will work again?
So, maybe it would be a good idea to actually provide some config details? ;)
output of dovecot -n would a goo starting place...
--
Best regards,
Charles
I didn't want to inundate the list with too much data. Here's the
output of "dovecot -n". Because I'm paranoid, some parts are
obfuscated with capital Xs:
# 1.1.6: /etc/dovecot/dovecot.conf # OS: Linux 2.6.27.4 ppc ext3 protocols: imaps ssl_cert_file: XXXXXXXXXXXXXX ssl_key_file: XXXXXXXXXXXXXX disable_plaintext_auth: no login_dir: /usr/var/run/dovecot/login login_executable: /usr/lib/dovecot/imap-login mail_location: maildir:/srv/mail/%d/%n namespace: type: private separator: . prefix: INBOX. inbox: yes list: yes subscriptions: yes auth default: mechanisms: plain login user: XXXXXX passdb: driver: sql args: /etc/dovecot/dovecot-sql.conf userdb: driver: static args: uid=XXXXXX gid=XXXXX home=/srv/mail/%d/%n allow_all_users=yes socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: XXXXX group: XXXXXX master: path: /var/run/dovecot/auth-master mode: 384 user: XXXXX
Is there anything else that would be helpful?
- Jon
On Nov 3, 2008, at 5:48 AM, Charles Marcus wrote:
On 11/2/2008 3:33 PM, Jon Fullmer wrote:
How must I change my Dovecot 1.1.x configuration so that my "plus addressing" set up (detailed above) will work again?
So, maybe it would be a good idea to actually provide some config details? ;)
output of dovecot -n would a goo starting place...
--
Best regards,
Charles
Jon Fullmer wrote:
I'm using Postfix, Amavisd-new/SpamAssassin, and Dovecot. They all run on the same server (running Linux). The mailboxes are stored on the same server in maildir format.
The logical path for incoming messages (as I understand it) is:
- received by Postfix; handed off to Amavisd-new
- Amavisd-new checks to see whether or not it's spam/undesirable; hands off to Dovecot deliver
- Dovecot deliver delivers the message to the local mailbox
Under each of my user's mailbox is a submailbox called "spam". Just so I don't confuse terminologies (I'm no IMAP/maildir expert), for example, we have someone@domain.com. My configured mail_location is "maildir:/srv/mail/%d/%n", so this person's mailbox is located here:
/srv/mail/domain.com/someone/ Within this directory is another mailbox: /srv/mail/domain.com/someone/.spam/[snip]
Or is there a better way?
you can use something like this (in master.cf):
dovecot unix - n n - - pipe flags=DRhu user=_mailbox argv=/path/to/dovecot/deliver -d ${user}@${nexthop} -n -m ${extension}
(-n prevents dovecot from creating the folder if it doesn't exist. otherwise, strangers can create random folders in your mailbox!).
Alternatively, you can use sieve:
require "fileinto";
if header :contains "X-Spam-Flag" "YES" { fileinto "Junk"; stop; }
#if header :contains "X-Amavis-Alert" "BANNED" { # fileinto "Junk"; # stop; #}
#if header :contains "X-Spam-Status" "BOUNCE_MESSAGE" { # fileinto "Junk.Bounce"; # stop; #}
Thanks so much for your help, and thanks for a great product!
- Jon
This is the line from my master.cf:
dovecot unix - n n - - pipe flags=DRhu user=XXXXXX:XXXXXX argv=/usr/lib/dovecot/deliver -f $ {sender} -d ${user}@${nexthop} -n -m ${extension}
I'm not having a problem with a new mailbox being created (say,
"someone+spam"). It would seem that deliver isn't separating the
"someone+spam", or else is doing it in a way that is different from
the way it used to.
If I have to use sieve, I can I guess, but why was this feature
damaged? This did work in 1.0.15. I haven't changed the config with
the upgrade to 1.1.6.
- Jon
On Nov 4, 2008, at 2:46 AM, mouss wrote:
Jon Fullmer wrote:
I'm using Postfix, Amavisd-new/SpamAssassin, and Dovecot. They all
run on the same server (running Linux). The mailboxes are stored on
the same server in maildir format. The logical path for incoming messages (as I understand it) is:
- received by Postfix; handed off to Amavisd-new
- Amavisd-new checks to see whether or not it's spam/undesirable;
hands off to Dovecot deliver- Dovecot deliver delivers the message to the local mailbox Under each of my user's mailbox is a submailbox called "spam". Just
so I don't confuse terminologies (I'm no IMAP/maildir expert), for
example, we have someone@domain.com. My configured mail_location is
"maildir:/srv/mail/%d/%n", so this person's mailbox is located
here: /srv/mail/domain.com/someone/ Within this directory is
another mailbox: /srv/mail/domain.com/someone/.spam/ [snip] Or is there a better way?you can use something like this (in master.cf):
dovecot unix - n n - - pipe flags=DRhu user=_mailbox argv=/path/to/dovecot/deliver -d ${user}@${nexthop} -n -m ${extension}
(-n prevents dovecot from creating the folder if it doesn't exist.
otherwise, strangers can create random folders in your mailbox!).Alternatively, you can use sieve:
require "fileinto";
if header :contains "X-Spam-Flag" "YES" { fileinto "Junk"; stop; }
#if header :contains "X-Amavis-Alert" "BANNED" { # fileinto "Junk"; # stop; #}
#if header :contains "X-Spam-Status" "BOUNCE_MESSAGE" { # fileinto "Junk.Bounce"; # stop; #}
Thanks so much for your help, and thanks for a great product!
- Jon
On Sun, 2008-11-02 at 13:33 -0700, Jon Fullmer wrote:
As best as I can tell, the answer seems to lie in "namespaces" as a
feature added in Dovecot 1.1.0. The problem is that I don't understand
how I could use them to resolve this situation. I've read the
documentation. I've looked at as many example configurations as I
could find.
Instead of:
deliver -m ${extension}
Use:
deliver -m INBOX.${extension}
On 11/5/2008 7:11 AM, Timo Sirainen wrote:
On Sun, 2008-11-02 at 13:33 -0700, Jon Fullmer wrote:
As best as I can tell, the answer seems to lie in "namespaces" as a
feature added in Dovecot 1.1.0. The problem is that I don't understand
how I could use them to resolve this situation. I've read the
documentation. I've looked at as many example configurations as I
could find.
Instead of: deliver -m ${extension}
Use: deliver -m INBOX.${extension}
Hmm.. so what was the reason this changed from 1.0.x?
--
Best regards,
Charles
On Wed, 2008-11-05 at 08:05 -0500, Charles Marcus wrote:
On 11/5/2008 7:11 AM, Timo Sirainen wrote:
On Sun, 2008-11-02 at 13:33 -0700, Jon Fullmer wrote:
As best as I can tell, the answer seems to lie in "namespaces" as a
feature added in Dovecot 1.1.0. The problem is that I don't understand
how I could use them to resolve this situation. I've read the
documentation. I've looked at as many example configurations as I
could find.Instead of: deliver -m ${extension}
Use: deliver -m INBOX.${extension}
Hmm.. so what was the reason this changed from 1.0.x?
deliver v1.1 reads namespace configuration (so the mailbox names are now identical with deliver and IMAP) instead of ignoring it and only supporting one location for mails.
That did it! HOORAY! Thanks, Timo!
- Jon
On Nov 5, 2008, at 9:58 AM, Timo Sirainen wrote:
On Wed, 2008-11-05 at 08:05 -0500, Charles Marcus wrote:
On 11/5/2008 7:11 AM, Timo Sirainen wrote:
On Sun, 2008-11-02 at 13:33 -0700, Jon Fullmer wrote:
As best as I can tell, the answer seems to lie in "namespaces" as a feature added in Dovecot 1.1.0. The problem is that I don't
understand how I could use them to resolve this situation. I've read the documentation. I've looked at as many example configurations as I could find.Instead of: deliver -m ${extension}
Use: deliver -m INBOX.${extension}
Hmm.. so what was the reason this changed from 1.0.x?
deliver v1.1 reads namespace configuration (so the mailbox names are
now identical with deliver and IMAP) instead of ignoring it and only supporting one location for mails.
As best as I can tell, the answer seems to lie in "namespaces" as a feature added in Dovecot 1.1.0. The problem is that I don't understand how I could use them to resolve this situation. I've read the documentation. I've looked at as many example configurations as I could find.
Instead of: deliver -m ${extension}
Use: deliver -m INBOX.${extension}
Hmm.. so what was the reason this changed from 1.0.x?
deliver v1.1 reads namespace configuration (so the mailbox names are now identical with deliver and IMAP) instead of ignoring it and only supporting one location for mails.
Oh, right... kindof obvious now that you pointed it out... ;)
--
Best regards,
Charles
participants (5)
-
Charles Marcus
-
Jon Fullmer
-
justin＠ma3x.net
-
mouss
-
Timo Sirainen