dovecot - Apr 2020 - Bug maybe already resolved? Sieve rule does not accept special use folder names

It is a 'special use' folder, so it only appears to exist in mail 
clients. 

  # spam folders merging
  mailbox Junk {
    special_use = \Junk
    auto = create
  }
  mailbox Spam {
    special_use = \Junk
    auto = no
  }
  mailbox "Junk E-mail" {
    special_use = \Junk
    auto = no
  }


On 16/04/2020 23:19, Marc Roos wrote:
> I do not have the log file anymore from the home dir. It just 
> complains that the folder Spam does not exist.
>
>   dovecot: lmtp(xxxx): oG8YI6enmF7FIAAAI7dPvA: sieve: Execution of 
> script /xxxx/.dovecot.sieve failed, but implicit keep was successful 
> (user logfile /xxx/.dovecot.sieve.log may reveal additional details)
So, does that Spam mailbox exist? The mailbox configuration you posted 
tells me that it is at least not created automatically once accessed.

Regards,

Stephan.
>
> -----Original Message-----
> From: Stephan Bosch [mailto:stephan at rename-it.nl]
> Sent: 16 April 2020 23:12
> To: Marc Roos; dovecot
> Subject: Re: Bug maybe already resolved? Sieve rule does not accept 
> special use folder names
>
>
>
> On 16/04/2020 21:04, Marc Roos wrote:
>> Sieve rule fileinto Spam fails, while fileinto Junk succeeds
>>
>>
>>     mailbox Spam {
>>       special_use = \Junk
>>       auto = no
>>     }
>>
>> dovecot-pigeonhole-2.2.36-3.el7_7.1.x86_64
>> dovecot-2.2.36-3.el7_7.1.x86_64
>> CentOS Linux release 7.7.1908 (Core
> I can't tell without insight in the error message and your full 
> configuration (`dovecot -n`).
>
> Regards,
>
> Stephan
>
>

On 16/04/2020 23:38, Marc Roos wrote:
> It is a 'special use' folder, so it only appears to exist in mail
> clients.
>
>    # spam folders merging
>    mailbox Junk {
>      special_use = \Junk
>      auto = create
>    }
>    mailbox Spam {
>      special_use = \Junk
>      auto = no
>    }
>    mailbox "Junk E-mail" {
>      special_use = \Junk
>      auto = no
>    }
I think you misunderstand this feature. This does not create some magic 
mailbox that only exists virtually or some alias of the mailbox. 
Instead, it makes it possible to find the mailbox with a special use 
easily in a standard way.

In your configuration the three mailboxes are separate physical mailboxes.

If Spam doesn't exist, it doesn't exist until it is created explicitly.

Regards,

Stephan.
>
> On 16/04/2020 23:19, Marc Roos wrote:
>> I do not have the log file anymore from the home dir. It just
>> complains that the folder Spam does not exist.
>>
>>    dovecot: lmtp(xxxx): oG8YI6enmF7FIAAAI7dPvA: sieve: Execution of
>> script /xxxx/.dovecot.sieve failed, but implicit keep was successful
>> (user logfile /xxx/.dovecot.sieve.log may reveal additional details)
> So, does that Spam mailbox exist? The mailbox configuration you posted
> tells me that it is at least not created automatically once accessed.
>
> Regards,
>
> Stephan.
>
>> -----Original Message-----
>> From: Stephan Bosch [mailto:stephan at rename-it.nl]
>> Sent: 16 April 2020 23:12
>> To: Marc Roos; dovecot
>> Subject: Re: Bug maybe already resolved? Sieve rule does not accept
>> special use folder names
>>
>>
>>
>> On 16/04/2020 21:04, Marc Roos wrote:
>>> Sieve rule fileinto Spam fails, while fileinto Junk succeeds
>>>
>>>
>>>      mailbox Spam {
>>>        special_use = \Junk
>>>        auto = no
>>>      }
>>>
>>> dovecot-pigeonhole-2.2.36-3.el7_7.1.x86_64
>>> dovecot-2.2.36-3.el7_7.1.x86_64
>>> CentOS Linux release 7.7.1908 (Core
>> I can't tell without insight in the error message and your full
>> configuration (`dovecot -n`).
>>
>> Regards,
>>
>> Stephan
>>
>>
>
>

Hmmm, confusing, clients should then display the mailbox name redirected 
by the server. 

If a user in a front end just sees the 'Junk E-mail', that is the name 
he is going to be using in his mailbox rules. If he does not know that 
this is actually the Junk folder on the server, he will make an 
incorrect message rule. 

So I guess you have to correct this server side, before storing the 
sieve rule? Or is there something nice that magically does this for me?


On 16/04/2020 23:38, Marc Roos wrote:
> It is a 'special use' folder, so it only appears to exist in mail 
> clients.
>
>    # spam folders merging
>    mailbox Junk {
>      special_use = \Junk
>      auto = create
>    }
>    mailbox Spam {
>      special_use = \Junk
>      auto = no
>    }
>    mailbox "Junk E-mail" {
>      special_use = \Junk
>      auto = no
>    }
I think you misunderstand this feature. This does not create some magic 
mailbox that only exists virtually or some alias of the mailbox. 
Instead, it makes it possible to find the mailbox with a special use 
easily in a standard way.

In your configuration the three mailboxes are separate physical 
mailboxes.

If Spam doesn't exist, it doesn't exist until it is created explicitly.

Regards,

Stephan.
>
> On 16/04/2020 23:19, Marc Roos wrote:
>> I do not have the log file anymore from the home dir. It just 
>> complains that the folder Spam does not exist.
>>
>>    dovecot: lmtp(xxxx): oG8YI6enmF7FIAAAI7dPvA: sieve: Execution of 
>> script /xxxx/.dovecot.sieve failed, but implicit keep was successful 
>> (user logfile /xxx/.dovecot.sieve.log may reveal additional details)
> So, does that Spam mailbox exist? The mailbox configuration you posted 
> tells me that it is at least not created automatically once accessed.
>
> Regards,
>
> Stephan.
>
>> -----Original Message-----
>> From: Stephan Bosch [mailto:stephan at rename-it.nl]
>> Sent: 16 April 2020 23:12
>> To: Marc Roos; dovecot
>> Subject: Re: Bug maybe already resolved? Sieve rule does not accept 
>> special use folder names
>>
>>
>>
>> On 16/04/2020 21:04, Marc Roos wrote:
>>> Sieve rule fileinto Spam fails, while fileinto Junk succeeds
>>>
>>>
>>>      mailbox Spam {
>>>        special_use = \Junk
>>>        auto = no
>>>      }
>>>
>>> dovecot-pigeonhole-2.2.36-3.el7_7.1.x86_64
>>> dovecot-2.2.36-3.el7_7.1.x86_64
>>> CentOS Linux release 7.7.1908 (Core
>> I can't tell without insight in the error message and your full 
>> configuration (`dovecot -n`).
>>
>> Regards,
>>
>> Stephan
>>
>>
>
>