[ingo] Rules don't have mail prefix

[Shane Williams]

I searched through the lists and bug reports pretty extensively, and
the only solution I found was was basically to set the MAILDIR
variable in scriptparams (which is what I meant instead of DEFAULT in
my first option).  Really, though, this isn't an ideal solution, since
many users already have scripts that properly point to mail/whatever.

After some more thought, I wonder if it might be relatively easy to
add an option to ingo (or maybe it needs to be in imp) to ignore the
default namespace and use the specified namespace array instead.  Or,
as another option, allow a prefix option to be set at the rule level,
rather than at the procmail level so that all folder names get the
prefix.

Based on my experimenting, I'd say the former is the more elegant.  If
someone could point to where these changes would need to be made, I'd
be happy to work on a potential patch.

On Wed, 2 Dec 2009, Jan Schneider wrote:

> Zitat von Shane Williams <broot at ischool.utexas.edu>:
>
>> Running Horde 3.3.4, IMP 4.3.4, Ingo 1.2.2 and Dovecot 1.0.7
>> 
>> Other background:  Due to historical issues with mail folders (that,
>> no surprise, have to do with UW-IMAP), we've created several
>> namespaces in dovecot.  The default namespace, with no prefix, points
>> to "$HOME/mail".  Then there are additional hidden namespaces, one of
>> which, to provide backward compatibility in certain situations uses
>> the prefix "mail/" and also points to "$HOME/mail".  So, right now,
>> when IMP does it's NAMESPACE command, it gets back:
>> * NAMESPACE (("" "/")) NIL NIL
>> 
>> Problem description
>> Ingo is set to use the IMP folder api, which appears to work right.
>> That is, when I go to set up a new rule, and choose "Deliver to
>> folder..." as the "Do this:" action, up pops a list of target folders
>> (which live in $HOME/mail).
>> 
>> But then, when I select a folder (cron for instance), and save the
>> rule, the resulting procmail script shows the destination as only
>> "cron" when it ought to say "mail/cron".
>> 
>> Interestingly, if I specify a namespace in my IMP servers.php with:
>> 'namespace' => array('mail/')
>> when I go through ingo action to "Deliver to folder" the drop-down now
>> shows the list of folders from the default, and then, in the middle
>> where the "m"s are, there's a greyed out line that says "mail" and all
>> the folders listed again, but slightly indented.  If I chose the
>> indented "cron", ingo now points the procmail action toward
>> "mail/cron", as desired.
>> 
>> So I see two possible solutions, but I want to know if there's
>> something I might be missing.
>> 
>> Option 1:
>> the straightforward fix would seem to be something like the following
>> in my backends.php:
>> 'scriptparams' => array(
>>        // Use if you need to set up specific environment variables.
>>        'variables' => array(
>>            'DEFAULT' => '$HOME/mail'
>> 		      )
>> 	    )
>> This adds the "DEFAULT=$HOME/mail" line into procmail, but since many
>> people have rules that are older than our horde/imp upgrade which
>> introduced the IMP folderapi, they're rules still apearr with the mail
>> prefix on them.  So, unless you go back and re-save each rule
>> individually, you now have rules that will try to put things in 
>> $HOME/mail/mail/foldername.
>> 
>> Option 2:
>> Change our dovecot configuration so that the default, non-hidden
>> namespace has the "mail/" prefix, and make the namespace with no name
>> hidden instead.  I suspect this is most likely to fix the ingo rule
>> problems without causing other ingo rules to be broken, but I'm not
>> sure what it's going to do to IMP (or other mail clients for that
>> matter).
>> 
>> If there's a way to turn off the IMP folder api and specify a
>> namespace, maybe that would work?  I know it's not ideal, but if I
>> only have one non-hidden namespace, it doesn't seem like there's any
>> practical difference.
>> 
>> Other suggestions?
>
> I don't know the final outcome, but this has been discussed a few times in 
> both the mailing list and the bug tracker. And IIRC a solution has eventually 
> been found by fixing the Dovecot configuration. Please search the mailing 
> list archive and bug tracker.

I searched both for quite a while this morning, using a variety of
search terms, and came up with nothing

-- 
Shane Williams
Coordinator of Information Technology & System Administrator
School of Information, University of Texas at Austin
broot at ischool.utexas.edu - 512-471-9471