It works, thanks.

Please try what I committed instead.

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/ingo/lib/Storage.php?r1=1.84&r2=1.85&ty=u

When running Imp and Ingo, Ingo does not store the spam preferences 
correctly. The problem is in the following code (lib/Storage/prefs.php):



case INGO_STORAGE_ACTION_SPAM:

              $ob = new Ingo_Storage_spam();

              $data = @unserialize($prefs->getValue('spam'));



Here, $prefs has previously been loaded to point to Ingo's 
preferences. However, within the constructor of Ingo_Storage_spam, the 
preference object is invalidated by changing the preference object's 
scope, as Imp's preferences are loaded:



         if (in_array('imp', $GLOBALS['registry']->listApps())) {

             $prefs = &Prefs::singleton($GLOBALS['conf']['prefs']['driver'],

                                        'imp', Ingo::getUser(), '', 
null, false);

             $prefs->retrieve();

             [...]



To solve this, I changed Ingo's code to read



          case INGO_STORAGE_ACTION_SPAM:

              $ob = new Ingo_Storage_spam();

              $prefs->retrieve($GLOBALS['registry']->getApp());

              $data = @unserialize($prefs->getValue('spam'));



So the preferences are reloaded after the construction call. 
Alternatively, only resetting the scope should also be sufficient. 
This solves the problem, but I admit it may not be the most preferable 
solution. I think that Prefs::singleton() should allow to cache 
preference objects with different scopes separately, which is 
currently disallowed (horde/lib/Horde/Prefs.php):



         if (!isset($instances[$signature])) {

             $instances[$signature] = &Prefs::factory($driver, $scope, 
$user, $password, $params, $caching);

         }



         /* Preferences may be cached with a different scope. */

         $instances[$signature]->setScope($scope);



If you want, I'll submit that as a separate Horde framework bug.