#2415 1.4.9a search option deadlocks with PMDF imap

closed-fixed
nobody
None
5
2010-01-16
2007-01-12
ric
No

Squirrelmail 1.4.9a deadlocks talking to a PMDF imap server.

It appears that, when looking for "whatever", PMDF wants the conversation to go
Squirrelmail: search blah blah {8} - TCP packet 1
PMDF Imap: + Ready for argument - resp to packet 1
Squirrelmail: whatever - TCP packet 2
PMDF Imap: OK response. - resp to packet 2

The problem is squirrelmail crafts a single tcp packet that contains
search blah blah {8}\r\n{whatever}\r\n
in effect pipelining the search. Since PMDF is looking for another packet to come in with the search string, PMDF and squirrelmail deadlock at this point.

The PMDF folks say this is wrong and point to several paragraphs in the IMAP v4 RFC to support their position. I pawed thru the UW imap source code, and it appears this works with UW imap just because of how it happens to read data, which, in effect allows the search string to be in the same packet as the search command.

It would be nice if squirrelmail could send the "search",
check for a "+ Ready for argument" response, then send the search string. AFAIK this should work with any IMAP server.

Discussion

  • Chris Hilts

    Chris Hilts - 2007-01-12
    • status: open --> pending-works-for-me
     
  • Chris Hilts

    Chris Hilts - 2007-01-12

    Logged In: YES
    user_id=626255
    Originator: NO

    It's my understanding that the PMDF folks are completely incorrect, and I cite RFC3501 section 6.4.4 to back me up. If you feel I'm wrong on this, please feel free to quote them so I may better understand the situation.

     
  • ric

    ric - 2007-01-12
    • status: pending-works-for-me --> open-works-for-me
     
  • ric

    ric - 2007-01-12

    Logged In: YES
    user_id=1690720
    Originator: YES

    Ok, here's the sticking point...

    RFC 3501 says in the data formats section 4.3 under "string":
    4.3. String
    [some text deleted]... In the case of
    literals transmitted FROM CLIENT to server, the client MUST wait
    to receive a command continuation request (described later in
    this document) before sending the octet data (and the remainder
    of the command).
    ---

     
  • Tomas Kuliavas

    Tomas Kuliavas - 2007-01-13

    Logged In: YES
    user_id=225877
    Originator: NO

    SquirrelMail does not work with literals correctly.

    Try setting your imap server type to macosx or hmailserver.

     
  • Thijs Kinkhorst

    Thijs Kinkhorst - 2007-01-18

    Logged In: YES
    user_id=285765
    Originator: NO

    Hi,
    Did tokul's advice work?

     
  • Chris Hilts

    Chris Hilts - 2007-01-18

    Logged In: YES
    user_id=626255
    Originator: NO

    I'm curious why Squirrelmail appears to be using literals.

     
  • Tomas Kuliavas

    Tomas Kuliavas - 2007-01-18

    Logged In: YES
    user_id=225877
    Originator: NO

    functions/search.php

    Revision 1.50
    Fri Apr 5 04:09:04 2002 UTC (4 years, 9 months ago) by graf25
    Branch: MAIN
    CVS Tags: rel-1_2_6
    Changes since 1.49: +4 -15 lines
    Diff to previous 1.49

    8-bit searches are now possible -- using literals instead of quotes as per
    RFC 2060.

     
  • ric

    ric - 2007-01-18

    Logged In: YES
    user_id=1690720
    Originator: YES

    Changing the IMAP server type from "other" to "hmailserver" makes squirrelmail stop using literals and does make searching work with PMDF imap. Will this band aid work in an 8-bit environment, or are literals required for that?

     
  • Chris Hilts

    Chris Hilts - 2007-01-18
    • status: open-works-for-me --> open-accepted
     
  • Chris Hilts

    Chris Hilts - 2007-01-18

    Logged In: YES
    user_id=626255
    Originator: NO

    Graf's commit says:
    8-bit searches are now possible -- using literals instead of quotes

    Tokul says:
    SquirrelMail does not work with literals correctly.

    So, which is it? This should be fixed. Changing the imap type in conf.pl isn't a fix. That's a workaround.

     
  • Tomas Kuliavas

    Tomas Kuliavas - 2007-01-18

    Logged In: YES
    user_id=225877
    Originator: NO

    PMDF developers are right about SquirrelMail using literals incorrectly. SquirrelMail must wait for server's response instead of executing IMAP query with \r\n.

    IMAP RFC (3501)
    ----
    4.3. String

    A string is in one of two forms: either literal or quoted string.

    ...
    A literal is a sequence of zero or more octets (including CR and LF), prefix-quoted with an octet count in the form of an open brace ("{"), the number of octets, close brace ("}"), and CRLF. In the case of literals transmitted from server to client, the CRLF is immediately followed by the octet data. In the case of literals transmitted from client to server, the client MUST wait to receive a command continuation request (described later in this document) before sending the octet data (and the remainder of the command).

    A quoted string is a sequence of zero or more 7-bit characters, excluding CR and LF, with double quote (<">) characters at each end.
    ----

    SquirrelMail users can use 8bit queries in searches. You can avoid using literals by testing string for 8bit data. It does not change the fact that SquirrelMail IMAP API can't execute correct query with literals. If IMAP search, folder name functions or filtering plugins use literals, they must handle literals without sqimap api or sqimap_run_command() function must be updated to handle multiline queries.

    I think SquirrelMail 1.5.x already has some code to handle literals in filters plugin.

    If you want to do it right, you will need function to quote imap strings and updates to low level sqimap api.

     
  • Jonathan Angliss

    • status: open-accepted --> closed-fixed
     
  • Jonathan Angliss

    The bug you reported has already been fixed, and the fix is committed to the repository. Please update to the latest version in the repository or use a new snapshot. Note that the snapshots might be delayed 24 hours compared to the repository.

    If for some reason your problem still exists, please update this bug report with that information.

    Thank you for your help!

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks