102 lines
4.9 KiB
Plaintext
102 lines
4.9 KiB
Plaintext
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.
|
|
>
|
|
>
|
|
|