Should be fixed in CVS now.

Forgot to add one thing - after viewing and saving the blacklist, the 
empty string disappears. So I'm guessing it is not something that is 
happening on the blacklist editing page but rather something happens 
when the user blacklists a particular message ... perhaps one with an 
invalid/null "From" header? I have not been able to accurately test 
this scenario yet - most smtp servers do not allow empty From headers, 
and it seems our IMAP server adds one if it's missing anyway...

Hi there - not sure if this belongs in the IMP queue or the Ingo queue 
as I'm not sure where the source of the problem is.



We recently upgraded to IMP 4.0.3 / Ingo 1.0.1. We have 47 users (out 
of 17,000+) whose blacklist has an invisible "empty" string in it. 
This empty string matches any message and has the rather catastrophic 
effect of deleting everything in the user's inbox.



Most of the 47 cases appear to be the result of bad filter settings in 
our previous installation (IMP 3.2.3), which was converted using the 
script provided in ingo/scripts/convert_imp_filters.php. However - at 
least a few of the 47 were definitely created AFTER the upgrade, 
meaning that users are somehow generating this empty string in their 
blacklist.



The "empty" string I am referring to looks like this in the serialized 
data in our horde_prefs table (the 2nd line with index i:0):



   a:2:{s:1:"a";a:26:

    {i:0;s:0:"";

     i:1;s:14:"j21n@chello.nl";

     i:2;s:15:"k1thy@chello.nl";

     i:3;s:27:"creditcardservices@cibc.com";

    etc...



I am so far unable to reproduce the problem, except by editing the 
data via sql. I have not yet determined how the empty string is 
getting into their blacklist, but I thought I should open a ticket 
here to find out anyone else has experienced the problem.



We are using:

Horde 3.0.4, IMP H3 4.0.3 (final), Ingo H3 1.0.1, Turba H3 2.0.2

Cyrus IMAP4 v2.1.12

Postgres 7.3.6-RH

PHP 4.3.2