Error when parsing PERMANENTFLAGS? about emailjs-imap-handler

[jviereck]

Okay, just looking into this a little bit more. I think the problem is located in ParserInstance.prototype.getCommand.

The commands can have a response text, which is defined in the spec 1 by this gramma:

 resp_text       ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text)   
 resp_text_code  ::= "ALERT" / "PARSE" /
                       "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" /
                       "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
                       "UIDVALIDITY" SPACE nz_number /
                       "UNSEEN" SPACE nz_number /
                       atom [SPACE 1*<any TEXT_CHAR except "]">]

The code inside of the ParserInstance.prototype.getCommand method tries to get hold of the resp_text_code from the input string by executing:

responseCode = this.remainder.match(/^ \[[^\]]*\]/);

however, this fails if the content for the resp_text_code contains an additional ] character. This is the case in my failing example (here an reduced example) due to

* OK [PERMANENTFLAGS (ostern [css3-page] \*)] Flags permitted.

and

responseCode = " [PERMANENTFLAGS (ostern [css3-page] \*)] Flags permitted.".remainder.match(/^ \[[^\]]*\]/);
console.log(responseCode); 
// PRINTS:  [PERMANENTFLAGS (ostern [css3-page]
// EXPECTED: [PERMANENTFLAGS (ostern [css3-page] \*)]

The best solution might be to implement a proper parser for the resp_text, but this will be more effort. For now I try to implement a shortcut, which in the case of PERMANENTFLAGS seeks for the closing ).

[jviereck]

Seems like the idea proposed above worked - this seems to produce a reasonable response text:

    ParserInstance.prototype.getCommand = function() {
        var responseCode;

        if (!this.command) {
            this.command = this.getElement(imapFormalSyntax.command());
        }

        switch ((this.command || "").toString().toUpperCase()) {
            case "OK":
            case "NO":
            case "BAD":
            case "PREAUTH":
            case "BYE":
                if (this.remainder.indexOf(' [PERMANENTFLAGS') === 0) {
                    responseCode = [this.remainder.substr(0, this.remainder.indexOf(')]') + 2)];
                }
                responseCode = responseCode || this.remainder.match(/^ \[[^\]]*\]/);
                if (responseCode) {
                    this.humanReadable = this.remainder.substr(responseCode[0].length).trim();
                    this.remainder = responseCode[0];
                } else {
                    this.humanReadable = this.remainder.trim();
                    this.remainder = "";
                }
                break;
        }

        return this.command;
    };

However, the TokenParser fails to process a string like [PERMANENTFLAGS (ostern [css3-page] JunkRecorded \*)]. There are many assumptions in the parser at the moment that try to guess the interpret [ of correctly but fail here as [css3-page] should be an atom.

@felixhammerl, do you have a good idea how to continue from here? Have you considered implementing a proper parser against the BNF described in 1?

[andris9]

Thanks for the report, this was not known so far. This issue with [ and ] in names goes a bit deeper than just PERMANENTFLAGS as it can happen anywhere. For example a mailbox can be named as "[zzz]" and as imap-handler is not context aware, it would try to wrongly parse this totally valid atom into a list.

The solution would be to identify where [] lists are actually required and treat these values as an atom anywhere else. So far it seems [] can only be used as a list after a OK/BAD/... response and as BODY/BODY.PEEK sequence argument. I'm going through specs to identify any other places but the idea would be that [ starts a list only if it is in these specific places, otherwise it would be treated as a beginning for an atom string.

[jviereck]

I'm going through specs to identify any other places but the idea would be that [ starts a list only if it is in these specific places, otherwise it would be treated as a beginning for an atom string.

That sounds like a good idea to start! Let me know if you need a help with something on the way :)

[felixhammerl]

fixed with 186d2dd
released to npm and tagged as v0.1.13

[jviereck]

Thanks for fixing this one! Works fine for me now :)