#1309 Yet another loop in parseAddress() imap_general.php

[Ray Ferguson]

Pardon me for reposting this. I added this to an old
ticket opened for general performance problems, but it
looks like that ticket is complaining about a seperate
issue and also not really getting any attention. I
originally saw a similar problem to this with other
malformed headers but the imap_general.php and
Rfc822Header.class.php cvs updates fixed it for most
accounts. This one account has another sort of
malformed header though that forms another loop in the
parse address function.

This user had about 40 messages in the inbox. When
trying to view inbox you get the same time exeeded in
imap_general.php line 448...
(the parseAddress function). It turns out to be
another bad
header causing a loop. I found the message and the
offending header section.

To: "Obfuscated User" <notme@fake.com>,
To: <orme@fake.com>,
To: <another@fake.com>,
To: <someother@fake.com>

After removing three extra To: lines the problem goes away.
I got permission from the recipient to share the
message w/
the devolper if it would be of use in testing. I can
recreate this problem by placing the message in another
email box. This loop
occurs when there is no sort= option specified in the
user.pref file and server side sorting is on w/ courier
imap. Of course conditions may not have to be quite that
specific to reproduce it.

I've attached a copy of the message w/ obfuscated
addresses.

-ray.

[Ray Ferguson]

[Marc Groot Koerkamp]

Logged In: YES
user_id=476981

I rewrote the address parser function and as far as I know
it cannot run into a infinite loop anymore. The problem was
that we used the function recursive in case of group
addresses which starts with : and ends with ;

Please check the latest SM 1.5 imap_general.php function
(you can also use the same file for a SM 1.4.1 install at
this moment)

And report if it works okey.

[Ray Ferguson]

Logged In: YES
user_id=756274

This particular email still breaks the parseAddress() function in version
1.150 of imap_general.php. Timeouts still consitantly occur in the
parseAddress() function. I used the imap test module and found
courier returns the following when it runs into this particular message:

TEST_6

Request:

A009 FETCH 1:* (FLAGS BODY[HEADER.FIELDS (FROM DATE TO)])

Response:

* 1 FETCH (FLAGS () BODY[HEADER.FIELDS ("FROM" "DATE" "TO")]
{208}
From: <randygilde@morgansmagic.biz>
To: "winnie sawyer" <prairiegarden@bigfoot.com>,
To: <frip@bigfoot.com>,
To: <darylp@bigfoot.com>,
To: <bandd@bigfoot.com>
Date: Mon, 09 Jun 2003 21:37:17 -0900

)
FETCH completed.

[Marc Groot Koerkamp]

Logged In: YES
user_id=476981

you need 1.51 of imap_general.php. Watch out for the not up
to date cvs viewer. You are viewing a backup instead of
realtime cvs.

[Ray Ferguson]

Logged In: YES
user_id=756274

Fix verified. I just put the 1.51 imap_general.php in
production for several thousand users. Thank you for your
work and the speedy response.

-ray.

[Marc Groot Koerkamp]

Logged In: YES
user_id=476981

Okey, just submitted version 1.152 with some minor tweaks
regarding parseAddress and now it works even better :)

Thnx for testing it.

Next issue to fix is porting this function to
class/mime/Rfc822Header.class.php

[Ray Ferguson]

Logged In: YES
user_id=756274

Just I just ported imap_general.php 1.153 and Rfc822Header 1.24 to
my production server and did notice it sorting faster. I'll let you know
if anyting unexpected comes up. It looks pretty solid though.

Thanks.