Possible RFC compliance issues in test cases

[mdecimus]

Hi,

First of all, thank you for this excellent tool! It has been really helpful to detect and fix issues on our IMAP proxy.

I have spotted a few issues on the tests where certain responses are expected which I believe do not comply with RFC3501:

• fetch-body-mime: BODY[1] or BODY[2] responses do not include headers and I believe that they should return both headers as well the body. Looking at section 6.4.6 of RFC3501 it states that "An empty section specification refers to the entire message, including the header." Even though this is referring to BODY[], I believe that BODY[1] should return both headers and body since BODY[1.HEADERS] returns the headers and BODY[1.TEXT] returns the actual body. If BODY[1] is the same as BODY[1.TEXT], there is no way to retrieve the entire section including headers as it is possible for instance when calling BODY[], BODY[HEADERS] and BODY[TEXT] which all return different sections of the entire message.

• listext: Line 90 should start with * instead of !. As per RFC5258, if the mailbox exists and does not meet the selection criteria but it has a child that matches the selection criteria then the returned attributes should be () + CHILDINFO.

• sort-size: Line 8 should be * sort 7 4 5 3 6 2 8 1

Please let me know your thoughts.

Thanks!

[sirainen]

Hi,

• fetch-body-mime: I'd have to spend some time with the RFC to give a better answer, but the short answer is that all the widely used IMAP servers behave the way this is tested, so even if RFC were wrong/confusing it would break IMAP clients if this was changed. Or at least this is true for body[1]. I'm not sure if body[2] is really a valid thing to even ask from a server, since it points to the whole message/rfc822 part.
• listext: This is a bit of an edge case. My idea here when writing the test was that if you have test2/test1 subscribed, then:
  • If you do list (subscribed recursivematch) "" * - it's going to list test2/test1 in any case so there is no need to list test2 by itself with the CHILDINFO. I think this may be written in some way in the RFC.
  • If you do list (subscribed recursivematch) "" % - then it needs to list test2 with CHILDINFO, because the child isn't listed.
  • If you do list (subscribed recursivematch) "" (test2 test2/test1) (which is what this test does) it's similar to listing with * in that the test2/test1 is listed, so listing test2 with CHILDINFO is unnecessary.
  • I could accept it being optionally returned, but I don't think it's required.
• sort-size: No, the test is intentionally done this way and it is correct. For example if you look at the mails 1 and 8, they are the same size. So sorting forwards the sort order is "1 8". But when sorting in reverse, since they are the same size their primary sort order shows them as equal. The secondary sort order is to sort by the MSN/UID, so "1 8" is still the correct order.

[mdecimus]

Thanks for the quick reply.

• fetch-body-mime: That was my guess, so I'll change the behaviour to what most IMAP clients expect.
• listext: I see your point, I am going to make this rule optional on my fork of the tests.
• sort-size: You are correct, I had missed that part of RFC 5256.

Thanks again!