Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Initial commit

  • Loading branch information...
commit 2fdcf8936fc7a67b64905dc7eef354d56cdf24ed 0 parents
@timburks authored
Showing with 41,965 additions and 0 deletions.
  1. +4,943 −0 ChangeLog
  2. +19 −0 Documentation/AUTHORS
  3. +504 −0 Documentation/LICENSE
  4. +69 −0 Documentation/README
  5. +507 −0 Documentation/RFC/rfc1870.txt
  6. +1,291 −0 Documentation/RFC/rfc1939.txt
  7. +1,739 −0 Documentation/RFC/rfc2045.txt
  8. +2,467 −0 Documentation/RFC/rfc2046.txt
  9. +843 −0 Documentation/RFC/rfc2047.txt
  10. +676 −0 Documentation/RFC/rfc2183.txt
  11. +899 −0 Documentation/RFC/rfc2192.txt
  12. +899 −0 Documentation/RFC/rfc2222.txt
  13. +451 −0 Documentation/RFC/rfc2384.txt
  14. +619 −0 Documentation/RFC/rfc2554.txt
  15. +787 −0 Documentation/RFC/rfc2646.txt
  16. +1,291 −0 Documentation/RFC/rfc2683.txt
  17. +2,859 −0 Documentation/RFC/rfc2822.txt
  18. +9 −0 Documentation/TODO
  19. +29 −0 Examples/SimplePOP3/GNUmakefile
  20. +199 −0 Examples/SimplePOP3/SimplePOP3.m
  21. +29 −0 Examples/SimpleSMTP/GNUmakefile
  22. +237 −0 Examples/SimpleSMTP/SimpleSMTP.m
  23. +156 −0 Framework/Pantomime/CWCacheManager.h
  24. +141 −0 Framework/Pantomime/CWCacheManager.m
  25. +109 −0 Framework/Pantomime/CWCharset.h
  26. +316 −0 Framework/Pantomime/CWCharset.m
  27. +124 −0 Framework/Pantomime/CWConnection.h
  28. +367 −0 Framework/Pantomime/CWConstants.h
  29. +96 −0 Framework/Pantomime/CWConstants.m
  30. +96 −0 Framework/Pantomime/CWContainer.h
  31. +246 −0 Framework/Pantomime/CWContainer.m
  32. +63 −0 Framework/Pantomime/CWDNSManager.h
  33. +123 −0 Framework/Pantomime/CWDNSManager.m
  34. +140 −0 Framework/Pantomime/CWFlags.h
  35. +240 −0 Framework/Pantomime/CWFlags.m
  36. +639 −0 Framework/Pantomime/CWFolder.h
  37. +970 −0 Framework/Pantomime/CWFolder.m
  38. +92 −0 Framework/Pantomime/CWFolderInformation.h
  39. +93 −0 Framework/Pantomime/CWFolderInformation.m
  40. +95 −0 Framework/Pantomime/CWIMAPCacheManager.h
  41. +408 −0 Framework/Pantomime/CWIMAPCacheManager.m
  42. +177 −0 Framework/Pantomime/CWIMAPFolder.h
  43. +489 −0 Framework/Pantomime/CWIMAPFolder.m
  44. +82 −0 Framework/Pantomime/CWIMAPMessage.h
  45. +164 −0 Framework/Pantomime/CWIMAPMessage.m
  46. +270 −0 Framework/Pantomime/CWIMAPStore.h
  47. +2,959 −0 Framework/Pantomime/CWIMAPStore.m
  48. +32 −0 Framework/Pantomime/CWISO8859_1.h
  49. +57 −0 Framework/Pantomime/CWISO8859_1.m
  50. +32 −0 Framework/Pantomime/CWISO8859_10.h
  51. +57 −0 Framework/Pantomime/CWISO8859_10.m
  52. +32 −0 Framework/Pantomime/CWISO8859_11.h
  53. +55 −0 Framework/Pantomime/CWISO8859_11.m
  54. +32 −0 Framework/Pantomime/CWISO8859_13.h
  55. +57 −0 Framework/Pantomime/CWISO8859_13.m
  56. +32 −0 Framework/Pantomime/CWISO8859_14.h
  57. +57 −0 Framework/Pantomime/CWISO8859_14.m
  58. +32 −0 Framework/Pantomime/CWISO8859_15.h
  59. +57 −0 Framework/Pantomime/CWISO8859_15.m
  60. +32 −0 Framework/Pantomime/CWISO8859_2.h
  61. +57 −0 Framework/Pantomime/CWISO8859_2.m
  62. +32 −0 Framework/Pantomime/CWISO8859_3.h
  63. +55 −0 Framework/Pantomime/CWISO8859_3.m
  64. +32 −0 Framework/Pantomime/CWISO8859_4.h
  65. +57 −0 Framework/Pantomime/CWISO8859_4.m
  66. +32 −0 Framework/Pantomime/CWISO8859_5.h
  67. +57 −0 Framework/Pantomime/CWISO8859_5.m
  68. +32 −0 Framework/Pantomime/CWISO8859_6.h
  69. +48 −0 Framework/Pantomime/CWISO8859_6.m
  70. +32 −0 Framework/Pantomime/CWISO8859_7.h
  71. +55 −0 Framework/Pantomime/CWISO8859_7.m
  72. +32 −0 Framework/Pantomime/CWISO8859_8.h
  73. +49 −0 Framework/Pantomime/CWISO8859_8.m
  74. +32 −0 Framework/Pantomime/CWISO8859_9.h
  75. +57 −0 Framework/Pantomime/CWISO8859_9.m
  76. +205 −0 Framework/Pantomime/CWInternetAddress.h
  77. +346 −0 Framework/Pantomime/CWInternetAddress.m
  78. +32 −0 Framework/Pantomime/CWKOI8_R.h
  79. +63 −0 Framework/Pantomime/CWKOI8_R.m
  80. +32 −0 Framework/Pantomime/CWKOI8_U.h
  81. +63 −0 Framework/Pantomime/CWKOI8_U.m
  82. +93 −0 Framework/Pantomime/CWLocalCacheManager.h
  83. +646 −0 Framework/Pantomime/CWLocalCacheManager.m
  84. +36 −0 Framework/Pantomime/CWLocalFolder+maildir.h
  85. +190 −0 Framework/Pantomime/CWLocalFolder+maildir.m
  86. +50 −0 Framework/Pantomime/CWLocalFolder+mbox.h
  87. +807 −0 Framework/Pantomime/CWLocalFolder+mbox.m
  88. +143 −0 Framework/Pantomime/CWLocalFolder.h
  89. +809 −0 Framework/Pantomime/CWLocalFolder.m
  90. +100 −0 Framework/Pantomime/CWLocalMessage.h
  91. +261 −0 Framework/Pantomime/CWLocalMessage.m
  92. +93 −0 Framework/Pantomime/CWLocalStore.h
  93. +938 −0 Framework/Pantomime/CWLocalStore.m
  94. +87 −0 Framework/Pantomime/CWMD5.h
  95. +489 −0 Framework/Pantomime/CWMD5.m
  96. +78 −0 Framework/Pantomime/CWMIMEMultipart.h
  97. +91 −0 Framework/Pantomime/CWMIMEMultipart.m
  98. +158 −0 Framework/Pantomime/CWMIMEUtility.h
  99. +956 −0 Framework/Pantomime/CWMIMEUtility.m
  100. +48 −0 Framework/Pantomime/CWMacOSXGlue.h
  101. +42 −0 Framework/Pantomime/CWMacOSXGlue.m
  102. +590 −0 Framework/Pantomime/CWMessage.h
  103. +2,061 −0 Framework/Pantomime/CWMessage.m
  104. +69 −0 Framework/Pantomime/CWPOP3CacheManager.h
  105. +257 −0 Framework/Pantomime/CWPOP3CacheManager.m
  106. +92 −0 Framework/Pantomime/CWPOP3CacheObject.h
  107. +133 −0 Framework/Pantomime/CWPOP3CacheObject.m
  108. +106 −0 Framework/Pantomime/CWPOP3Folder.h
  109. +223 −0 Framework/Pantomime/CWPOP3Folder.m
  110. +83 −0 Framework/Pantomime/CWPOP3Message.h
  111. +139 −0 Framework/Pantomime/CWPOP3Message.m
  112. +112 −0 Framework/Pantomime/CWPOP3Store.h
