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

closed-fixed
None
5
2003-06-17
2003-06-14
No

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.

Discussion

  • 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.

     
  • Marc Groot Koerkamp

    • assigned_to: nobody --> stekkel
     
  • Ray Ferguson

    Ray Ferguson - 2003-06-17

    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

    Ray Ferguson - 2003-06-17

    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

    • status: open --> closed-fixed
     
  • 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

    Ray Ferguson - 2003-06-20

    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.

     

Log in to post a comment.