dovecot - Nov 2008 - 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:

1) received by Postfix; handed off to Amavisd-new
2) Amavisd-new checks to see whether or not it's spam/undesirable;  
hands off to Dovecot deliver
3) 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 at 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 at
domain.com
", it was "someone+spam at 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:
>
> 1) received by Postfix; handed off to Amavisd-new
> 2) Amavisd-new checks to see whether or not it's spam/undesirable;
> hands off to Dovecot deliver
> 3) 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 at 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 at domain.com", it was "someone+spam at
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

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:
> 
> 1) received by Postfix; handed off to Amavisd-new
> 2) Amavisd-new checks to see whether or not it's spam/undesirable;
hands
> off to Dovecot deliver
> 3) 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 at 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}

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20081105/f7e43868/attachment-0002.bin>

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