MBOX-Line: From Lynn at BusCom.net  Mon Jun  6 10:31:06 2011
To: imap-protocol@u.washington.edu
From: "Lynn W. Taylor" <Lynn@BusCom.net>
Date: Fri Jun  8 12:34:46 2018
Subject: [Imap-protocol] Where to start?
In-Reply-To: <201106060837.2YFKV00@c.mx.BCN-servers.us>
References: <4DEBB242.2090200@BusCom.net>
	<201106051924.p55JOwpG003543@mxout12.cac.washington.edu>
	<4DEBDFF5.9000301@BusCom.net>
	<4DEC1C93.24755.853F5AE5@David.Harris.pmail.gen.nz>
	<4DEC5CC4.5010507@BusCom.net>
	<201106060837.2YFKV00@c.mx.BCN-servers.us>
Message-ID: <4DED0EDA.3030303@BusCom.net>

I intend to test as many ways as possible, and I agree that "de-jure" 
RFC-3501 compliance is the goal.

Testing with telnet is going to verify that my server works the way I 
think it should. It doesn't validate my understanding of RFC-3501.

... and when I finish my server, it has to work with clients, and it has 
to provide reasonable results based on what real mail clients do.

Testing with Pine makes an incredible amount of sense.

One of the things pushing IMAP is mobile.

On 6/6/2011 8:36 AM, Pete Maclean wrote:
> I have been inspired to supplement my tips on building an IMAP server 
> with 10 tips for testing. A couple of these have already been 
> mentioned. Here they are:
>
>
> 1). Do not rely on testing just from the position of a client. Write 
> test programs for the back-end code of each significant command, 
> especially CREATE, LIST and FETCH.
>
> 2). Do initial online testing with a telnet client. You will likely 
> continue using telnet testing throughout the server?s lifetime.
>
> 3). There is no one IMAP client you can rely on to test your server. 
> This is simply because no one client does everything. (As is 
> appropriate: servers must do everything that is not clearly optional, 
> such as PREAUTH, but client designers pick and choose what elements of 
> the protocol to make use of.) Pine may be the best one to start with 
> because it makes use of so much of the protocol. Test with any and 
> every client you can, both good ones and bad. Clients for desktop 
> systems tend to be the most fully featured while mobile clients may be 
> very limited. Nevertheless, mobile clients may do things that desktop 
> clients don?t (such as use the BINARY extension when it is offered and 
> fetch just the first few characters of a message).
>
> 4). Test with multiple connections open for the same account both 
> working in different mailboxes and working in the same mailbox.
>
> 5). For testing things like the numbering of body parts and generation 
> of BODYSTRUCTURE data, find a reference server to use, one that you 
> can trust to do it right. Compare the output of the same command sent 
> for the same message on your server and the reference server. Do the 
> same for SEARCH. (I used Cyrus for this purpose.)
>
> 6). Be sure your server has a way of recording conversations, that is 
> creating a transcript of every command received and response sent for 
> a connection. This is invaluable for troubleshooting. You may want to 
> include extra hints such as timing information (carefully 
> distinguished from the protocol text).
>
> 7). You can implement private X- commands for debugging. This is like 
> having a built-in debugger. Of course you either have to build your 
> own client or use telnet manually to take advantage of these but they 
> can be a great boon. My server even has an X-CRASH command that 
> deliberately makes it fault so I can verify that its crash-handling is 
> working as it should. (Needless to say, I hope, such commands are 
> enabled only in special accounts.)
>
> 8). Do not stop at testing what should work; also check that your 
> server appropriately handles what should not work. Especially such 
> things as invalid UIDs and message numbers, handling of extension 
> commands when the relevant extensions are not advertised, commands 
> sent in an inappropriate mode, invalid modified UTF-7 data, and 
> oversized mailbox names and paths. Also test things that are valid but 
> may be rarely seen such as FETCH commands with repeated data items, 
> UIDs greater than 0x80000000, and charset values sent as literals in 
> SEARCH commands.
>
> 9). Test with pipelined commands. Few if any clients do pipelining but 
> it is allowed. And don?t forget to test mid-session disconnections and 
> timing out of idle connections.
>
> 10). While many clients make poor use of IMAP, they generally do use 
> it accurately (in the sense of composing commands according to the 
> specified syntax) ? and if they don?t then it is not something you 
> should tolerate. Your message parser however should be ready to deal 
> with any old crap. ?Garbage in, garbage out? is fine but ?garbage in, 
> crash? is not. Test with spam and the junkiest messages you can get 
> your hands on as well as RFC-compliant ones. Mine had a bug that 
> lurked for several years until an empty MIME part of a certain kind 
> came along and blew it up.
>
>

