[imp] Large Search on mailbox causes logout

[felix at compsoc.nuigalway.ie]

Hi,


Noticed a problem before when running large searchs on mail boxes using imp. On
a website that I help run and build we integrated horde 2.2.5 & imp 3.2.5 into
the website so that only 1 login from the site was needed and it would log you
into horde & imp as well.

However for some users if they run large searchs across their mail boxes imp
destroys its session and logs them out. Naturally we have a few additionally
problems since it doesn't destroy the main site session, but thats a separate
issue.

I've been able to replicate this issue for a good deal of time, I have 80
folders and to break imp all I have to do is:
go to the search page
select all folders to search (80)
insert "break imp" to search in the body of each mail.

Search returns no results and then when I click on the inbox next it exits imp
and horde and brings me to the imp login screen. Repeated attempts to login
again fail.


Now I've gone through the code and done some hacking to try and trace whats
messing up and I've found out the following.

in horde/imp/templates/common-footer.inc I added a few lines to dump out the
current session to the screen

echo "<pre>";
echo print_r($_SESSION['imp']);
echo print_r(imap_errors());
echo print_R(imap_alerts());
echo "</pre>";

After accessing the search page, before going to the inbox I modified
horde/imp/lib/IMP.php and after the following lines:

if ($flags == 0) {
            $_SESSION['imp']['stream'] = @imap_open($connstr,
$_SESSION['imp']['user'], Secret::read(Secret::getKey('imp'),
$_SESSION['imp']['pass']));
        } else {
            $_SESSION['imp']['stream'] = @imap_open($connstr,
$_SESSION['imp']['user'], Secret::read(Secret::getKey('imp'),
$_SESSION['imp']['pass']), $flags);

I added the code to dump out the session contents again


The only difference between what that displayed at the bottom of the search
results page and the failed login page when I tried to go to the inbox was that
the following part:

end of search page
$_SESSION['imp']['stream'] = #3 resource id

failed login page (naturally the headers failed to go out since I used echo
print_r from the IMP.php page)
$_SESSION['imp']['stream'] =


So for some reason the imap_open function did not return the stream which as a
result when imp detects this, it destroys the session and logs you out, since
that is part of its authenicate section.

Now I examined the session variables closely and all the authenication details
remained correct, even
Secret::read(Secret::getKey('imp'), $_SESSION['imp']['pass'])

returned the correct value (well it did just before imp wiped the session).



Now from this and looking at the code in mailbox.php and IMP.php it seems that
something is blocking access to the mailbox after the search so that imp cannot
authenicate the next time around and so logs the user out. Additionally for a
period of time afterwards you cannot log back in as it seems that the imap_open
function returns null for that particular mailbox for a short period afterwards.
About 5 minutes or so.

Note that we are not using maildir but single files for the mail folders,
(forget what its called) and the search I executed would have tried to access
>25,000 mails taking up 295MB on the server.


Does anyone have any suggestions for tracing this problem further, I'm assuming
that I need to examine the following areas:

Could be the request caused an overflow so the mailbox was not closed correctly?
It was still searching through the mail during the time that access was blocked
to the folder and the php code had returned to early without indicating a
timeout, therefore the imapd had left the folders locked?

Possible issue areas
c-client
imp (unlikely but perhaps if the search was too big it should have blocked it)
imapd


I've asked the server admins to forward on some logs to me so I can try and
trace whats happening. Anyone ever encountered this before or have some
suggestions on how to locate what was going wrong. Once I work out what went
wrong I might be able to work on a patch to help imp prevent this issue occuring
in the future.


Thanks in advance for any suggestions of info anyone provides.

--

Darragh Bailey
webteam member for Computer Society NUIG
webteam at compsoc.nuigalway.ie

"Nothing is foolproof to a sufficiently talented fool."