mailing list archives

To start off, a bit of background information:

I am currently working on writing a comprehensive IMAP testing server 
for use in automated regression tests for the email clients Thunderbird 
and SeaMonkey. If you would like to see more, you can view my trials and 
tribulations at <https://bugzilla.mozilla.org/show_bug.cgi?id=437193>.

I'll admit that I have not gotten around to reading all of the IMAP RFCs 
yet, nor have I read the entire archives yet, so I apologize in advance 
if I ask a question answered in one of those two forums.

These are some questions that pop into my mind when reading the RFC:
1. Which parts are case-sensitive and which parts are not? The only 
explicit mentions I see are that literals in the ABNF are 
case-insensitive, and that base64 strings are case sensitive (for 
obvious reasons), that INBOX is case-insensitive, and that other mailbox 
names are explicitly not defined with respect to case-sensitivity.

2. Can hierarchy delimiters change recursively (e.g., "Users" has a 
delimiter of "/" but "Users/news" has a delimiter of ".")? To what 
degree do multiple hierarchy delimiters exist in nature?

3. Is there any definitive list of which servers support which 
extensions, including how they don't support them correctly (okay, that 
wasn't about the RFC itself)?

4. Are there any explicit pitfalls I might want to test or look out for 
when writing the testing server?

Thanks in advance for your response.

-- 
Joshua Cranmer

Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth

> 1. Which parts are case-sensitive and which parts are not?

From page 81:
        (1) Except as noted otherwise, all alphabetic characters
        are case-insensitive.

This means, besides what you noted, that flags are case-insensitive.

> 2. Can hierarchy delimiters change recursively (e.g., "Users" has a
> delimiter of "/" but "Users/news" has a delimiter of ".")? To what
> degree do multiple hierarchy delimiters exist in nature?

Hierarchy delimiters are constant for a particular root.  A server which has multiple roots is supposed to use the # namespace convention which is there for that purpose.  So, if you have USENET news, you should use something like #news.comp.mail.imap and not /Users/news/comp.mail.imap since you can't mix hierarchy delimiters in the same root.

> 3. Is there any definitive list of which servers support which
> extensions, including how they don't support them correctly (okay, that
> wasn't about the RFC itself)?

Such a list is ever changing, and listing what servers don't support them correctly is likely to result in considerable hostility aimed at the lister.  It's easier to list servers that do things right: UW/Panda, Dovecot, and Cyrus.  The author of Dovecot has been quite diligent in producing torture tests for servers, and he and the author of UW/Panda (me) have had a friendly competition in who can fix the problems uncovered first.

> 4. Are there any explicit pitfalls I might want to test or look out for
> when writing the testing server?

Writing an IMAP server is not for the faint-hearted or for one who hasn't read (and understood) the entire RFC.  Good luck...

-- Mark --

_________________________________________________________________
Use video conversation to talk face-to-face with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_video_072008

Mark Crispin wrote:
>> 3. Is there any definitive list of which servers support which
>> extensions, including how they don't support them correctly (okay, that
>> wasn't about the RFC itself)?
>>     
>
> Such a list is ever changing, and listing what servers don't support them correctly is likely to result in considerable hostility aimed at the lister.  It's easier to list servers that do things right: UW/Panda, Dovecot, and Cyrus.  The author of Dovecot has been quite diligent in producing torture tests for servers, and he and the author of UW/Panda (me) have had a friendly competition in who can fix the problems uncovered first.
>   
Pray tell, where might I find this list?

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth

Joshua Cranmer wrote:
> Mark Crispin wrote:

>> Such a list is ever changing, and listing what servers don't support 
>> them correctly is likely to result in considerable hostility aimed at 

> Pray tell, where might I find this list?

I think what he meant is that by virtue of it being ever changing and 
possibly causing hostility such a list doesn't really exist in practice. :-)

As a side note, I see what once was uw-imapd has gotten a name change. I 
am happy to see development is continuing.

Best regards,
Jeroen

Joshua,

I keep a table of client capabilities at
<http://uplib.parc.com/misc/imapclients.html>.  You might be interested
in that, and I'd be interested in verifying these client capabilities
and updating the table.

Any client implementers who'd like to send me updates -- I'll be happy
to incorporate them.

Bill

Joshua Cranmer wrote:
> Mark Crispin wrote:
>> Such a list is ever changing, and listing what servers don't support 
>> them correctly is likely to result in considerable hostility aimed at 
>> the lister.  It's easier to list servers that do things right: 
>> UW/Panda, Dovecot, and Cyrus.  The author of Dovecot has been quite 
>> diligent in producing torture tests for servers, and he and the 
>> author of UW/Panda (me) have had a friendly competition in who can 
>> fix the problems uncovered first.
>>   
> Pray tell, where might I find this list?
>
For clarification: I'm referring to the torture test list.

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth

> As a side note, I see what once was uw-imapd has gotten a name change. I
> am happy to see development is continuing.

Unfortunately, that's a bit over-optimistic.

I have forked UW imapd for my own purposes on my private panda.com domain.  I have made improvements to it since that time.   However, without funding, I can not continue development, nor maintenance, nor open-source distribution for anyone other than myself.

I do not know what plans UW may have to continue development, although I doubt very much that they will do so.

I'm sorry.

-- Mark --

_________________________________________________________________
Making the world a better place one message at a time.
http://www.imtalkathon.com/?source=EML_WLH_Talkathon_BetterPlace

On Thu, 2008-07-10 at 21:16 -0400, Joshua Cranmer wrote:
> Joshua Cranmer wrote:
> > Mark Crispin wrote:
> >> Such a list is ever changing, and listing what servers don't support 
> >> them correctly is likely to result in considerable hostility aimed at 
> >> the lister.  It's easier to list servers that do things right: 
> >> UW/Panda, Dovecot, and Cyrus.  The author of Dovecot has been quite 
> >> diligent in producing torture tests for servers, and he and the 
> >> author of UW/Panda (me) have had a friendly competition in who can 
> >> fix the problems uncovered first.
> >>   
> > Pray tell, where might I find this list?
> >
> For clarification: I'm referring to the torture test list.

http://imapwiki.org/ImapTest/ServerStatus

Currently it just lists a boring n/34 number for servers. It wouldn't be
too difficult to have imaptest print out which problems are related to
which extensions (or base protocol, or combination of extensions). And I
guess the n/34 could be a link that lists all the issues with all the
specifics. But I haven't bothered yet.

Anyway, feel free to create new tests and I'll add them to imaptest
distribution. It should be quite easy to create the tests (at least from
the syntax point of view - how to create comprehensive and correct tests
are another matter).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20080711/7292b929/attachment.sig>