idnits 2.17.1 draft-leiba-imap-mailconnect3-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 325: '... all": clients MUST still deal with ...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1998) is 9507 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Auth' on line 536 looks like a reference -- Missing reference section? 'SASL' on line 539 looks like a reference -- Missing reference section? 'Plain' on line 548 looks like a reference -- Missing reference section? 'CRAM' on line 554 looks like a reference -- Missing reference section? 'SCRAM' on line 557 looks like a reference -- Missing reference section? 'IPCP' on line 542 looks like a reference -- Missing reference section? 'TLS' on line 545 looks like a reference -- Missing reference section? 'Implement' on line 561 looks like a reference -- Missing reference section? 'Language' on line 564 looks like a reference -- Missing reference section? 'Children' on line 567 looks like a reference -- Missing reference section? 'Namespace' on line 570 looks like a reference -- Missing reference section? '1' on line 496 looks like a reference -- Missing reference section? 'RFC-2060' on line 533 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Leiba, IBM T.J. Watson Research Center 3 Internet Draft P. Hoffman, Internet Mail Consortium 4 Document: draft-leiba-imap-mailconnect3-00.txt November 1997 5 Expires April 1998 7 IMAP MailConnect 3 Report 9 Status of this Document 11 This document provides information for the Internet community. This 12 document does not specify an Internet standard of any kind. 13 Distribution of this document is unlimited. 15 This document is an Internet Draft. Internet Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its Areas, 17 and its Working Groups. Note that other groups may also distribute 18 working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six 21 months. Internet Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet 23 Drafts as reference material or to cite them other than as a "working 24 draft" or "work in progress". 26 To learn the current status of any Internet-Draft, please check the 27 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 28 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 29 munnari.oz.au. 31 1. Abstract 33 In an effort to help increase the depth of interoperability in the 34 Internet mail industry, over 80 people from 16 companies participated 35 in MailConnect 3, a two-day event sponsored by the Internet Mail 36 Consortium and held in San Jose, California, October 30 and 31, 1997. 37 This document reports the findings of the MailConnect 3 event. 39 2. Conventions used in this document 41 In examples, "C:" indicates lines sent by a client that is connected 42 to a server. "S:" indicates lines sent by the server to the client. 44 When the text calls out references, in [square brackets], see section 45 7, "References". 47 Internet DRAFT IMAP MailConnect 3 Report November 1997 49 3. About the MailConnect Event 51 In an effort to help increase the depth of interoperability in the 52 Internet mail industry, over 80 people from 16 companies participated 53 in MailConnect 3, a two-day event sponsored by the Internet Mail 54 Consortium (see http://www.imc.org/ for information about the IMC and 55 about the MailConnect events) and held in San Jose, California, 56 October 30 and 31, 1997. The participant companies included: 58 AT&T Labs Innosoft Qualcomm 59 Control Data i-Planet Software.com 60 ESYS Isocor Sun 61 Hewlett-Packard MetaInfo Worldtalk 62 IBM/Lotus Microsoft 63 IRdg Netscape 65 The two primary focuses of the event were testing IMAP clients and 66 servers, and testing end-to-end Internet mail security using S/MIME 67 and PGP/MIME. The goal of the event was to enable participating 68 vendors to test their software against that of other vendors so that 69 each could find where they did and did not interoperate and conform 70 to the protocols. 72 Unlike many marketing-based events, MailConnect 3 was exclusively for 73 technical staff of the participants, and press and marketing staff 74 were not invited. There were no formal tests that vendors had to 75 participate in, and no pass or fail grades were given out. The 76 purpose of the event was the testing itself, not grading the 77 performance of any of the participants. 79 4. The IMAP Testing 81 Most of the participants at MailConnect 3 were testing IMAP clients 82 and servers (or both). In general, people felt that IMAP 83 interoperability had improved markedly in the six months since 84 MailConnect 2, particularly for companies that had participated in 85 each. At the wrap-up session at the end of the event, the consensus 86 was that the typical user perception of interoperability in IMAP 87 would be very good, although some felt that it would only be 88 adequate. 90 Although fetching of body parts was not implemented in all clients, 91 and disconnected mode was not implemented in any of the clients that 92 were tested, most companies felt that the servers that were tested 93 would be ready when the clients were. 95 Having a large number of IMAP vendors being in the same room caused 97 Internet DRAFT IMAP MailConnect 3 Report November 1997 99 some discussions on important topics that were not being addressed in 100 the market. The two biggest discussions during the event were about 101 authentication and internationalization (see below). 103 4.1 IMAP Authentication [Auth] and SASL [SASL] (Chris Newman, 104 Innosoft) 106 The customer requirements were perceived as: 108 * Many customers are happy with a mechanism such as LOGIN (an 109 experimental unspecified SASL mechanism which some have 110 implemented) or PLAIN (a non-standard specified SASL mechanism 111 [Plain]) when the SASL profile base64-encodes the password. 113 * Most customers appear to be satisfied by 40-bit SSL + plaintext 114 password. 116 * Developers recognize neither of the above two options is 117 acceptably secure, but they are adequate for most customer 118 demand. A few customer markets want something stronger. 120 Developers, of course, had their own opinions. For some vendors, any 121 mechanism which requires a new authentication database is very hard 122 to deploy and will be ignored unless it becomes a very popular among 123 customers. These include CRAM [CRAM], SCRAM [SCRAM], OTP, S/Key and 124 Kerberos. 126 CRAM: Server vendors aren't fond of this mechanism. Some vendors 127 don't like need for new authentication database, others don't like 128 plaintext equivalent verifiers on server. Client vendors like 129 simplicity. 131 SCRAM: Server vendors who don't mind deploying a new authentication 132 database like this due to simplicity. 134 OTP or S/Key: Some have implemented S/Key [Auth]. Not interesting to 135 many due to authentication database requirements and speed with which 136 one time passwords are used up. 138 Kerberos5: This is too hard to administrate at present and there are 139 no current implementations in IMAP clients/servers (there are a few 140 Kerberos4 implementations). This may become viable if WinNT 5.0 141 makes it simple enough to administrate, but time will tell. 143 Proposed SASL mechanism which does strong authentication of password 144 but doesn't require authentication of rest of session: This is 145 interesting to vendors as it should be exportable and will strongly 146 protect the password. Will allow strong authentication without 148 Internet DRAFT IMAP MailConnect 3 Report November 1997 150 change of backend database or slowdown of entire session. Chris 151 agreed to produce specification soon with DSS/DH/3DES. 153 Other authentication issues were also discussed. Many participants 154 were interested in password change protocol [IPCP], but some vendors 155 satisfied with SSL web page. There was general agreement to switch 156 to STARTTLS command [TLS] instead of using separate port for TLS. 157 Some developers have started work on SASL API; discussion will be on 158 the ietf-sasl@imc.org mailing list (subscribe at 159 ietf-sasl-request@imc.org). 161 4.2 IMAP Internationalization (John Myers, Netscape) 163 The group discussed the issue of what charsets to use with the SEARCH 164 CHARSET facility of IMAP. It was agreed that the IMAP implementor's 165 guide [Implement] include a recommendation that servers implement the 166 UTF-8 charset with this command. 168 The group also discussed the proposed LANGUAGE extension [Language] 169 and its interaction with IMAP namespaces. Servers implementing 170 LANGUAGE are likely to want to localize the exposed NAMESPACE 171 prefixes and the name of the INBOX. However, it is clear that this 172 causes a problem with IMAP URLs. If we use LANGUAGE, the client will 173 need some way to figure out the URL for a given folder. After much 174 talk, it was decided that the problem will need to be discussed on 175 the IMAP list. 177 4.3 IBM Research's Report (Barry Leiba, IBM Research) 179 The 4.3.x subsections contain reports from IBM Research's testing 180 only. They do not represent a consensus of any kind. They do not 181 necessarily even represent the general view of IBM or Lotus; indeed, 182 there were developers from other parts of IBM and Lotus besides IBM 183 Research, and those developers may have had different results from 184 those stated here. Nevertheless, this author feels that the general 185 community of IMAP developers will be well served by having this 186 summary publicised. 188 The rules of the IMC MailConnect events do not permit the divulgence 189 of specific results against specific products. Rather, this report 190 is on the author's preception of the general state of 191 interoperability between IMAP clients and IMAP servers at this time, 192 and, as such, is intended to encourage and assist the development of 193 clients and servers that operate well with each other. 195 Those interested in other recommendations for implementation of IMAP 196 clients and servers should refer to [Implement], which reflects the 198 Internet DRAFT IMAP MailConnect 3 Report November 1997 200 consensus of the IMAP community in many interoperability matters. 202 4.3.1 Client Comments 204 IBM Research ran a server that is part of a research project, against 205 which the client developers tested their clients. This author's 206 comments about client behaviour are based solely on the logs kept on 207 that server, from which we could see the protocol being used by the 208 clients (after eliminating the obvious telnet sessions, in which 209 testers were typing commands by hand). These comments, therefore, do 210 not reflect what a user might actually have seen while using the 211 clients. 213 There were, unfortunately, relatively few clients represented at the 214 MailConnect 3 event - fewer than ten different clients were tested 215 there. The protocol used by the clients was generally valid 216 protocol. One client used commands associated with a protocol 217 extension whose presence was not advertised in the CAPABILITY 218 response, and one client used the obsolete FIND command. Apart from 219 that, all protocol used was legal, valid IMAP4rev1 protocol. 221 Clients varied widely in their discovery of mailbox lists. Most 222 clients have now ceased to use the dangerous 223 C: 001 LIST "" * 224 method of mailbox discovery in favour of 225 C: 001 LIST "" % 226 and 227 C: 001 LSUB "" * 228 but there is a great variability in the mechanism used to go below 229 that. Some clients search for all second-level inferiors at startup, 230 presumably so that they may correctly place "+" expansion icons on 231 the mailbox list. This can be costly if the mailbox tree boradens 232 quickly at the second level, and there is a new Internet Draft 233 [Children] designed to make the accurate placement of the expansion 234 icons easier and more efficient. 236 Some clients do not look for second-level mailboxes until the user 237 opens a first-level mailbox, but some of those clients use the 238 "refname" parameter of the LIST command for that discovery, a 239 practice that assumes specific server behaviour with respect to the 240 refname, and which is, therefore, inadvisable (the command 241 C: 002 LIST "XYZ" % 242 will, on some servers, result in the desired list of the inferiors of 243 mailbox "XYZ", but on other servers it will not). 245 Clients, at least those present at MailConnect 3, seem to be moving 246 away from the practice of fetching entire message bodies (with FETCH 247 RFC822, for instance), and are, instead, fetching individual body 249 Internet DRAFT IMAP MailConnect 3 Report November 1997 251 parts as needed. This is a welcome change from this author's earlier 252 observations. 254 Clients are beginning to use some of the new FETCH options, including 255 BODY[HEADER.FIELDS (...)], BODY[n.MIME], and partial fetches. This 256 shows that clients are finding ways to take advantage of some of the 257 advanced features of IMAP4rev1, but it is also uncovering some server 258 problems as servers are unprepared for these usages and are sometimes 259 immature in their support of them (see below). 261 We do not know how many clients offer configuration of a mailbox 262 prefix, but we cannot overstress the importance of providing this. 263 Some servers, for example, do not allow creation of inferiors of 264 "inbox", while others require that all user-created mailboxes be 265 inferiors of "inbox". Until the Namespace extension [Namespace] is 266 completed and widely deployed, there's no way to reconcile this sort 267 of variation without making a configuration option available. 269 4.3.2 Server Comments 271 Our group did server testing mostly with an automated test client, 272 which ran predefined test scenarios against each server. These 273 scenarios were designed to test different aspects of server behaviour 274 with 275 * commands that we expect to be common from clients, 276 * commands that we expect to be uncommon, but reasonable, 277 * commands that were designed to test the limits of the protocol, 278 and 279 * commands that are actually invalid. 281 The servers are generally returning syntactially valid responses to 282 the clients, though there were some exceptions, especially in the 283 areas of some of the less-used FETCH options. Particular problems 284 seemed to show up in the BODY[HEADER.FIELDS (...)] responses; server 285 developers must take particular care to follow the grammar for these 286 responses. 288 On the receiving end, we found that quite a bit of valid IMAP4rev1 289 protocol was rejected or misinterpreted by some servers. One item 290 was so bad that we had to change our test suite in order to get it to 291 run on several servers, so it's worth mentioning here: the APPEND 292 command takes the mailbox name before the data, and is usually issued 293 in this form: 294 C: 004 APPEND MBOXNAME {nnn} 295 S: + send data 296 C: ...... RFC822 data ...... 297 S: 004 OK done 299 Internet DRAFT IMAP MailConnect 3 Report November 1997 301 The mailbox name may, however, also be sent as a literal, thus: 302 C: 004 APPEND {8} 303 S: + send data 304 C: MBOXNAME {nnn} 305 S: + send data 306 C: ...... RFC822 data ...... 307 S: 004 OK done 309 Several servers did not support this syntax. Some of them saw the 310 first literal, assumed it was to be the RFC822 data, and complained 311 that the mailbox name was missing. Others took the string "{8}" to 312 be the mailbox name, failing to recognise it as a literal. This was 313 the single most serious problem that we encountered. Server 314 developers should be careful to accept literals anywhere they are 315 valid. (We did not actually expect this to be a stress test; the 316 reason our test sent mailbox names as literals is because it's easier 317 to set it up that way in case the hierarchy delimiter turns out to be 318 the backslash, which must either be escaped or sent in a literal.) 320 All servers maintained persistent UIDs and almost all servers 321 supported IMAP4rev1, returned accurate RFC822.SIZE, allowed dual-use 322 mailboxes (mailboxes that can contain messages and inferiors at the 323 same time), allowed the deletion of a non-empty mailbox, and allowed 324 multiple sessions to select the same mailbox. But note that "almost 325 all": clients MUST still deal with servers that do not allow these 326 things. 328 On the other hand, servers were much more divided in whether they 329 allow the deletion of the currently selected mailbox and in how they 330 handle the refname parameter of the LIST command. It continues to be 331 a good idea for clients to assume that they can't delete the selected 332 mailbox and that they should not use the refname in an attempt to 333 list inferiors. 335 There are also distressingly many servers that do not support 336 subscriptions (they respond to LSUB either with all mailboxes or with 337 none). We suspect that this will change over time, as users demand 338 this feature. 340 There is still very little server support for authentication methods, 341 and the LOGIN command remains the way one must gain access to most 342 IMAP servers. A client that supported a wide array of authentication 343 methods actually could often find one to use - many servers support 344 one or another of them - but there is no one method (or even two 345 methods) that could be recommended at this point as "the best one to 346 start with". 348 Servers were generally weakest on SEARCH commands, giving various 349 results and exhibiting various bugs and limitations. All servers 351 Internet DRAFT IMAP MailConnect 3 Report November 1997 353 handled flag searches fine, which is good: the flag searches are the 354 ones most likely to be used internally by clients. Still, users who 355 want to do date searching (SENDSINCE, and such) and those who want to 356 search for substrings in message texts and header fields may be in 357 for unpredictable results. Some servers did not correctly match 358 substrings in header fields, some only allowed matching on certian 359 "known" header fields, some had problems with the handling of date 360 searches. These may be uncommon things to do, but they will also 361 cause significant end-user confusion when they don't work 362 consistently. 364 There were a number of miscellaneous protocol problems - where 365 servers responded NO or BAD to valid protocol - and all developers 366 were happy to find out about these problems and hurried off to fix 367 them. There seems to be no long-term problem here, but just a bit of 368 advice: carefully implement to the spec, and particularly to the 369 formal grammar. Try to avoid the temptation to implement to someone 370 else's implementation, because that leads to interoperability 371 problems further along. It's one thing to say, "We want our server 372 to work with Joe's client, so we'll test it against Joe's client 373 first." It's another thing to say, "We want our server to work with 374 Joe's client, so we'll design it based on what Joe's client does," 375 and that approach is ill-advised. 377 Servers are about evenly divided in whether they do or don't permit 378 the client to create a mailbox with a non-7-bit-ascii character in 379 the name. The IMAP4rev1 spec advises the use of UTF-7 encoding for 380 such names, but about half the servers allow the raw 8-bit character. 381 This is arguably a client issue (client shouldn't do that), but from 382 an interoperability standpoint it would be useful for servers to stop 383 it at their end (otherwise one client might create a mailbox name 384 that another client couldn't deal with). 386 There is still a wide variation on the response to a command such as 387 C: 008 FETCH 18 ENVELOPE 388 in a mailbox with fewer than 18 messages. We think that, because 389 this is syntactically correct but semantically wrong, the correct 390 response is NO. We see servers returning all three possible answers: 391 OK, NO, and BAD. In reality this will not likely present an 392 interoperability problem, since only a buggy client will issue such a 393 FETCH command. 395 A few servers modified APPENDed messages, adding, removing, or 396 changing some message header fields. This might present 397 interoperability problems for clients doing resynchronization after 398 reconnecting - in order to determine the UID of the message that the 399 client just APPENDed, it might compare certain header fields with its 400 copy, and could get confused if these header fields changed. 402 Internet DRAFT IMAP MailConnect 3 Report November 1997 404 Some servers did not make APPENDed messages available immediately. 405 This could again be an interoperability problem for disconnected 406 clients trying to reconnect and resynchronise. If the clients APPEND 407 new messages to the selected mailbox and then expect to be able to 408 retrieve information about them immediately after receiving a tagged 409 OK from the APPEND command, they may become confused when the new 410 message seems not yet to be there. Clients should be careful to wait 411 for an EXISTS response announcing the availability of the new 412 message, but this can be annoying when the client must periodically 413 send NOOP commands to poll for this event. Happily, most servers do 414 provide access to the new message immediately. 416 Some servers allow the deletion of a mailbox that's intermediate in 417 the hierarchy - that is, if mailboxes exist as "x", "x/y", and 418 "x/y/z", some servers allow "DELETE x/y" and will actually eliminate 419 x/y from the list of mailboxes. When used with clients that only 420 allow access to inferior mailboxes through the listed hierarchy, this 421 will "widow" the inferior mailbox x/y/z, rendering it inaccessible to 422 such clients (and this does seem to be the common way for clients to 423 access mailboxes now). Instead, we think the server should mark the 424 deleted mailbox "\Noselect" and let it remain in the mailbox list. 426 4.3.3 What IBM Research Tested 428 The details of our automated test scenario might be useful to some, 429 so we'll list the contents of the test here. Note that while we're 430 showing a mailbox hierarchy delimiter of "/" and are showing mailbox 431 names as quoted strings, the actual test used the proper hierarchy 432 delimiter as return by the server, and sent all mailbox names as 433 literals. 435 LOGIN ... ... 436 LIST "" "" [get hierarchy delimiter] 437 CREATE "Sent Mail" [mailbox names actually sent as 438 literals] 439 CREATE "Sent Mail/Broccoli" [substitute proper delimiter] 440 CREATE "Sent Mail/Spinach" 441 CREATE "inbox/Peaches" [see if we can create inbox 442 inferiors] 443 APPEND eight messages to "Sent Mail/Broccoli" 444 [some APPEND commands set specific message flags] 445 LIST "" % 446 LIST "" %/% 447 FIND ALL.MAILBOXES INBOX [test for FIND compatibility 448 support] 449 SELECT "Sent Mail/Broccoli" 450 STORE 8 FLAGS() [turn off flags on last message] 451 FETCH 1:* FULL 453 Internet DRAFT IMAP MailConnect 3 Report November 1997 455 FETCH 8 BODY[1] [this one should return \Seen flag] 456 FETCH 8 BODY[1] 457 STORE 8 +FLAGS \Flagged [test support of flags and syntax] 458 FETCH 8 RFC822.SIZE [save size for next command] 459 FETCH 8 RFC822 [compare size returned with prior] 460 SEARCH ANSWERED 461 SEARCH SENTBEFORE 1-Aug-1996 462 SEARCH SENTON 5-Aug-1996 463 SEARCH SENTAFTER 31-FEB-1997 [test bad date] 464 SEARCH OR HEADER SUBJECT "JPEG" (NOT FLAGGED NOT DRAFT) 465 NOT FROM "xyz" [test complicated search string] 466 Now comes a series of FETCH commands, fetching various attributes and 467 body parts of various messages. Then... 468 COPY 1 "Sent Mail/Spinach" 469 SELECT "Sent Mail/Spinach" 470 FETCH 1 FULL 471 STORE 1 +FLAGS (\Seen) 472 FETCH 1 BODY[1]<0.53> [test partial fetch] 473 STORE 1 +FLAGS (\Deleted) 474 CLOSE 475 FETCH 1:* FULL [test "wrong state" response] 476 SELECT "Sent Mail/Spinach" [make sure message count went down] 477 DELETE "Sent Mail/Spinach" [test deletion of selected mailbox] 478 DELETE "Sent Mail/Broccoli" [test deletion of non-empty mailbox] 479 CREATE "Sent Mail/Bad*Folder1" ["*" is actually 0xE0; test 480 creation of 8-bit mailbox name] 481 CREATE "Sent Mail/SubFolder1" 482 CREATE "Sent Mail/SubFolder1/SubFolder2" 483 LIST "" "Sent Mail/*" 484 LIST "Sent Mail/SubFolder1" % [see what happens with refname] 485 LIST "Sent Mail/SubFolder1/" % [second variation...] 486 Now test hierarchical rename and hierarchical delete. 487 RENAME "Sent Mail/SubFolder1" "Sent Mail/RenFolder1" 488 LIST "" "Sent Mail/*" 489 DELETE "Sent Mail/SubFolder1" [should fail] 490 DELETE "Sent Mail/RenFolder1" [see what happens here] 491 LIST "" "Sent Mail/*" 492 SELECT "Sent Mail" 493 APPEND three messages and look for EXISTS responses. 494 Send NOOP commands if needed to get EXISTS responses. 495 Fetch various combinations of items, including things like 496 FETCH 1 (BODY[1] BODY[1.MIME] BODY[2.MIME]) 497 ...to test fetching multiple body elements in one command. 498 STORE 1:* +FLAGS.SILENT (\Deleted} 499 CLOSE 500 Delete all created mailboxes, then log out. 502 Internet DRAFT IMAP MailConnect 3 Report November 1997 504 5. End-to-End Security with S/MIME and PGP/MIME 506 MailConnect 3 was the first time that S/MIME and PGP/MIME vendors had 507 gotten together to do interoperability testing since the two 508 protocols had been established in the market. Only a few companies 509 supporting each protocol participated, although it is expected that 510 many more will want to test their products at MailConnect 4. 512 The three vendors with S/MIME products tested a wide variety of 513 message types, using different encryption algorithms and types of 514 certificates. They reported that they had almost universal success 515 with the tests, with the exception in the area of self-signed 516 certificates, which are not well documented in the S/MIME v2 517 specification. The three vendors testing PGP/MIME only tested a small 518 number of messages, and reported that there were some problems with 519 some implementations. 521 6. Post-Event Testing 523 The IMAP, S/MIME, and PGP/MIME testers agreed that having some 524 post-event testing, before MailConnect 4, would be a good way to 525 check whether or not they had in fact fixed bugs that were found at 526 the event. The event's mailing list is always available to any vendor 527 who wants to find other vendors to test with. In addition, IMC will 528 set up a testing system for both S/MIME and PGP/MIME vendors to 529 exchange messages easily. 531 7. References 533 [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version 534 4rev1", RFC 2060, University of Washington, December 1996. 536 [Auth], Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, 537 Carnegie Mellon, December 1994. 539 [SASL], Myers, J., "Simple Authentication and Security Layer (SASL)", 540 draft-myers-auth-sasl-13.txt, October 1997. 542 [IPCP], Newman & Gellens, "Internet Password Change Protocol (IPCP)", 543 draft-newman-pwchange-00.txt, July 1997. 545 [TLS], Newman, C., "Using TLS with IMAP4 and POP3", 546 draft-newman-tls-imappop-01.txt, Innosoft, November 1997. 548 [Plain] Newman, C., "Plaintext Password SASL Mechanism for 549 Transitioning", draft-newman-sasl-plaintrans-04.txt, Innosoft, 550 November 1997. 552 Internet DRAFT IMAP MailConnect 3 Report November 1997 554 [CRAM] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension for 555 Simple Challenge/Response", RFC 2195, MCI, September 1997. 557 [SCRAM], Newman, C., "Salted Challenge Response Authentication 558 Mechanism (SCRAM)", draft-newman-auth-scram-01.txt, Innosoft, October 559 1997. 561 [Implement], Leiba, B., "IMAP4 Implementation Recommendations", 562 draft-leiba-imap-implement-guide-04.txt, IBM Research, November 1997. 564 [Language], Gahrns & McCown, "IMAP4 Language Extension", 565 draft-gahrns-imap-language-00.txt, November 1997. 567 [Children], Gahrns & Cheng, "IMAP4 Child Mailbox Extension", draft- 568 gahrns-imap-child-mailbox-00.txt, Microsoft, November 1997. 570 [Namespace], Gahrns & Newman, "IMAP4 Namespace", draft-gahrns-imap- 571 namespace-05.txt, November 1997. 573 8. Authors' Addresses 575 Barry Leiba 576 IBM T.J. Watson Research Center 577 30 Saw Mill River Road 578 Hawthorne, NY 10532 USA 580 Phone: 1-914-784-7941 581 Email: leiba@watson.ibm.com 583 Paul Hoffman, Director 584 Internet Mail Consortium 585 127 Segre Place 586 Santa Cruz, CA 95060 USA 588 Phone: 1-408-426-9827 589 Email: phoffman@imc.org