Sorry, we could not display the entire diff because it was too big.
4,943 ChangeLog
4,943 additions, 0 deletions not shown
19 Documentation/AUTHORS
@@ -0,0 +1,19 @@
+Ludovic Marcotte <ludovic@Sophos.ca>
+====================================
+- main developer
+
+
+Jonathan B. Leffert <jonathan@leffert.net>
+==========================================
+- some methods in the NSString category
+
+
+ Alexander Malmberg <alexander@malmberg.org>
+============================================
+- some bug fixes and enhanced support of qp and base64
+
+
+Ujwal S. Sathyam <ujwal@setlurgroup.com>
+========================================
+- frequent contributor
+- contributor on the maildir code
504 Documentation/LICENSE
@@ -0,0 +1,504 @@
+ GNU LESSER GENERAL PUBLIC LICENSE
+ Version 2.1, February 1999
+
+ Copyright (C) 1991, 1999 Free Software Foundation, Inc.
+ 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+[This is the first released version of the Lesser GPL. It also counts
+ as the successor of the GNU Library Public License, version 2, hence
+ the version number 2.1.]
+
+ Preamble
+
+ The licenses for most software are designed to take away your
+freedom to share and change it. By contrast, the GNU General Public
+Licenses are intended to guarantee your freedom to share and change
+free software--to make sure the software is free for all its users.
+
+ This license, the Lesser General Public License, applies to some
+specially designated software packages--typically libraries--of the
+Free Software Foundation and other authors who decide to use it. You
+can use it too, but we suggest you first think carefully about whether
+this license or the ordinary General Public License is the better
+strategy to use in any particular case, based on the explanations below.
+
+ When we speak of free software, we are referring to freedom of use,
+not price. Our General Public Licenses are designed to make sure that
+you have the freedom to distribute copies of free software (and charge
+for this service if you wish); that you receive source code or can get
+it if you want it; that you can change the software and use pieces of
+it in new free programs; and that you are informed that you can do
+these things.
+
+ To protect your rights, we need to make restrictions that forbid
+distributors to deny you these rights or to ask you to surrender these
+rights. These restrictions translate to certain responsibilities for
+you if you distribute copies of the library or if you modify it.
+
+ For example, if you distribute copies of the library, whether gratis
+or for a fee, you must give the recipients all the rights that we gave
+you. You must make sure that they, too, receive or can get the source
+code. If you link other code with the library, you must provide
+complete object files to the recipients, so that they can relink them
+with the library after making changes to the library and recompiling
+it. And you must show them these terms so they know their rights.
+
+ We protect your rights with a two-step method: (1) we copyright the
+library, and (2) we offer you this license, which gives you legal
+permission to copy, distribute and/or modify the library.
+
+ To protect each distributor, we want to make it very clear that
+there is no warranty for the free library. Also, if the library is
+modified by someone else and passed on, the recipients should know
+that what they have is not the original version, so that the original
+author's reputation will not be affected by problems that might be
+introduced by others.
+
+ Finally, software patents pose a constant threat to the existence of
+any free program. We wish to make sure that a company cannot
+effectively restrict the users of a free program by obtaining a
+restrictive license from a patent holder. Therefore, we insist that
+any patent license obtained for a version of the library must be
+consistent with the full freedom of use specified in this license.
+
+ Most GNU software, including some libraries, is covered by the
+ordinary GNU General Public License. This license, the GNU Lesser
+General Public License, applies to certain designated libraries, and
+is quite different from the ordinary General Public License. We use
+this license for certain libraries in order to permit linking those
+libraries into non-free programs.
+
+ When a program is linked with a library, whether statically or using
+a shared library, the combination of the two is legally speaking a
+combined work, a derivative of the original library. The ordinary
+General Public License therefore permits such linking only if the
+entire combination fits its criteria of freedom. The Lesser General
+Public License permits more lax criteria for linking other code with
+the library.
+
+ We call this license the "Lesser" General Public License because it
+does Less to protect the user's freedom than the ordinary General
+Public License. It also provides other free software developers Less
+of an advantage over competing non-free programs. These disadvantages
+are the reason we use the ordinary General Public License for many
+libraries. However, the Lesser license provides advantages in certain
+special circumstances.
+
+ For example, on rare occasions, there may be a special need to
+encourage the widest possible use of a certain library, so that it becomes
+a de-facto standard. To achieve this, non-free programs must be
+allowed to use the library. A more frequent case is that a free
+library does the same job as widely used non-free libraries. In this
+case, there is little to gain by limiting the free library to free
+software only, so we use the Lesser General Public License.
+
+ In other cases, permission to use a particular library in non-free
+programs enables a greater number of people to use a large body of
+free software. For example, permission to use the GNU C Library in
+non-free programs enables many more people to use the whole GNU
+operating system, as well as its variant, the GNU/Linux operating
+system.
+
+ Although the Lesser General Public License is Less protective of the
+users' freedom, it does ensure that the user of a program that is
+linked with the Library has the freedom and the wherewithal to run
+that program using a modified version of the Library.
+
+ The precise terms and conditions for copying, distribution and
+modification follow. Pay close attention to the difference between a
+"work based on the library" and a "work that uses the library". The
+former contains code derived from the library, whereas the latter must
+be combined with the library in order to run.
+
+ GNU LESSER GENERAL PUBLIC LICENSE
+ TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+ 0. This License Agreement applies to any software library or other
+program which contains a notice placed by the copyright holder or
+other authorized party saying it may be distributed under the terms of
+this Lesser General Public License (also called "this License").
+Each licensee is addressed as "you".
+
+ A "library" means a collection of software functions and/or data
+prepared so as to be conveniently linked with application programs
+(which use some of those functions and data) to form executables.
+
+ The "Library", below, refers to any such software library or work
+which has been distributed under these terms. A "work based on the
+Library" means either the Library or any derivative work under
+copyright law: that is to say, a work containing the Library or a
+portion of it, either verbatim or with modifications and/or translated
+straightforwardly into another language. (Hereinafter, translation is
+included without limitation in the term "modification".)
+
+ "Source code" for a work means the preferred form of the work for
+making modifications to it. For a library, complete source code means
+all the source code for all modules it contains, plus any associated
+interface definition files, plus the scripts used to control compilation
+and installation of the library.
+
+ Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope. The act of
+running a program using the Library is not restricted, and output from
+such a program is covered only if its contents constitute a work based
+on the Library (independent of the use of the Library in a tool for
+writing it). Whether that is true depends on what the Library does
+and what the program that uses the Library does.
+
+ 1. You may copy and distribute verbatim copies of the Library's
+complete source code as you receive it, in any medium, provided that
+you conspicuously and appropriately publish on each copy an
+appropriate copyright notice and disclaimer of warranty; keep intact
+all the notices that refer to this License and to the absence of any
+warranty; and distribute a copy of this License along with the
+Library.
+
+ You may charge a fee for the physical act of transferring a copy,
+and you may at your option offer warranty protection in exchange for a
+fee.
+
+ 2. You may modify your copy or copies of the Library or any portion
+of it, thus forming a work based on the Library, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+ a) The modified work must itself be a software library.
+
+ b) You must cause the files modified to carry prominent notices
+ stating that you changed the files and the date of any change.
+
+ c) You must cause the whole of the work to be licensed at no
+ charge to all third parties under the terms of this License.
+
+ d) If a facility in the modified Library refers to a function or a
+ table of data to be supplied by an application program that uses
+ the facility, other than as an argument passed when the facility
+ is invoked, then you must make a good faith effort to ensure that,
+ in the event an application does not supply such function or
+ table, the facility still operates, and performs whatever part of
+ its purpose remains meaningful.
+
+ (For example, a function in a library to compute square roots has
+ a purpose that is entirely well-defined independent of the
+ application. Therefore, Subsection 2d requires that any
+ application-supplied function or table used by this function must
+ be optional: if the application does not supply it, the square
+ root function must still compute square roots.)
+
+These requirements apply to the modified work as a whole. If
+identifiable sections of that work are not derived from the Library,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works. But when you
+distribute the same sections as part of a whole which is a work based
+on the Library, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote
+it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Library.
+
+In addition, mere aggregation of another work not based on the Library
+with the Library (or with a work based on the Library) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+ 3. You may opt to apply the terms of the ordinary GNU General Public
+License instead of this License to a given copy of the Library. To do
+this, you must alter all the notices that refer to this License, so
+that they refer to the ordinary GNU General Public License, version 2,
+instead of to this License. (If a newer version than version 2 of the
+ordinary GNU General Public License has appeared, then you can specify
+that version instead if you wish.) Do not make any other change in
+these notices.
+
+ Once this change is made in a given copy, it is irreversible for
+that copy, so the ordinary GNU General Public License applies to all
+subsequent copies and derivative works made from that copy.
+
+ This option is useful when you wish to copy part of the code of
+the Library into a program that is not a library.
+
+ 4. You may copy and distribute the Library (or a portion or
+derivative of it, under Section 2) in object code or executable form
+under the terms of Sections 1 and 2 above provided that you accompany
+it with the complete corresponding machine-readable source code, which
+must be distributed under the terms of Sections 1 and 2 above on a
+medium customarily used for software interchange.
+
+ If distribution of object code is made by offering access to copy
+from a designated place, then offering equivalent access to copy the
+source code from the same place satisfies the requirement to
+distribute the source code, even though third parties are not
+compelled to copy the source along with the object code.
+
+ 5. A program that contains no derivative of any portion of the
+Library, but is designed to work with the Library by being compiled or
+linked with it, is called a "work that uses the Library". Such a
+work, in isolation, is not a derivative work of the Library, and
+therefore falls outside the scope of this License.
+
+ However, linking a "work that uses the Library" with the Library
+creates an executable that is a derivative of the Library (because it
+contains portions of the Library), rather than a "work that uses the
+library". The executable is therefore covered by this License.
+Section 6 states terms for distribution of such executables.
+
+ When a "work that uses the Library" uses material from a header file
+that is part of the Library, the object code for the work may be a
+derivative work of the Library even though the source code is not.
+Whether this is true is especially significant if the work can be
+linked without the Library, or if the work is itself a library. The
+threshold for this to be true is not precisely defined by law.
+
+ If such an object file uses only numerical parameters, data
+structure layouts and accessors, and small macros and small inline
+functions (ten lines or less in length), then the use of the object
+file is unrestricted, regardless of whether it is legally a derivative
+work. (Executables containing this object code plus portions of the
+Library will still fall under Section 6.)
+
+ Otherwise, if the work is a derivative of the Library, you may
+distribute the object code for the work under the terms of Section 6.
+Any executables containing that work also fall under Section 6,
+whether or not they are linked directly with the Library itself.
+
+ 6. As an exception to the Sections above, you may also combine or
+link a "work that uses the Library" with the Library to produce a
+work containing portions of the Library, and distribute that work
+under terms of your choice, provided that the terms permit
+modification of the work for the customer's own use and reverse
+engineering for debugging such modifications.
+
+ You must give prominent notice with each copy of the work that the
+Library is used in it and that the Library and its use are covered by
+this License. You must supply a copy of this License. If the work
+during execution displays copyright notices, you must include the
+copyright notice for the Library among them, as well as a reference
+directing the user to the copy of this License. Also, you must do one
+of these things:
+
+ a) Accompany the work with the complete corresponding
+ machine-readable source code for the Library including whatever
+ changes were used in the work (which must be distributed under
+ Sections 1 and 2 above); and, if the work is an executable linked
+ with the Library, with the complete machine-readable "work that
+ uses the Library", as object code and/or source code, so that the
+ user can modify the Library and then relink to produce a modified
+ executable containing the modified Library. (It is understood
+ that the user who changes the contents of definitions files in the
+ Library will not necessarily be able to recompile the application
+ to use the modified definitions.)
+
+ b) Use a suitable shared library mechanism for linking with the
+ Library. A suitable mechanism is one that (1) uses at run time a
+ copy of the library already present on the user's computer system,
+ rather than copying library functions into the executable, and (2)
+ will operate properly with a modified version of the library, if
+ the user installs one, as long as the modified version is
+ interface-compatible with the version that the work was made with.
+
+ c) Accompany the work with a written offer, valid for at
+ least three years, to give the same user the materials
+ specified in Subsection 6a, above, for a charge no more
+ than the cost of performing this distribution.
+
+ d) If distribution of the work is made by offering access to copy
+ from a designated place, offer equivalent access to copy the above
+ specified materials from the same place.
+
+ e) Verify that the user has already received a copy of these
+ materials or that you have already sent this user a copy.
+
+ For an executable, the required form of the "work that uses the
+Library" must include any data and utility programs needed for
+reproducing the executable from it. However, as a special exception,
+the materials to be distributed need not include anything that is
+normally distributed (in either source or binary form) with the major
+components (compiler, kernel, and so on) of the operating system on
+which the executable runs, unless that component itself accompanies
+the executable.
+
+ It may happen that this requirement contradicts the license
+restrictions of other proprietary libraries that do not normally
+accompany the operating system. Such a contradiction means you cannot
+use both them and the Library together in an executable that you
+distribute.
+
+ 7. You may place library facilities that are a work based on the
+Library side-by-side in a single library together with other library
+facilities not covered by this License, and distribute such a combined
+library, provided that the separate distribution of the work based on
+the Library and of the other library facilities is otherwise
+permitted, and provided that you do these two things:
+
+ a) Accompany the combined library with a copy of the same work
+ based on the Library, uncombined with any other library
+ facilities. This must be distributed under the terms of the
+ Sections above.
+
+ b) Give prominent notice with the combined library of the fact
+ that part of it is a work based on the Library, and explaining
+ where to find the accompanying uncombined form of the same work.
+
+ 8. You may not copy, modify, sublicense, link with, or distribute
+the Library except as expressly provided under this License. Any
+attempt otherwise to copy, modify, sublicense, link with, or
+distribute the Library is void, and will automatically terminate your
+rights under this License. However, parties who have received copies,
+or rights, from you under this License will not have their licenses
+terminated so long as such parties remain in full compliance.
+
+ 9. You are not required to accept this License, since you have not
+signed it. However, nothing else grants you permission to modify or
+distribute the Library or its derivative works. These actions are
+prohibited by law if you do not accept this License. Therefore, by
+modifying or distributing the Library (or any work based on the
+Library), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Library or works based on it.
+
+ 10. Each time you redistribute the Library (or any work based on the
+Library), the recipient automatically receives a license from the
+original licensor to copy, distribute, link with or modify the Library
+subject to these terms and conditions. You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties with
+this License.
+
+ 11. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License. If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Library at all. For example, if a patent
+license would not permit royalty-free redistribution of the Library by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Library.
+
+If any portion of this section is held invalid or unenforceable under any
+particular circumstance, the balance of the section is intended to apply,
+and the section as a whole is intended to apply in other circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system which is
+implemented by public license practices. Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+
+ 12. If the distribution and/or use of the Library is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Library under this License may add
+an explicit geographical distribution limitation excluding those countries,
+so that distribution is permitted only in or among countries not thus
+excluded. In such case, this License incorporates the limitation as if
+written in the body of this License.
+
+ 13. The Free Software Foundation may publish revised and/or new
+versions of the Lesser General Public License from time to time.
+Such new versions will be similar in spirit to the present version,
+but may differ in detail to address new problems or concerns.
+
+Each version is given a distinguishing version number. If the Library
+specifies a version number of this License which applies to it and
+"any later version", you have the option of following the terms and
+conditions either of that version or of any later version published by
+the Free Software Foundation. If the Library does not specify a
+license version number, you may choose any version ever published by
+the Free Software Foundation.
+
+ 14. If you wish to incorporate parts of the Library into other free
+programs whose distribution conditions are incompatible with these,
+write to the author to ask for permission. For software which is
+copyrighted by the Free Software Foundation, write to the Free
+Software Foundation; we sometimes make exceptions for this. Our
+decision will be guided by the two goals of preserving the free status
+of all derivatives of our free software and of promoting the sharing
+and reuse of software generally.
+
+ NO WARRANTY
+
+ 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
+WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
+EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
+OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
+KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
+LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
+THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+ 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
+WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
+AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU
+FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
+CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
+LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
+RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
+FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
+SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
+DAMAGES.
+
+ END OF TERMS AND CONDITIONS
+
+ How to Apply These Terms to Your New Libraries
+
+ If you develop a new library, and you want it to be of the greatest
+possible use to the public, we recommend making it free software that
+everyone can redistribute and change. You can do so by permitting
+redistribution under these terms (or, alternatively, under the terms of the
+ordinary General Public License).
+
+ To apply these terms, attach the following notices to the library. It is
+safest to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least the
+"copyright" line and a pointer to where the full notice is found.
+
+ <one line to give the library's name and a brief idea of what it does.>
+ Copyright (C) <year> <name of author>
+
+ This library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ This library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with this library; if not, write to the Free Software
+ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+
+Also add information on how to contact you by electronic and paper mail.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the library, if
+necessary. Here is a sample; alter the names:
+
+ Yoyodyne, Inc., hereby disclaims all copyright interest in the
+ library `Frob' (a library for tweaking knobs) written by James Random Hacker.
+
+ <signature of Ty Coon>, 1 April 1990
+ Ty Coon, President of Vice
+
+That's all there is to it!
+
+
69 Documentation/README
@@ -0,0 +1,69 @@
+Pantomime v1.2.0
+===============================================================================
+
+
+Compiling Pantomime for GNUstep
+===============================================================================
+
+To try Pantomime, your first need to install GNUstep. You can get GNUstep at:
+
+http://www.gnustep.org
+
+Be sure to fully read and understand the GNUstep installation procedure. You
+can read a comprehensive guide on how to install GNUstep on Unix systems here:
+
+http://documents.made-it.com/GNUstep/Build/
+
+Once you have installed GNUstep, you can compile Pantomime.
+
+To compile and install it:
+
+cd Pantomime
+make
+make install
+
+If you are using RedHat 9 or Fedora, you might have to define the
+ADDITIONAL_OBJCFLAGS environment variable, like this:
+
+export ADDITIONAL_OBJCFLAGS="-I/usr/kerberos/include"
+
+in order to include the Kerberos headers during compilation (since
+your OpenSSL installation requires them).
+
+
+Compiling Pantomime for Apple Mac OS X
+===============================================================================
+
+In order to compile Pantomime under OS X, you first need to install Apple's
+developer tools. You can get them at:
+
+http://developer.apple.com/tools/
+
+Once you've downloaded and installed the developer tools, open Xcode.
+
+Once Xcode is started, open the Pantomime's project file (Pantomime.xcode).
+
+To compile it, choose the "Build" menu item from the "Build" menu. This will create
+a "Pantomime.framework" directory inside the Pantomime's build directory. You can
+safely move this framework where you want, or simply add it to your application
+from Xcode (Project->Add Frameworks...).
+
+
+Using Pantomime in your application
+===============================================================================
+
+Under GNUstep, you must add the following line to your GNUmakefile:
+
+ADDITIONAL_LDFLAGS = -lPantomime
+
+Under Apple Mac OS X, you must add the following compiler flag:
+
+-DMACOSX
+
+Otherwise, you'll get errors when compiling your application.
+
+
+===============================================================================
+Author: Ludovic Marcotte (ludovic@Sophos.ca)
+
+The name "Pantomime" was proposed by Jay Kominek.
507 Documentation/RFC/rfc1870.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group J. Klensin, WG Chair
+Request For Comments: 1870 MCI
+STD: 10 N. Freed, Editor
+Obsoletes: 1653 Innosoft International, Inc.
+Category: Standards Track K. Moore
+ University of Tennessee
+ November 1995
+
+
+ SMTP Service Extension
+ for Message Size Declaration
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+1. Abstract
+
+ This memo defines an extension to the SMTP service whereby an SMTP
+ client and server may interact to give the server an opportunity to
+ decline to accept a message (perhaps temporarily) based on the
+ client's estimate of the message size.
+
+2. Introduction
+
+ The MIME extensions to the Internet message protocol provide for the
+ transmission of many kinds of data which were previously unsupported
+ in Internet mail. One expected result of the use of MIME is that
+ SMTP will be expected to carry a much wider range of message sizes
+ than was previously the case. This has an impact on the amount of
+ resources (e.g. disk space) required by a system acting as a server.
+
+ This memo uses the mechanism defined in [5] to define extensions to
+ the SMTP service whereby a client ("sender-SMTP") may declare the
+ size of a particular message to a server ("receiver-SMTP"), after
+ which the server may indicate to the client that it is or is not
+ willing to accept the message based on the declared message size and
+ whereby a server ("receiver-SMTP") may declare the maximum message
+ size it is willing to accept to a client ("sender-SMTP").
+
+
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 1]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+3. Framework for the Size Declaration Extension
+
+ The following service extension is therefore defined:
+
+ (1) the name of the SMTP service extension is "Message Size
+ Declaration";
+
+ (2) the EHLO keyword value associated with this extension is "SIZE";
+
+ (3) one optional parameter is allowed with this EHLO keyword value, a
+ decimal number indicating the fixed maximum message size in bytes
+ that the server will accept. The syntax of the parameter is as
+ follows, using the augmented BNF notation of [2]:
+
+ size-param ::= [1*DIGIT]
+
+ A parameter value of 0 (zero) indicates that no fixed maximum
+ message size is in force. If the parameter is omitted no
+ information is conveyed about the server's fixed maximum message
+ size;
+
+ (4) one optional parameter using the keyword "SIZE" is added to the
+ MAIL FROM command. The value associated with this parameter is a
+ decimal number indicating the size of the message that is to be
+ transmitted. The syntax of the value is as follows, using the
+ augmented BNF notation of [2]:
+
+ size-value ::= 1*20DIGIT
+
+ (5) the maximum length of a MAIL FROM command line is increased by 26
+ characters by the possible addition of the SIZE keyword and
+ value;
+
+ (6) no additional SMTP verbs are defined by this extension.
+
+ The remainder of this memo specifies how support for the extension
+ affects the behavior of an SMTP client and server.
+
+4. The Message Size Declaration service extension
+
+ An SMTP server may have a fixed upper limit on message size. Any
+ attempt by a client to transfer a message which is larger than this
+ fixed upper limit will fail. In addition, a server normally has
+ limited space with which to store incoming messages. Transfer of a
+ message may therefore also fail due to a lack of storage space, but
+ might succeed at a later time.
+
+
+
+
+
+Klensin, et al Standards Track [Page 2]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+ A client using the unextended SMTP protocol defined in [1], can only
+ be informed of such failures after transmitting the entire message to
+ the server (which discards the transferred message). If, however,
+ both client and server support the Message Size Declaration service
+ extension, such conditions may be detected before any transfer is
+ attempted.
+
+ An SMTP client wishing to relay a large content may issue the EHLO
+ command to start an SMTP session, to determine if the server supports
+ any of several service extensions. If the server responds with code
+ 250 to the EHLO command, and the response includes the EHLO keyword
+ value SIZE, then the Message Size Declaration extension is supported.
+
+ If a numeric parameter follows the SIZE keyword value of the EHLO
+ response, it indicates the size of the largest message that the
+ server is willing to accept. Any attempt by a client to transfer a
+ message which is larger than this limit will be rejected with a
+ permanent failure (552) reply code.
+
+ A server that supports the Message Size Declaration extension will
+ accept the extended version of the MAIL command described below.
+ When supported by the server, a client may use the extended MAIL
+ command (instead of the MAIL command as defined in [1]) to declare an
+ estimate of the size of a message it wishes to transfer. The server
+ may then return an appropriate error code if it determines that an
+ attempt to transfer a message of that size would fail.
+
+5. Definitions
+
+ The message size is defined as the number of octets, including CR-LF
+ pairs, but not the SMTP DATA command's terminating dot or doubled
+ quoting dots, to be transmitted by the SMTP client after receiving
+ reply code 354 to the DATA command.
+
+ The fixed maximum message size is defined as the message size of the
+ largest message that a server is ever willing to accept. An attempt
+ to transfer any message larger than the fixed maximum message size
+ will always fail. The fixed maximum message size may be an
+ implementation artifact of the SMTP server, or it may be chosen by
+ the administrator of the server.
+
+ The declared message size is defined as a client's estimate of the
+ message size for a particular message.
+
+
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 3]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+6. The extended MAIL command
+
+ The extended MAIL command is issued by a client when it wishes to
+ inform a server of the size of the message to be sent. The extended
+ MAIL command is identical to the MAIL command as defined in [1],
+ except that a SIZE parameter appears after the address.
+
+ The complete syntax of this extended command is defined in [5]. The
+ esmtp-keyword is "SIZE" and the syntax for esmtp-value is given by
+ the syntax for size-value shown above.
+
+ The value associated with the SIZE parameter is a decimal
+ representation of the declared message size in octets. This number
+ should include the message header, body, and the CR-LF sequences
+ between lines, but not the SMTP DATA command's terminating dot or
+ doubled quoting dots. Only one SIZE parameter may be specified in a
+ single MAIL command.
+
+ Ideally, the declared message size is equal to the true message size.
+ However, since exact computation of the message size may be
+ infeasable, the client may use a heuristically-derived estimate.
+ Such heuristics should be chosen so that the declared message size is
+ usually larger than the actual message size. (This has the effect of
+ making the counting or non-counting of SMTP DATA dots largely an
+ academic point.)
+
+ NOTE: Servers MUST NOT use the SIZE parameter to determine end of
+ content in the DATA command.
+
+6.1 Server action on receipt of the extended MAIL command
+
+ Upon receipt of an extended MAIL command containing a SIZE parameter,
+ a server should determine whether the declared message size exceeds
+ its fixed maximum message size. If the declared message size is
+ smaller than the fixed maximum message size, the server may also wish
+ to determine whether sufficient resources are available to buffer a
+ message of the declared message size and to maintain it in stable
+ storage, until the message can be delivered or relayed to each of its
+ recipients.
+
+ A server may respond to the extended MAIL command with any of the
+ error codes defined in [1] for the MAIL command. In addition, one of
+ the following error codes may be returned:
+
+ (1) If the server currently lacks sufficient resources to accept a
+ message of the indicated size, but may be able to accept the
+ message at a later time, it responds with code "452 insufficient
+ system storage".
+
+
+
+Klensin, et al Standards Track [Page 4]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+ (2) If the indicated size is larger than the server's fixed maximum
+ message size, the server responds with code "552 message size
+ exceeds fixed maximium message size".
+
+ A server is permitted, but not required, to accept a message which
+ is, in fact, larger than declared in the extended MAIL command, such
+ as might occur if the client employed a size-estimation heuristic
+ which was inaccurate.
+
+6.2 Client action on receiving response to extended MAIL command
+
+ The client, upon receiving the server's response to the extended MAIL
+ command, acts as follows:
+
+ (1) If the code "452 insufficient system storage" is returned, the
+ client should next send either a RSET command (if it wishes to
+ attempt to send other messages) or a QUIT command. The client
+ should then repeat the attempt to send the message to the server
+ at a later time.
+
+ (2) If the code "552 message exceeds fixed maximum message size" is
+ received, the client should immediately send either a RSET command
+ (if it wishes to attempt to send additional messages), or a QUIT
+ command. The client should then declare the message undeliverable
+ and return appropriate notification to the sender (if a sender
+ address was present in the MAIL command).
+
+ A successful (250) reply code in response to the extended MAIL
+ command does not constitute an absolute guarantee that the message
+ transfer will succeed. SMTP clients using the extended MAIL command
+ must still be prepared to handle both temporary and permanent error
+ reply codes (including codes 452 and 552), either immediately after
+ issuing the DATA command, or after transfer of the message.
+
+6.3 Messages larger than the declared size.
+
+ Once a server has agreed (via the extended MAIL command) to accept a
+ message of a particular size, it should not return a 552 reply code
+ after the transfer phase of the DATA command, unless the actual size
+ of the message transferred is greater than the declared message size.
+ A server may also choose to accept a message which is somewhat larger
+ than the declared message size.
+
+ A client is permitted to declare a message to be smaller than its
+ actual size. However, in this case, a successful (250) reply code is
+ no assurance that the server will accept the message or has
+ sufficient resources to do so. The server may reject such a message
+ after its DATA transfer.
+
+
+
+Klensin, et al Standards Track [Page 5]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+6.4 Per-recipient rejection based on message size.
+
+ A server that implements this extension may return a 452 or 552 reply
+ code in response to a RCPT command, based on its unwillingness to
+ accept a message of the declared size for a particular recipient.
+
+ (1) If a 452 code is returned, the client may requeue the message for
+ later delivery to the same recipient.
+
+ (2) If a 552 code is returned, the client may not requeue the message
+ for later delivery to the same recipient.
+
+7. Minimal usage
+
+ A "minimal" client may use this extension to simply compare its
+ (perhaps estimated) size of the message that it wishes to relay, with
+ the server's fixed maximum message size (from the parameter to the
+ SIZE keyword in the EHLO response), to determine whether the server
+ will ever accept the message. Such an implementation need not
+ declare message sizes via the extended MAIL command. However,
+ neither will it be able to discover temporary limits on message size
+ due to server resource limitations, nor per-recipient limitations on
+ message size.
+
+ A minimal server that employs this service extension may simply use
+ the SIZE keyword value to inform the client of the size of the
+ largest message it will accept, or to inform the client that there is
+ no fixed limit on message size. Such a server must accept the
+ extended MAIL command and return a 552 reply code if the client's
+ declared size exceeds its fixed size limit (if any), but it need not
+ detect "temporary" limitations on message size.
+
+ The numeric parameter to the EHLO SIZE keyword is optional. If the
+ parameter is omitted entirely it indicates that the server does not
+ advertise a fixed maximum message size. A server that returns the
+ SIZE keyword with no parameter in response to the EHLO command may
+ not issue a positive (250) response to an extended MAIL command
+ containing a SIZE specification without first checking to see if
+ sufficient resources are available to transfer a message of the
+ declared size, and to retain it in stable storage until it can be
+ relayed or delivered to its recipients. If possible, the server
+ should actually reserve sufficient storage space to transfer the
+ message.
+
+
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 6]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+8. Example
+
+ The following example illustrates the use of size declaration with
+ some permanent and temporary failures.
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+ S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
+ C: EHLO ymir.claremont.edu
+ S: 250-sigurd.innosoft.com
+ S: 250-EXPN
+ S: 250-HELP
+ S: 250 SIZE 1000000
+ C: MAIL FROM:<ned@thor.innosoft.com> SIZE=500000
+ S: 250 Address Ok.
+ C: RCPT TO:<ned@innosoft.com>
+ S: 250 ned@innosoft.com OK; can accomodate 500000 byte message
+ C: RCPT TO:<ned@ymir.claremont.edu>
+ S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU
+ C: RCPT TO:<ned@hmcvax.claremont.edu>
+ S: 452 Insufficient channel storage: ned@hmcvax.CLAREMONT.EDU
+ C: DATA
+ S: 354 Send message, ending in CRLF.CRLF.
+ ...
+ C: .
+ S: 250 Some recipients OK
+ C: QUIT
+ S: 221 Goodbye
+
+9. Security Considerations
+
+ The size declaration extensions described in this memo can
+ conceivably be used to facilitate crude service denial attacks.
+ Specifically, both the information contained in the SIZE parameter
+ and use of the extended MAIL command make it somewhat quicker and
+ easier to devise an efficacious service denial attack. However,
+ unless implementations are very weak, these extensions do not create
+ any vulnerability that has not always existed with SMTP. In addition,
+ no issues are addressed involving trusted systems and possible
+ release of information via the mechanisms described in this RFC.
+
+10. Acknowledgements
+
+ This document was derived from an earlier Working Group work in
+ progess contribution. Jim Conklin, Dave Crocker, Neil Katin, Eliot
+ Lear, Marshall T. Rose, and Einar Stefferud provided extensive
+ comments in response to earlier works in progress of both this and
+ the previous memo.
+
+
+
+Klensin, et al Standards Track [Page 7]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+11. References
+
+ [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+ USC/Information Sciences Institute, August 1982.
+
+ [2] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, UDEL, August 1982.
+
+ [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
+ Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
+
+ [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
+ Headers", RFC 1522, University of Tennessee, September 1993.
+
+ [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
+ "SMTP Service Extensions", STD 11, RFC 1869, MCI, Innosoft
+ International, Inc., Dover Beach Consulting, Inc., Network
+ Management Associates, Inc., Brandenburg Consulting, November
+ 1995.
+
+ [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+ 974, BBN, January 1986.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 8]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+12. Chair, Editor, and Author Addresses
+
+ John Klensin, WG Chair
+ MCI
+ 2100 Reston Parkway
+ Reston, VA 22091
+
+ Phone: +1 703 715-7361
+ Fax: +1 703 715-7436
+ EMail: klensin@mci.net
+
+
+ Ned Freed, Editor
+ Innosoft International, Inc.
+ 1050 East Garvey Avenue South
+ West Covina, CA 91790
+ USA
+
+ Phone: +1 818 919 3600
+ Fax: +1 818 919 3614
+ EMail: ned@innosoft.com
+
+
+ Keith Moore
+ Computer Science Dept.
+ University of Tennessee
+ 107 Ayres Hall
+ Knoxville, TN 37996-1301
+ USA
+
+ EMail: moore@cs.utk.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 9]
+
1,291 Documentation/RFC/rfc1939.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group J. Myers
+Request for Comments: 1939 Carnegie Mellon
+STD: 53 M. Rose
+Obsoletes: 1725 Dover Beach Consulting, Inc.
+Category: Standards Track May 1996
+
+
+ Post Office Protocol - Version 3
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Table of Contents
+
+ 1. Introduction ................................................ 2
+ 2. A Short Digression .......................................... 2
+ 3. Basic Operation ............................................. 3
+ 4. The AUTHORIZATION State ..................................... 4
+ QUIT Command ................................................ 5
+ 5. The TRANSACTION State ....................................... 5
+ STAT Command ................................................ 6
+ LIST Command ................................................ 6
+ RETR Command ................................................ 8
+ DELE Command ................................................ 8
+ NOOP Command ................................................ 9
+ RSET Command ................................................ 9
+ 6. The UPDATE State ............................................ 10
+ QUIT Command ................................................ 10
+ 7. Optional POP3 Commands ...................................... 11
+ TOP Command ................................................. 11
+ UIDL Command ................................................ 12
+ USER Command ................................................ 13
+ PASS Command ................................................ 14
+ APOP Command ................................................ 15
+ 8. Scaling and Operational Considerations ...................... 16
+ 9. POP3 Command Summary ........................................ 18
+ 10. Example POP3 Session ....................................... 19
+ 11. Message Format ............................................. 19
+ 12. References ................................................. 20
+ 13. Security Considerations .................................... 20
+ 14. Acknowledgements ........................................... 20
+ 15. Authors' Addresses ......................................... 21
+ Appendix A. Differences from RFC 1725 .......................... 22
+
+
+
+Myers & Rose Standards Track [Page 1]
+
+RFC 1939 POP3 May 1996
+
+
+ Appendix B. Command Index ...................................... 23
+
+1. Introduction
+
+ On certain types of smaller nodes in the Internet it is often
+ impractical to maintain a message transport system (MTS). For
+ example, a workstation may not have sufficient resources (cycles,
+ disk space) in order to permit a SMTP server [RFC821] and associated
+ local mail delivery system to be kept resident and continuously
+ running. Similarly, it may be expensive (or impossible) to keep a
+ personal computer interconnected to an IP-style network for long
+ amounts of time (the node is lacking the resource known as
+ "connectivity").
+
+ Despite this, it is often very useful to be able to manage mail on
+ these smaller nodes, and they often support a user agent (UA) to aid
+ the tasks of mail handling. To solve this problem, a node which can
+ support an MTS entity offers a maildrop service to these less endowed
+ nodes. The Post Office Protocol - Version 3 (POP3) is intended to
+ permit a workstation to dynamically access a maildrop on a server
+ host in a useful fashion. Usually, this means that the POP3 protocol
+ is used to allow a workstation to retrieve mail that the server is
+ holding for it.
+
+ POP3 is not intended to provide extensive manipulation operations of
+ mail on the server; normally, mail is downloaded and then deleted. A
+ more advanced (and complex) protocol, IMAP4, is discussed in
+ [RFC1730].
+
+ For the remainder of this memo, the term "client host" refers to a
+ host making use of the POP3 service, while the term "server host"
+ refers to a host which offers the POP3 service.
+
+2. A Short Digression
+
+ This memo does not specify how a client host enters mail into the
+ transport system, although a method consistent with the philosophy of
+ this memo is presented here:
+
+ When the user agent on a client host wishes to enter a message
+ into the transport system, it establishes an SMTP connection to
+ its relay host and sends all mail to it. This relay host could
+ be, but need not be, the POP3 server host for the client host. Of
+ course, the relay host must accept mail for delivery to arbitrary
+ recipient addresses, that functionality is not required of all
+ SMTP servers.
+
+
+
+
+
+Myers & Rose Standards Track [Page 2]
+
+RFC 1939 POP3 May 1996
+
+
+3. Basic Operation
+
+ Initially, the server host starts the POP3 service by listening on
+ TCP port 110. When a client host wishes to make use of the service,
+ it establishes a TCP connection with the server host. When the
+ connection is established, the POP3 server sends a greeting. The
+ client and POP3 server then exchange commands and responses
+ (respectively) until the connection is closed or aborted.
+
+ Commands in the POP3 consist of a case-insensitive keyword, possibly
+ followed by one or more arguments. All commands are terminated by a
+ CRLF pair. Keywords and arguments consist of printable ASCII
+ characters. Keywords and arguments are each separated by a single
+ SPACE character. Keywords are three or four characters long. Each
+ argument may be up to 40 characters long.
+
+ Responses in the POP3 consist of a status indicator and a keyword
+ possibly followed by additional information. All responses are
+ terminated by a CRLF pair. Responses may be up to 512 characters
+ long, including the terminating CRLF. There are currently two status
+ indicators: positive ("+OK") and negative ("-ERR"). Servers MUST
+ send the "+OK" and "-ERR" in upper case.
+
+ Responses to certain commands are multi-line. In these cases, which
+ are clearly indicated below, after sending the first line of the
+ response and a CRLF, any additional lines are sent, each terminated
+ by a CRLF pair. When all lines of the response have been sent, a
+ final line is sent, consisting of a termination octet (decimal code
+ 046, ".") and a CRLF pair. If any line of the multi-line response
+ begins with the termination octet, the line is "byte-stuffed" by
+ pre-pending the termination octet to that line of the response.
+ Hence a multi-line response is terminated with the five octets
+ "CRLF.CRLF". When examining a multi-line response, the client checks
+ to see if the line begins with the termination octet. If so and if
+ octets other than CRLF follow, the first octet of the line (the
+ termination octet) is stripped away. If so and if CRLF immediately
+ follows the termination character, then the response from the POP
+ server is ended and the line containing ".CRLF" is not considered
+ part of the multi-line response.
+
+ A POP3 session progresses through a number of states during its
+ lifetime. Once the TCP connection has been opened and the POP3
+ server has sent the greeting, the session enters the AUTHORIZATION
+ state. In this state, the client must identify itself to the POP3
+ server. Once the client has successfully done this, the server
+ acquires resources associated with the client's maildrop, and the
+ session enters the TRANSACTION state. In this state, the client
+ requests actions on the part of the POP3 server. When the client has
+
+
+
+Myers & Rose Standards Track [Page 3]
+
+RFC 1939 POP3 May 1996
+
+
+ issued the QUIT command, the session enters the UPDATE state. In
+ this state, the POP3 server releases any resources acquired during
+ the TRANSACTION state and says goodbye. The TCP connection is then
+ closed.
+
+ A server MUST respond to an unrecognized, unimplemented, or
+ syntactically invalid command by responding with a negative status
+ indicator. A server MUST respond to a command issued when the
+ session is in an incorrect state by responding with a negative status
+ indicator. There is no general method for a client to distinguish
+ between a server which does not implement an optional command and a
+ server which is unwilling or unable to process the command.
+
+ A POP3 server MAY have an inactivity autologout timer. Such a timer
+ MUST be of at least 10 minutes' duration. The receipt of any command
+ from the client during that interval should suffice to reset the
+ autologout timer. When the timer expires, the session does NOT enter
+ the UPDATE state--the server should close the TCP connection without
+ removing any messages or sending any response to the client.
+
+4. The AUTHORIZATION State
+
+ Once the TCP connection has been opened by a POP3 client, the POP3
+ server issues a one line greeting. This can be any positive
+ response. An example might be:
+
+ S: +OK POP3 server ready
+
+ The POP3 session is now in the AUTHORIZATION state. The client must
+ now identify and authenticate itself to the POP3 server. Two
+ possible mechanisms for doing this are described in this document,
+ the USER and PASS command combination and the APOP command. Both
+ mechanisms are described later in this document. Additional
+ authentication mechanisms are described in [RFC1734]. While there is
+ no single authentication mechanism that is required of all POP3
+ servers, a POP3 server must of course support at least one
+ authentication mechanism.
+
+ Once the POP3 server has determined through the use of any
+ authentication command that the client should be given access to the
+ appropriate maildrop, the POP3 server then acquires an exclusive-
+ access lock on the maildrop, as necessary to prevent messages from
+ being modified or removed before the session enters the UPDATE state.
+ If the lock is successfully acquired, the POP3 server responds with a
+ positive status indicator. The POP3 session now enters the
+ TRANSACTION state, with no messages marked as deleted. If the
+ maildrop cannot be opened for some reason (for example, a lock can
+ not be acquired, the client is denied access to the appropriate
+
+
+
+Myers & Rose Standards Track [Page 4]
+
+RFC 1939 POP3 May 1996
+
+
+ maildrop, or the maildrop cannot be parsed), the POP3 server responds
+ with a negative status indicator. (If a lock was acquired but the
+ POP3 server intends to respond with a negative status indicator, the
+ POP3 server must release the lock prior to rejecting the command.)
+ After returning a negative status indicator, the server may close the
+ connection. If the server does not close the connection, the client
+ may either issue a new authentication command and start again, or the
+ client may issue the QUIT command.
+
+ After the POP3 server has opened the maildrop, it assigns a message-
+ number to each message, and notes the size of each message in octets.
+ The first message in the maildrop is assigned a message-number of
+ "1", the second is assigned "2", and so on, so that the nth message
+ in a maildrop is assigned a message-number of "n". In POP3 commands
+ and responses, all message-numbers and message sizes are expressed in
+ base-10 (i.e., decimal).
+
+ Here is the summary for the QUIT command when used in the
+ AUTHORIZATION state:
+
+ QUIT
+
+ Arguments: none
+
+ Restrictions: none
+
+ Possible Responses:
+ +OK
+
+ Examples:
+ C: QUIT
+ S: +OK dewey POP3 server signing off
+
+5. The TRANSACTION State
+
+ Once the client has successfully identified itself to the POP3 server
+ and the POP3 server has locked and opened the appropriate maildrop,
+ the POP3 session is now in the TRANSACTION state. The client may now
+ issue any of the following POP3 commands repeatedly. After each
+ command, the POP3 server issues a response. Eventually, the client
+ issues the QUIT command and the POP3 session enters the UPDATE state.
+
+
+
+
+
+
+
+
+
+
+Myers & Rose Standards Track [Page 5]
+
+RFC 1939 POP3 May 1996
+
+
+ Here are the POP3 commands valid in the TRANSACTION state:
+
+ STAT
+
+ Arguments: none
+
+ Restrictions:
+ may only be given in the TRANSACTION state
+
+ Discussion:
+ The POP3 server issues a positive response with a line
+ containing information for the maildrop. This line is
+ called a "drop listing" for that maildrop.
+
+ In order to simplify parsing, all POP3 servers are
+ required to use a certain format for drop listings. The
+ positive response consists of "+OK" followed by a single
+ space, the number of messages in the maildrop, a single
+ space, and the size of the maildrop in octets. This memo
+ makes no requirement on what follows the maildrop size.
+ Minimal implementations should just end that line of the
+ response with a CRLF pair. More advanced implementations
+ may include other information.
+
+ NOTE: This memo STRONGLY discourages implementations
+ from supplying additional information in the drop
+ listing. Other, optional, facilities are discussed
+ later on which permit the client to parse the messages
+ in the maildrop.
+
+ Note that messages marked as deleted are not counted in
+ either total.
+
+ Possible Responses:
+ +OK nn mm
+
+ Examples:
+ C: STAT
+ S: +OK 2 320
+
+
+ LIST [msg]
+
+ Arguments:
+ a message-number (optional), which, if present, may NOT
+ refer to a message marked as deleted
+
+
+
+
+
+Myers & Rose Standards Track [Page 6]
+
+RFC 1939 POP3 May 1996
+
+
+ Restrictions:
+ may only be given in the TRANSACTION state
+
+ Discussion:
+ If an argument was given and the POP3 server issues a
+ positive response with a line containing information for
+ that message. This line is called a "scan listing" for
+ that message.
+
+ If no argument was given and the POP3 server issues a
+ positive response, then the response given is multi-line.
+ After the initial +OK, for each message in the maildrop,
+ the POP3 server responds with a line containing
+ information for that message. This line is also called a
+ "scan listing" for that message. If there are no
+ messages in the maildrop, then the POP3 server responds
+ with no scan listings--it issues a positive response
+ followed by a line containing a termination octet and a
+ CRLF pair.
+
+ In order to simplify parsing, all POP3 servers are
+ required to use a certain format for scan listings. A
+ scan listing consists of the message-number of the
+ message, followed by a single space and the exact size of
+ the message in octets. Methods for calculating the exact
+ size of the message are described in the "Message Format"
+ section below. This memo makes no requirement on what
+ follows the message size in the scan listing. Minimal
+ implementations should just end that line of the response
+ with a CRLF pair. More advanced implementations may
+ include other information, as parsed from the message.
+
+ NOTE: This memo STRONGLY discourages implementations
+ from supplying additional information in the scan
+ listing. Other, optional, facilities are discussed
+ later on which permit the client to parse the messages
+ in the maildrop.
+
+ Note that messages marked as deleted are not listed.
+
+ Possible Responses:
+ +OK scan listing follows
+ -ERR no such message
+
+ Examples:
+ C: LIST
+ S: +OK 2 messages (320 octets)
+ S: 1 120
+
+
+
+Myers & Rose Standards Track [Page 7]
+
+RFC 1939 POP3 May 1996
+
+
+ S: 2 200
+ S: .
+ ...
+ C: LIST 2
+ S: +OK 2 200
+ ...
+ C: LIST 3
+ S: -ERR no such message, only 2 messages in maildrop
+
+
+ RETR msg
+
+ Arguments:
+ a message-number (required) which may NOT refer to a
+ message marked as deleted
+
+ Restrictions:
+ may only be given in the TRANSACTION state
+
+ Discussion:
+ If the POP3 server issues a positive response, then the
+ response given is multi-line. After the initial +OK, the
+ POP3 server sends the message corresponding to the given
+ message-number, being careful to byte-stuff the termination
+ character (as with all multi-line responses).
+
+ Possible Responses:
+ +OK message follows
+ -ERR no such message
+
+ Examples:
+ C: RETR 1
+ S: +OK 120 octets
+ S: <the POP3 server sends the entire message here>
+ S: .
+
+
+ DELE msg
+
+ Arguments:
+ a message-number (required) which may NOT refer to a
+ message marked as deleted
+
+ Restrictions:
+ may only be given in the TRANSACTION state
+
+
+
+
+
+
+Myers & Rose Standards Track [Page 8]
+
+RFC 1939 POP3 May 1996
+
+
+ Discussion:
+ The POP3 server marks the message as deleted. Any future
+ reference to the message-number associated with the message
+ in a POP3 command generates an error. The POP3 server does
+ not actually delete the message until the POP3 session
+ enters the UPDATE state.
+
+ Possible Responses:
+ +OK message deleted
+ -ERR no such message
+
+ Examples:
+ C: DELE 1
+ S: +OK message 1 deleted
+ ...
+ C: DELE 2
+ S: -ERR message 2 already deleted
+
+
+ NOOP
+
+ Arguments: none
+
+ Restrictions:
+ may only be given in the TRANSACTION state
+
+ Discussion:
+ The POP3 server does nothing, it merely replies with a
+ positive response.
+
+ Possible Responses:
+ +OK
+
+ Examples:
+ C: NOOP
+ S: +OK
+
+
+ RSET
+
+ Arguments: none
+
+ Restrictions:
+ may only be given in the TRANSACTION state
+
+ Discussion:
+ If any messages have been marked as deleted by the POP3
+ server, they are unmarked. The POP3 server then replies
+
+
+
+Myers & Rose Standards Track [Page 9]
+
+RFC 1939 POP3 May 1996
+
+
+ with a positive response.
+
+ Possible Responses:
+ +OK
+
+ Examples:
+ C: RSET
+ S: +OK maildrop has 2 messages (320 octets)
+
+6. The UPDATE State
+
+ When the client issues the QUIT command from the TRANSACTION state,
+ the POP3 session enters the UPDATE state. (Note that if the client
+ issues the QUIT command from the AUTHORIZATION state, the POP3
+ session terminates but does NOT enter the UPDATE state.)
+
+ If a session terminates for some reason other than a client-issued
+ QUIT command, the POP3 session does NOT enter the UPDATE state and
+ MUST not remove any messages from the maildrop.
+
+ QUIT
+
+ Arguments: none
+
+ Restrictions: none
+
+ Discussion:
+ The POP3 server removes all messages marked as deleted
+ from the maildrop and replies as to the status of this
+ operation. If there is an error, such as a resource
+ shortage, encountered while removing messages, the
+ maildrop may result in having some or none of the messages
+ marked as deleted be removed. In no case may the server
+ remove any messages not marked as deleted.
+
+ Whether the removal was successful or not, the server
+ then releases any exclusive-access lock on the maildrop
+ and closes the TCP connection.
+
+ Possible Responses:
+ +OK
+ -ERR some deleted messages not removed
+
+ Examples:
+ C: QUIT
+ S: +OK dewey POP3 server signing off (maildrop empty)
+ ...
+ C: QUIT
+
+
+
+Myers & Rose Standards Track [Page 10]
+
+RFC 1939 POP3 May 1996
+
+
+ S: +OK dewey POP3 server signing off (2 messages left)
+ ...
+
+7. Optional POP3 Commands
+
+ The POP3 commands discussed above must be supported by all minimal
+ implementations of POP3 servers.
+
+ The optional POP3 commands described below permit a POP3 client
+ greater freedom in message handling, while preserving a simple POP3
+ server implementation.
+
+ NOTE: This memo STRONGLY encourages implementations to support
+ these commands in lieu of developing augmented drop and scan
+ listings. In short, the philosophy of this memo is to put
+ intelligence in the part of the POP3 client and not the POP3
+ server.
+
+ TOP msg n
+
+ Arguments:
+ a message-number (required) which may NOT refer to to a
+ message marked as deleted, and a non-negative number
+ of lines (required)
+
+ Restrictions:
+ may only be given in the TRANSACTION state
+
+ Discussion:
+ If the POP3 server issues a positive response, then the
+ response given is multi-line. After the initial +OK, the
+ POP3 server sends the headers of the message, the blank
+ line separating the headers from the body, and then the
+ number of lines of the indicated message's body, being
+ careful to byte-stuff the termination character (as with
+ all multi-line responses).
+
+ Note that if the number of lines requested by the POP3
+ client is greater than than the number of lines in the
+ body, then the POP3 server sends the entire message.
+
+ Possible Responses:
+ +OK top of message follows
+ -ERR no such message
+
+ Examples:
+ C: TOP 1 10
+ S: +OK
+
+
+
+Myers & Rose Standards Track [Page 11]
+
+RFC 1939 POP3 May 1996
+
+
+ S: <the POP3 server sends the headers of the
+ message, a blank line, and the first 10 lines
+ of the body of the message>
+ S: .
+ ...
+ C: TOP 100 3
+ S: -ERR no such message
+
+
+ UIDL [msg]
+
+ Arguments:
+ a message-number (optional), which, if present, may NOT
+ refer to a message marked as deleted
+
+ Restrictions:
+ may only be given in the TRANSACTION state.
+
+ Discussion:
+ If an argument was given and the POP3 server issues a positive
+ response with a line containing information for that message.
+ This line is called a "unique-id listing" for that message.
+
+ If no argument was given and the POP3 server issues a positive
+ response, then the response given is multi-line. After the
+ initial +OK, for each message in the maildrop, the POP3 server
+ responds with a line containing information for that message.
+ This line is called a "unique-id listing" for that message.
+
+ In order to simplify parsing, all POP3 servers are required to
+ use a certain format for unique-id listings. A unique-id
+ listing consists of the message-number of the message,
+ followed by a single space and the unique-id of the message.
+ No information follows the unique-id in the unique-id listing.
+
+ The unique-id of a message is an arbitrary server-determined
+ string, consisting of one to 70 characters in the range 0x21
+ to 0x7E, which uniquely identifies a message within a
+ maildrop and which persists across sessions. This
+ persistence is required even if a session ends without
+ entering the UPDATE state. The server should never reuse an
+ unique-id in a given maildrop, for as long as the entity
+ using the unique-id exists.
+
+ Note that messages marked as deleted are not listed.
+
+ While it is generally preferable for server implementations
+ to store arbitrarily assigned unique-ids in the maildrop,
+
+
+
+Myers & Rose Standards Track [Page 12]
+
+RFC 1939 POP3 May 1996
+
+
+ this specification is intended to permit unique-ids to be
+ calculated as a hash of the message. Clients should be able
+ to handle a situation where two identical copies of a
+ message in a maildrop have the same unique-id.
+
+ Possible Responses:
+ +OK unique-id listing follows
+ -ERR no such message
+
+ Examples:
+ C: UIDL
+ S: +OK
+ S: 1 whqtswO00WBw418f9t5JxYwZ
+ S: 2 QhdPYR:00WBw1Ph7x7
+ S: .
+ ...
+ C: UIDL 2
+ S: +OK 2 QhdPYR:00WBw1Ph7x7
+ ...
+ C: UIDL 3
+ S: -ERR no such message, only 2 messages in maildrop
+
+
+ USER name
+
+ Arguments:
+ a string identifying a mailbox (required), which is of
+ significance ONLY to the server
+
+ Restrictions:
+ may only be given in the AUTHORIZATION state after the POP3
+ greeting or after an unsuccessful USER or PASS command
+
+ Discussion:
+ To authenticate using the USER and PASS command
+ combination, the client must first issue the USER
+ command. If the POP3 server responds with a positive
+ status indicator ("+OK"), then the client may issue
+ either the PASS command to complete the authentication,
+ or the QUIT command to terminate the POP3 session. If
+ the POP3 server responds with a negative status indicator
+ ("-ERR") to the USER command, then the client may either
+ issue a new authentication command or may issue the QUIT
+ command.
+
+ The server may return a positive response even though no
+ such mailbox exists. The server may return a negative
+ response if mailbox exists, but does not permit plaintext
+
+
+
+Myers & Rose Standards Track [Page 13]
+
+RFC 1939 POP3 May 1996
+
+
+ password authentication.
+
+ Possible Responses:
+ +OK name is a valid mailbox
+ -ERR never heard of mailbox name
+
+ Examples:
+ C: USER frated
+ S: -ERR sorry, no mailbox for frated here
+ ...
+ C: USER mrose
+ S: +OK mrose is a real hoopy frood
+
+
+ PASS string
+
+ Arguments:
+ a server/mailbox-specific password (required)
+
+ Restrictions:
+ may only be given in the AUTHORIZATION state immediately
+ after a successful USER command
+
+ Discussion:
+ When the client issues the PASS command, the POP3 server
+ uses the argument pair from the USER and PASS commands to
+ determine if the client should be given access to the
+ appropriate maildrop.
+
+ Since the PASS command has exactly one argument, a POP3
+ server may treat spaces in the argument as part of the
+ password, instead of as argument separators.
+
+ Possible Responses:
+ +OK maildrop locked and ready
+ -ERR invalid password
+ -ERR unable to lock maildrop
+
+ Examples:
+ C: USER mrose
+ S: +OK mrose is a real hoopy frood
+ C: PASS secret
+ S: -ERR maildrop already locked
+ ...
+ C: USER mrose
+ S: +OK mrose is a real hoopy frood
+ C: PASS secret
+ S: +OK mrose's maildrop has 2 messages (320 octets)
+
+
+
+Myers & Rose Standards Track [Page 14]
+
+RFC 1939 POP3 May 1996
+
+
+ APOP name digest
+
+ Arguments:
+ a string identifying a mailbox and a MD5 digest string
+ (both required)
+
+ Restrictions:
+ may only be given in the AUTHORIZATION state after the POP3
+ greeting or after an unsuccessful USER or PASS command
+
+ Discussion:
+ Normally, each POP3 session starts with a USER/PASS
+ exchange. This results in a server/user-id specific
+ password being sent in the clear on the network. For
+ intermittent use of POP3, this may not introduce a sizable
+ risk. However, many POP3 client implementations connect to
+ the POP3 server on a regular basis -- to check for new
+ mail. Further the interval of session initiation may be on
+ the order of five minutes. Hence, the risk of password
+ capture is greatly enhanced.
+
+ An alternate method of authentication is required which
+ provides for both origin authentication and replay
+ protection, but which does not involve sending a password
+ in the clear over the network. The APOP command provides
+ this functionality.
+
+ A POP3 server which implements the APOP command will
+ include a timestamp in its banner greeting. The syntax of
+ the timestamp corresponds to the `msg-id' in [RFC822], and
+ MUST be different each time the POP3 server issues a banner
+ greeting. For example, on a UNIX implementation in which a
+ separate UNIX process is used for each instance of a POP3
+ server, the syntax of the timestamp might be:
+
+ <process-ID.clock@hostname>
+
+ where `process-ID' is the decimal value of the process's
+ PID, clock is the decimal value of the system clock, and
+ hostname is the fully-qualified domain-name corresponding
+ to the host where the POP3 server is running.
+
+ The POP3 client makes note of this timestamp, and then
+ issues the APOP command. The `name' parameter has
+ identical semantics to the `name' parameter of the USER
+ command. The `digest' parameter is calculated by applying
+ the MD5 algorithm [RFC1321] to a string consisting of the
+ timestamp (including angle-brackets) followed by a shared
+
+
+
+Myers & Rose Standards Track [Page 15]
+
+RFC 1939 POP3 May 1996
+
+
+ secret. This shared secret is a string known only to the
+ POP3 client and server. Great care should be taken to
+ prevent unauthorized disclosure of the secret, as knowledge
+ of the secret will allow any entity to successfully
+ masquerade as the named user. The `digest' parameter
+ itself is a 16-octet value which is sent in hexadecimal
+ format, using lower-case ASCII characters.
+
+ When the POP3 server receives the APOP command, it verifies
+ the digest provided. If the digest is correct, the POP3
+ server issues a positive response, and the POP3 session
+ enters the TRANSACTION state. Otherwise, a negative
+ response is issued and the POP3 session remains in the
+ AUTHORIZATION state.
+
+ Note that as the length of the shared secret increases, so
+ does the difficulty of deriving it. As such, shared
+ secrets should be long strings (considerably longer than
+ the 8-character example shown below).
+
+ Possible Responses:
+ +OK maildrop locked and ready
+ -ERR permission denied
+
+ Examples:
+ S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
+ C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
+ S: +OK maildrop has 1 message (369 octets)
+
+ In this example, the shared secret is the string `tan-
+ staaf'. Hence, the MD5 algorithm is applied to the string
+
+ <1896.697170952@dbc.mtview.ca.us>tanstaaf
+
+ which produces a digest value of
+
+ c4c9334bac560ecc979e58001b3e22fb
+
+8. Scaling and Operational Considerations
+
+ Since some of the optional features described above were added to the
+ POP3 protocol, experience has accumulated in using them in large-
+ scale commercial post office operations where most of the users are
+ unrelated to each other. In these situations and others, users and
+ vendors of POP3 clients have discovered that the combination of using
+ the UIDL command and not issuing the DELE command can provide a weak
+ version of the "maildrop as semi-permanent repository" functionality
+ normally associated with IMAP. Of course the other capabilities of
+
+
+
+Myers & Rose Standards Track [Page 16]
+
+RFC 1939 POP3 May 1996
+
+
+ IMAP, such as polling an existing connection for newly arrived
+ messages and supporting multiple folders on the server, are not
+ present in POP3.
+
+ When these facilities are used in this way by casual users, there has
+ been a tendency for already-read messages to accumulate on the server
+ without bound. This is clearly an undesirable behavior pattern from
+ the standpoint of the server operator. This situation is aggravated
+ by the fact that the limited capabilities of the POP3 do not permit
+ efficient handling of maildrops which have hundreds or thousands of
+ messages.
+
+ Consequently, it is recommended that operators of large-scale multi-
+ user servers, especially ones in which the user's only access to the
+ maildrop is via POP3, consider such options as:
+
+ * Imposing a per-user maildrop storage quota or the like.
+
+ A disadvantage to this option is that accumulation of messages may
+ result in the user's inability to receive new ones into the
+ maildrop. Sites which choose this option should be sure to inform
+ users of impending or current exhaustion of quota, perhaps by
+ inserting an appropriate message into the user's maildrop.
+
+ * Enforce a site policy regarding mail retention on the server.
+
+ Sites are free to establish local policy regarding the storage and
+ retention of messages on the server, both read and unread. For
+ example, a site might delete unread messages from the server after
+ 60 days and delete read messages after 7 days. Such message
+ deletions are outside the scope of the POP3 protocol and are not
+ considered a protocol violation.
+
+ Server operators enforcing message deletion policies should take
+ care to make all users aware of the policies in force.
+
+ Clients must not assume that a site policy will automate message
+ deletions, and should continue to explicitly delete messages using
+ the DELE command when appropriate.
+
+ It should be noted that enforcing site message deletion policies
+ may be confusing to the user community, since their POP3 client
+ may contain configuration options to leave mail on the server
+ which will not in fact be supported by the server.
+
+ One special case of a site policy is that messages may only be
+ downloaded once from the server, and are deleted after this has
+ been accomplished. This could be implemented in POP3 server
+
+
+
+Myers & Rose Standards Track [Page 17]
+
+RFC 1939 POP3 May 1996
+
+
+ software by the following mechanism: "following a POP3 login by a
+ client which was ended by a QUIT, delete all messages downloaded
+ during the session with the RETR command". It is important not to
+ delete messages in the event of abnormal connection termination
+ (ie, if no QUIT was received from the client) because the client
+ may not have successfully received or stored the messages.
+ Servers implementing a download-and-delete policy may also wish to
+ disable or limit the optional TOP command, since it could be used
+ as an alternate mechanism to download entire messages.
+
+9. POP3 Command Summary
+
+ Minimal POP3 Commands:
+
+ USER name valid in the AUTHORIZATION state
+ PASS string
+ QUIT
+
+ STAT valid in the TRANSACTION state
+ LIST [msg]
+ RETR msg
+ DELE msg
+ NOOP
+ RSET
+ QUIT
+
+ Optional POP3 Commands:
+
+ APOP name digest valid in the AUTHORIZATION state
+
+ TOP msg n valid in the TRANSACTION state
+ UIDL [msg]
+
+ POP3 Replies:
+
+ +OK
+ -ERR
+
+ Note that with the exception of the STAT, LIST, and UIDL commands,
+ the reply given by the POP3 server to any command is significant
+ only to "+OK" and "-ERR". Any text occurring after this reply
+ may be ignored by the client.
+
+
+
+
+
+
+
+
+
+Myers & Rose Standards Track [Page 18]
+
+RFC 1939 POP3 May 1996
+
+
+10. Example POP3 Session
+
+ S: <wait for connection on TCP port 110>
+ C: <open connection>
+ S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
+ C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
+ S: +OK mrose's maildrop has 2 messages (320 octets)
+ C: STAT
+ S: +OK 2 320
+ C: LIST
+ S: +OK 2 messages (320 octets)
+ S: 1 120
+ S: 2 200
+ S: .
+ C: RETR 1
+ S: +OK 120 octets
+ S: <the POP3 server sends message 1>
+ S: .
+ C: DELE 1
+ S: +OK message 1 deleted
+ C: RETR 2
+ S: +OK 200 octets
+ S: <the POP3 server sends message 2>
+ S: .
+ C: DELE 2
+ S: +OK message 2 deleted
+ C: QUIT
+ S: +OK dewey POP3 server signing off (maildrop empty)
+ C: <close connection>
+ S: <wait for next connection>
+
+11. Message Format
+
+ All messages transmitted during a POP3 session are assumed to conform
+ to the standard for the format of Internet text messages [RFC822].
+
+ It is important to note that the octet count for a message on the
+ server host may differ from the octet count assigned to that message
+ due to local conventions for designating end-of-line. Usually,
+ during the AUTHORIZATION state of the POP3 session, the POP3 server
+ can calculate the size of each message in octets when it opens the
+ maildrop. For example, if the POP3 server host internally represents
+ end-of-line as a single character, then the POP3 server simply counts
+ each occurrence of this character in a message as two octets. Note
+ that lines in the message which start with the termination octet need
+ not (and must not) be counted twice, since the POP3 client will
+ remove all byte-stuffed termination characters when it receives a
+ multi-line response.
+
+
+
+Myers & Rose Standards Track [Page 19]
+
+RFC 1939 POP3 May 1996
+
+
+12. References
+
+ [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+ 821, USC/Information Sciences Institute, August 1982.
+
+ [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text
+ Messages", STD 11, RFC 822, University of Delaware, August 1982.
+
+ [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+ MIT Laboratory for Computer Science, April 1992.
+
+ [RFC1730] Crispin, M., "Internet Message Access Protocol - Version
+ 4", RFC 1730, University of Washington, December 1994.
+
+ [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,
+ Carnegie Mellon, December 1994.
+
+13. Security Considerations
+
+ It is conjectured that use of the APOP command provides origin
+ identification and replay protection for a POP3 session.
+ Accordingly, a POP3 server which implements both the PASS and APOP
+ commands should not allow both methods of access for a given user;
+ that is, for a given mailbox name, either the USER/PASS command
+ sequence or the APOP command is allowed, but not both.
+
+ Further, note that as the length of the shared secret increases, so
+ does the difficulty of deriving it.
+
+ Servers that answer -ERR to the USER command are giving potential
+ attackers clues about which names are valid.
+
+ Use of the PASS command sends passwords in the clear over the
+ network.
+
+ Use of the RETR and TOP commands sends mail in the clear over the
+ network.
+
+ Otherwise, security issues are not discussed in this memo.
+
+14. Acknowledgements
+
+ The POP family has a long and checkered history. Although primarily
+ a minor revision to RFC 1460, POP3 is based on the ideas presented in
+ RFCs 918, 937, and 1081.
+
+ In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff
+ provided significant comments on the APOP command.
+
+
+
+Myers & Rose Standards Track [Page 20]
+
+RFC 1939 POP3 May 1996
+
+
+15. Authors' Addresses
+
+ John G. Myers
+ Carnegie-Mellon University
+ 5000 Forbes Ave
+ Pittsburgh, PA 15213
+
+ EMail: jgm+@cmu.edu
+
+
+ Marshall T. Rose
+ Dover Beach Consulting, Inc.
+ 420 Whisman Court
+ Mountain View, CA 94043-2186
+
+ EMail: mrose@dbc.mtview.ca.us
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers & Rose Standards Track [Page 21]
+
+RFC 1939 POP3 May 1996
+
+
+Appendix A. Differences from RFC 1725
+
+ This memo is a revision to RFC 1725, a Draft Standard. It makes the
+ following changes from that document:
+
+ - clarifies that command keywords are case insensitive.
+
+ - specifies that servers must send "+OK" and "-ERR" in
+ upper case.
+
+ - specifies that the initial greeting is a positive response,
+ instead of any string which should be a positive response.
+
+ - clarifies behavior for unimplemented commands.
+
+ - makes the USER and PASS commands optional.
+
+ - clarified the set of possible responses to the USER command.
+
+ - reverses the order of the examples in the USER and PASS
+ commands, to reduce confusion.
+
+ - clarifies that the PASS command may only be given immediately
+ after a successful USER command.
+
+ - clarified the persistence requirements of UIDs and added some
+ implementation notes.
+
+ - specifies a UID length limitation of one to 70 octets.
+
+ - specifies a status indicator length limitation
+ of 512 octets, including the CRLF.
+
+ - clarifies that LIST with no arguments on an empty mailbox
+ returns success.
+
+ - adds a reference from the LIST command to the Message Format
+ section
+
+ - clarifies the behavior of QUIT upon failure
+
+ - clarifies the security section to not imply the use of the
+ USER command with the APOP command.
+
+ - adds references to RFCs 1730 and 1734
+
+ - clarifies the method by which a UA may enter mail into the
+ transport system.
+
+
+
+Myers & Rose Standards Track [Page 22]
+
+RFC 1939 POP3 May 1996
+
+
+ - clarifies that the second argument to the TOP command is a
+ number of lines.
+
+ - changes the suggestion in the Security Considerations section
+ for a server to not accept both PASS and APOP for a given user
+ from a "must" to a "should".
+
+ - adds a section on scaling and operational considerations
+
+Appendix B. Command Index
+
+ APOP ....................................................... 15
+ DELE ....................................................... 8
+ LIST ....................................................... 6
+ NOOP ....................................................... 9
+ PASS ....................................................... 14
+ QUIT ....................................................... 5
+ QUIT ....................................................... 10
+ RETR ....................................................... 8
+ RSET ....................................................... 9
+ STAT ....................................................... 6
+ TOP ........................................................ 11
+ UIDL ....................................................... 12
+ USER ....................................................... 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers & Rose Standards Track [Page 23]
+
1,739 Documentation/RFC/rfc2045.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group N. Freed
+Request for Comments: 2045 Innosoft
+Obsoletes: 1521, 1522, 1590 N. Borenstein
+Category: Standards Track First Virtual
+ November 1996
+
+
+ Multipurpose Internet Mail Extensions
+ (MIME) Part One:
+ Format of Internet Message Bodies
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ STD 11, RFC 822, defines a message representation protocol specifying
+ considerable detail about US-ASCII message headers, and leaves the
+ message content, or message body, as flat US-ASCII text. This set of
+ documents, collectively called the Multipurpose Internet Mail
+ Extensions, or MIME, redefines the format of messages to allow for
+
+ (1) textual message bodies in character sets other than
+ US-ASCII,
+
+ (2) an extensible set of different formats for non-textual
+ message bodies,
+
+ (3) multi-part message bodies, and
+
+ (4) textual header information in character sets other than
+ US-ASCII.
+
+ These documents are based on earlier work documented in RFC 934, STD
+ 11, and RFC 1049, but extends and revises them. Because RFC 822 said
+ so little about message bodies, these documents are largely
+ orthogonal to (rather than a revision of) RFC 822.
+
+ This initial document specifies the various headers used to describe
+ the structure of MIME messages. The second document, RFC 2046,
+ defines the general structure of the MIME media typing system and
+ defines an initial set of media types. The third document, RFC 2047,
+ describes extensions to RFC 822 to allow non-US-ASCII text data in
+
+
+
+Freed & Borenstein Standards Track [Page 1]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ Internet mail header fields. The fourth document, RFC 2048, specifies
+ various IANA registration procedures for MIME-related facilities. The
+ fifth and final document, RFC 2049, describes MIME conformance
+ criteria as well as providing some illustrative examples of MIME
+ message formats, acknowledgements, and the bibliography.
+
+ These documents are revisions of RFCs 1521, 1522, and 1590, which
+ themselves were revisions of RFCs 1341 and 1342. An appendix in RFC
+ 2049 describes differences and changes from previous versions.
+
+Table of Contents
+
+ 1. Introduction ......................................... 3
+ 2. Definitions, Conventions, and Generic BNF Grammar .... 5
+ 2.1 CRLF ................................................ 5
+ 2.2 Character Set ....................................... 6
+ 2.3 Message ............................................. 6
+ 2.4 Entity .............................................. 6
+ 2.5 Body Part ........................................... 7
+ 2.6 Body ................................................ 7
+ 2.7 7bit Data ........................................... 7
+ 2.8 8bit Data ........................................... 7
+ 2.9 Binary Data ......................................... 7
+ 2.10 Lines .............................................. 7
+ 3. MIME Header Fields ................................... 8
+ 4. MIME-Version Header Field ............................ 8
+ 5. Content-Type Header Field ............................ 10
+ 5.1 Syntax of the Content-Type Header Field ............. 12
+ 5.2 Content-Type Defaults ............................... 14
+ 6. Content-Transfer-Encoding Header Field ............... 14
+ 6.1 Content-Transfer-Encoding Syntax .................... 14
+ 6.2 Content-Transfer-Encodings Semantics ................ 15
+ 6.3 New Content-Transfer-Encodings ...................... 16
+ 6.4 Interpretation and Use .............................. 16
+ 6.5 Translating Encodings ............................... 18
+ 6.6 Canonical Encoding Model ............................ 19
+ 6.7 Quoted-Printable Content-Transfer-Encoding .......... 19
+ 6.8 Base64 Content-Transfer-Encoding .................... 24
+ 7. Content-ID Header Field .............................. 26
+ 8. Content-Description Header Field ..................... 27
+ 9. Additional MIME Header Fields ........................ 27
+ 10. Summary ............................................. 27
+ 11. Security Considerations ............................. 27
+ 12. Authors' Addresses .................................. 28
+ A. Collected Grammar .................................... 29
+
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 2]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+1. Introduction
+
+ Since its publication in 1982, RFC 822 has defined the standard
+ format of textual mail messages on the Internet. Its success has
+ been such that the RFC 822 format has been adopted, wholly or
+ partially, well beyond the confines of the Internet and the Internet
+ SMTP transport defined by RFC 821. As the format has seen wider use,
+ a number of limitations have proven increasingly restrictive for the
+ user community.
+
+ RFC 822 was intended to specify a format for text messages. As such,
+ non-text messages, such as multimedia messages that might include
+ audio or images, are simply not mentioned. Even in the case of text,
+ however, RFC 822 is inadequate for the needs of mail users whose
+ languages require the use of character sets richer than US-ASCII.
+ Since RFC 822 does not specify mechanisms for mail containing audio,
+ video, Asian language text, or even text in most European languages,
+ additional specifications are needed.
+