SquirrelMail

We have identified a small bug that crops up when an IMAP server provides
the "body location" element in the BODYSTRUCTURE response (see RFC 3501 sec
7.4.2) as our latest version of Sun Java System Messaging Server does when
a message has a "Content-location" header.

The simplest case of failure is a body structure of:

("TEXT" "PLAIN" ("CHARSET" "us-ascii") NIL NIL "7BIT" 6 1 NIL NIL NIL
("file.txt"))

I believe the bug is due to an off by one bug in parseParenthesis() --
called from parseBodyStructure() when it encounters a left-paren '(' on a
BODYSTRUCTURE element that it doesn't otherwise have a parser for.

Upon entry to parseParenthesis(), $i is at the position in the string
left-paren that triggered parseParenthesis() in the first place, so the
case statement then immediately calls parseProperties() which absorbs the
left-parenthesis and the corresponding right-parenthesis.

By adding a $i++ as the first line of parseParenthesis() (line 823 in
Message.class.php) we resolve all our test cases that failed parsing
previously, and don't interfere with other body structure parsing.

Here is our simplest test case:

require_once('class/mime/Message.class.php');
require_once('class/mime/MessageHeader.class.php');

$read = '("TEXT" "PLAIN" ("CHARSET" "us-ascii") NIL NIL "7BIT" 6 1 NIL
NIL NIL ("file.txt"))';

$i = 0;
$sub_msg = '';

$msg = Message::parseBodyStructure($read, $i, $sub_msg);

if ($msg)
{
print "Success\n";
}
else
{
print "Failure\n";
}