With the newest c-client version (IMAP-2002.RC10), imap_fetchstructure() does not appear to correctly handle multipart messages.  The following example message:

=====

Return-Path: <travel@priceline.m0.net>
Delivered-To: slusarz@bigworm.colorado.edu
Received: from localhost (localhost [127.0.0.1])
	by bigworm.colorado.edu (Postfix) with ESMTP id D56241096
	for <slusarz@bigworm.colorado.edu>; Tue, 12 Nov 2002 10:42:17 -0700 (MST)
Received: from bigworm.colorado.edu ([127.0.0.1]) by localhost (bigworm.colorado.edu [127.0.0.1]) (amavisd-new) with ESMTP id 19282-10 for <slusarz@bigworm.colorado.edu>; Tue, 12 Nov 2002 10:42:16 -0000 (MST)
Received: from wopr.Colorado.EDU (wopr.Colorado.EDU [128.138.196.42])
	by bigworm.colorado.edu (Postfix) with ESMTP id 346A81095
	for <slusarz@bigworm.colorado.edu>; Tue, 12 Nov 2002 10:42:16 -0700 (MST)
Received: from fac607.m0.net (fly.m0.net [209.11.137.109])
	by wopr.Colorado.EDU (8.12.5/8.12.4/UnixOps+Hesiod (wopr)) with SMTP id gACHgCiM011342
	for <SLUSARZ@colorado.edu>; Tue, 12 Nov 2002 10:42:12 -0700 (MST)
Message-ID: <7336030921.1037122928622@m0.net>
Date: Tue, 12 Nov 2002 09:42:08 -0800 (PST)
From: "priceline.com" <travel@priceline.m0.net>
Reply-To: travel@priceline.m0.net
To: SLUSARZ@colorado.edu
Subject: Short Notice Travel Deals from Priceline
Errors-To: travel@priceline.m0.net
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="---=_NEXT_f17957ffc2"


-----=_NEXT_f17957ffc2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

[snip]

-----=_NEXT_f17957ffc2
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

[snip]

-----=_NEXT_f17957ffc2--

=====

produces the following output using imap_fetchstructure():

stdClass Object
(
    [type] => 1
    [encoding] => 0
    [ifsubtype] => 1
    [subtype] => ALTERNATIVE
    [ifdescription] => 0
    [ifid] => 0
    [lines] => 138762584
    [ifdisposition] => 0
    [ifdparameters] => 0
    [ifparameters] => 1
    [parameters] => Array
        (
            [0] => stdClass Object
                (
                    [attribute] => boundary
                    [value] => ---=_NEXT_f17957ffc2
                )

        )

    [parts] => Array
        (
        )

)

As can be seen, no additional object appear in the parts array (there should be 2 additional stdObjects - one for each nested part).

The same problems occur (and can be verified by me) with multipart/mixed messages also.

This message is correctly handled using an older version of UW c-client (imap-2001a).  Additionally, a fresh compilation of pine using the latest c-client also handles the this message correctly.  Thus, it doesn't _appear_ to be a c-client issue (although my internal analysis of PHP and IMAP code is admittedly very very weak).

PHP configuration line:
'./configure' '--with-apxs=/httpd/bin/apxs' '--with-mysql' '--without-gd' '--with-gdbm' '--disable-short-tags' '--disable-debug' '--with-config-file-path=/httpd/conf' '--with-imap=/usr/local/src/c-client' '--with-imap-ssl' '--with-gettext' '--enable-ftp' '--with-pear=/httpd/lib/php/pear' '--enable-inline-optimization' '--with-mcrypt=/usr/local/libmcrypt' '--with-zlib' '--with-domxml'