From d78b61e3efaea197a6e5b2b72bf2981a9ed69461 Mon Sep 17 00:00:00 2001 From: Rob Funk Date: Tue, 8 Jun 2004 03:59:01 +0000 Subject: Add files from ESR's dev directory that weren't under version control svn path=/trunk/; revision=3881 --- .cvsignore | 8 + ABOUT-NLS | 226 ++ CHANGES | 4 + FetchmailOfSatan.gif | Bin 0 -> 1845 bytes OPTIONS | 77 + README.NTLM | 83 + README.SSL | 92 + RELEASE-INSTRUCTIONS | 10 + RFC/draft-klensin-cram-03.txt | 261 ++ RFC/draft-newman-tls-imappop-05.txt | 618 ++++ RFC/lan-mail-protocols | 1330 ++++++++ RFC/rfc1081.txt | 899 ++++++ RFC/rfc1123.txt | 5782 +++++++++++++++++++++++++++++++++++ RFC/rfc1176.txt | 1683 ++++++++++ RFC/rfc1203.txt | 2747 +++++++++++++++++ RFC/rfc1225.txt | 899 ++++++ RFC/rfc1460.txt | 955 ++++++ RFC/rfc1521.txt | 4539 +++++++++++++++++++++++++++ RFC/rfc1725.txt | 1011 ++++++ RFC/rfc1730.txt | 4318 ++++++++++++++++++++++++++ RFC/rfc1731.txt | 339 ++ RFC/rfc1732.txt | 283 ++ RFC/rfc1734.txt | 283 ++ RFC/rfc1870.txt | 507 +++ RFC/rfc1891.txt | 1739 +++++++++++ RFC/rfc1892.txt | 227 ++ RFC/rfc1893.txt | 843 +++++ RFC/rfc1894.txt | 2187 +++++++++++++ RFC/rfc1938.txt | 1011 ++++++ RFC/rfc1939.txt | 1291 ++++++++ RFC/rfc1985.txt | 395 +++ RFC/rfc2033.txt | 395 +++ RFC/rfc2060.txt | 4595 ++++++++++++++++++++++++++++ RFC/rfc2061.txt | 171 ++ RFC/rfc2062.txt | 451 +++ RFC/rfc2177.txt | 227 ++ RFC/rfc2195.txt | 283 ++ RFC/rfc2449.txt | 1067 +++++++ RFC/rfc2554.txt | 619 ++++ RFC/rfc2645.txt | 507 +++ RFC/rfc2683.txt | 1291 ++++++++ RFC/rfc821.txt | 4050 ++++++++++++++++++++++++ RFC/rfc822.txt | 2901 ++++++++++++++++++ RFC/rfc937.txt | 1392 +++++++++ RFC/rfc977.txt | 1539 ++++++++++ beos/beos_nameser.h | 597 ++++ beos/beos_nameser_compat.h | 229 ++ bighand.png | Bin 0 -> 2408 bytes config.sub | 1268 ++++++++ contrib/README | 179 ++ contrib/README.getmail | 64 + contrib/debian_rc | 40 + contrib/domino | 84 + contrib/fetchmail-mode.el | 142 + contrib/fetchmaildistrib | 29 + contrib/fetchmailnochda.pl | 131 + contrib/fetchspool | 58 + contrib/getfetchmail | 31 + contrib/getfetchmail.pl | 61 + contrib/getmail | 73 + contrib/gotmail | 69 + contrib/gotmail.awk | 62 + contrib/gotmail.conf | 25 + contrib/gotmail.html.awk | 99 + contrib/ip-up | 70 + contrib/login | 16 + contrib/logout | 30 + contrib/maildaemon | 75 + contrib/mailqueue.pl | 420 +++ contrib/mold_remover.py | 92 + contrib/multidrop | 236 ++ contrib/novell | 57 + contrib/poptest | 84 + contrib/preauth-harness | 53 + contrib/redhat_rc | 60 + contrib/runfetchmail | 182 ++ contrib/sm-hybrid | 539 ++++ contrib/start_dynamic_ppp | 16 + contrib/toprocmail | 46 + contrib/zsh-completion | 20 + fetchmail.png | Bin 0 -> 1973 bytes fetchmail.ppm | Bin 0 -> 7213 bytes fetchmail.xpm | 302 ++ getopt.h | 129 + gettext.m4 | 329 ++ install-sh | 276 ++ intl/ChangeLog | 1086 +++++++ intl/Makefile.in | 216 ++ intl/VERSION | 1 + intl/bindtextdom.c | 203 ++ intl/cat-compat.c | 262 ++ intl/dcgettext.c | 624 ++++ intl/dgettext.c | 59 + intl/explodename.c | 188 ++ intl/finddomain.c | 216 ++ intl/gettext.c | 70 + intl/gettext.h | 105 + intl/gettextP.h | 89 + intl/hash-string.h | 59 + intl/intl-compat.c | 76 + intl/l10nflist.c | 411 +++ intl/libgettext.h | 182 ++ intl/linux-msg.sed | 100 + intl/loadinfo.h | 76 + intl/loadmsgcat.c | 222 ++ intl/localealias.c | 424 +++ intl/po2tbl.sed.in | 102 + intl/textdomain.c | 108 + intl/xopen-msg.sed | 104 + kerberos.h | 33 + lcmessage.m4 | 22 + libntlm-0.21/COPYING | 339 ++ libntlm-0.21/HISTORY | 21 + libntlm-0.21/Makefile | 42 + libntlm-0.21/README | 98 + libntlm-0.21/ntlm.h | 68 + libntlm-0.21/smb.h | 52 + libntlm-0.21/smbbyteorder.h | 265 ++ libntlm-0.21/smbdes.c | 399 +++ libntlm-0.21/smbdes.h | 9 + libntlm-0.21/smbencrypt.c | 323 ++ libntlm-0.21/smbencrypt.h | 2 + libntlm-0.21/smbmd4.c | 172 ++ libntlm-0.21/smbmd4.h | 1 + libntlm-0.21/smbutil.c | 218 ++ libntlm-0.21/test/COPYING | 339 ++ libntlm-0.21/test/Makefile | 6 + libntlm-0.21/test/README | 19 + libntlm-0.21/test/dumper.c | 237 ++ libntlm-0.21/test/getargs.c | 240 ++ libntlm-0.21/test/getargs.h | 19 + memmove.c | 22 + mime64/Makefile | 14 + mime64/README | 81 + mime64/mime.txt | 831 +++++ mime64/mime64.c | 795 +++++ missing | 336 ++ mkinstalldirs | 40 + po/.cvsignore | 3 + po/.pot | 1885 ++++++++++++ po/Makefile.in.in | 251 ++ po/POTFILES.in | 30 + po/ca.gmo | Bin 0 -> 63149 bytes po/ca.po | 2890 +++++++++++++++++ po/cat-id-tbl.c | 0 po/cs.gmo | Bin 0 -> 47931 bytes po/cs.po | 2862 +++++++++++++++++ po/da.gmo | Bin 0 -> 59512 bytes po/da.po | 2821 +++++++++++++++++ po/de.gmo | Bin 0 -> 62860 bytes po/de.po | 2869 +++++++++++++++++ po/el.gmo | Bin 0 -> 62600 bytes po/el.po | 2849 +++++++++++++++++ po/es.gmo | Bin 0 -> 63206 bytes po/es.po | 2901 ++++++++++++++++++ po/fetchmail.diff | 2877 +++++++++++++++++ po/fetchmail.pot | 2744 +++++++++++++++++ po/fr.gmo | Bin 0 -> 61194 bytes po/fr.po | 2915 ++++++++++++++++++ po/fr.po.orig | 2915 ++++++++++++++++++ po/fr.po.rej | 116 + po/gl.gmo | Bin 0 -> 41443 bytes po/gl.po | 2912 ++++++++++++++++++ po/ja.gmo | Bin 0 -> 58746 bytes po/ja.po | 2883 +++++++++++++++++ po/pl.gmo | Bin 0 -> 36379 bytes po/pl.po | 2858 +++++++++++++++++ po/pl.po.orig | 3005 ++++++++++++++++++ po/pl.po.rej | 610 ++++ po/pt_BR.gmo | Bin 0 -> 41601 bytes po/pt_BR.po | 2951 ++++++++++++++++++ po/sk.gmo | Bin 0 -> 42025 bytes po/sk.po | 2825 +++++++++++++++++ po/stamp-cat-id | 1 + po/tr.gmo | Bin 0 -> 60495 bytes po/tr.po | 2932 ++++++++++++++++++ progtest.m4 | 47 + rh-config/fetchmailconf.init | 5 + rh-config/fetchmailconf.wmconfig | 4 + rh-config/fetchmailconf.xpm | 163 + smb.h | 52 + smbbyteorder.h | 265 ++ smbdes.c | 399 +++ smbdes.h | 9 + smbencrypt.c | 325 ++ smbencrypt.h | 2 + smbmd4.c | 173 ++ smbmd4.h | 1 + smbutil.c | 219 ++ test-request | 20 + testmail | 10 + testmda | 10 + testrc | 14 + testservers.html | 64 + timeplot | 40 + torturetest.gladep | 7 + uploadfaq | 24 + 197 files changed, 124192 insertions(+) create mode 100644 .cvsignore create mode 100644 ABOUT-NLS create mode 100644 CHANGES create mode 100644 FetchmailOfSatan.gif create mode 100644 OPTIONS create mode 100644 README.NTLM create mode 100644 README.SSL create mode 100644 RELEASE-INSTRUCTIONS create mode 100644 RFC/draft-klensin-cram-03.txt create mode 100644 RFC/draft-newman-tls-imappop-05.txt create mode 100644 RFC/lan-mail-protocols create mode 100644 RFC/rfc1081.txt create mode 100644 RFC/rfc1123.txt create mode 100644 RFC/rfc1176.txt create mode 100644 RFC/rfc1203.txt create mode 100644 RFC/rfc1225.txt create mode 100644 RFC/rfc1460.txt create mode 100644 RFC/rfc1521.txt create mode 100644 RFC/rfc1725.txt create mode 100644 RFC/rfc1730.txt create mode 100644 RFC/rfc1731.txt create mode 100644 RFC/rfc1732.txt create mode 100644 RFC/rfc1734.txt create mode 100644 RFC/rfc1870.txt create mode 100644 RFC/rfc1891.txt create mode 100644 RFC/rfc1892.txt create mode 100644 RFC/rfc1893.txt create mode 100644 RFC/rfc1894.txt create mode 100644 RFC/rfc1938.txt create mode 100644 RFC/rfc1939.txt create mode 100644 RFC/rfc1985.txt create mode 100644 RFC/rfc2033.txt create mode 100644 RFC/rfc2060.txt create mode 100644 RFC/rfc2061.txt create mode 100644 RFC/rfc2062.txt create mode 100644 RFC/rfc2177.txt create mode 100644 RFC/rfc2195.txt create mode 100644 RFC/rfc2449.txt create mode 100644 RFC/rfc2554.txt create mode 100644 RFC/rfc2645.txt create mode 100644 RFC/rfc2683.txt create mode 100644 RFC/rfc821.txt create mode 100644 RFC/rfc822.txt create mode 100644 RFC/rfc937.txt create mode 100644 RFC/rfc977.txt create mode 100644 beos/beos_nameser.h create mode 100644 beos/beos_nameser_compat.h create mode 100644 bighand.png create mode 100755 config.sub create mode 100644 contrib/README create mode 100644 contrib/README.getmail create mode 100755 contrib/debian_rc create mode 100644 contrib/domino create mode 100644 contrib/fetchmail-mode.el create mode 100644 contrib/fetchmaildistrib create mode 100755 contrib/fetchmailnochda.pl create mode 100644 contrib/fetchspool create mode 100644 contrib/getfetchmail create mode 100644 contrib/getfetchmail.pl create mode 100755 contrib/getmail create mode 100755 contrib/gotmail create mode 100644 contrib/gotmail.awk create mode 100644 contrib/gotmail.conf create mode 100644 contrib/gotmail.html.awk create mode 100644 contrib/ip-up create mode 100755 contrib/login create mode 100755 contrib/logout create mode 100755 contrib/maildaemon create mode 100644 contrib/mailqueue.pl create mode 100644 contrib/mold_remover.py create mode 100644 contrib/multidrop create mode 100644 contrib/novell create mode 100644 contrib/poptest create mode 100755 contrib/preauth-harness create mode 100644 contrib/redhat_rc create mode 100644 contrib/runfetchmail create mode 100644 contrib/sm-hybrid create mode 100644 contrib/start_dynamic_ppp create mode 100644 contrib/toprocmail create mode 100644 contrib/zsh-completion create mode 100644 fetchmail.png create mode 100644 fetchmail.ppm create mode 100644 fetchmail.xpm create mode 100644 getopt.h create mode 100644 gettext.m4 create mode 100755 install-sh create mode 100644 intl/ChangeLog create mode 100644 intl/Makefile.in create mode 100644 intl/VERSION create mode 100644 intl/bindtextdom.c create mode 100644 intl/cat-compat.c create mode 100644 intl/dcgettext.c create mode 100644 intl/dgettext.c create mode 100644 intl/explodename.c create mode 100644 intl/finddomain.c create mode 100644 intl/gettext.c create mode 100644 intl/gettext.h create mode 100644 intl/gettextP.h create mode 100644 intl/hash-string.h create mode 100644 intl/intl-compat.c create mode 100644 intl/l10nflist.c create mode 100644 intl/libgettext.h create mode 100644 intl/linux-msg.sed create mode 100644 intl/loadinfo.h create mode 100644 intl/loadmsgcat.c create mode 100644 intl/localealias.c create mode 100644 intl/po2tbl.sed.in create mode 100644 intl/textdomain.c create mode 100644 intl/xopen-msg.sed create mode 100644 kerberos.h create mode 100644 lcmessage.m4 create mode 100644 libntlm-0.21/COPYING create mode 100644 libntlm-0.21/HISTORY create mode 100644 libntlm-0.21/Makefile create mode 100644 libntlm-0.21/README create mode 100644 libntlm-0.21/ntlm.h create mode 100644 libntlm-0.21/smb.h create mode 100644 libntlm-0.21/smbbyteorder.h create mode 100644 libntlm-0.21/smbdes.c create mode 100644 libntlm-0.21/smbdes.h create mode 100644 libntlm-0.21/smbencrypt.c create mode 100644 libntlm-0.21/smbencrypt.h create mode 100644 libntlm-0.21/smbmd4.c create mode 100644 libntlm-0.21/smbmd4.h create mode 100644 libntlm-0.21/smbutil.c create mode 100755 libntlm-0.21/test/COPYING create mode 100644 libntlm-0.21/test/Makefile create mode 100644 libntlm-0.21/test/README create mode 100644 libntlm-0.21/test/dumper.c create mode 100644 libntlm-0.21/test/getargs.c create mode 100644 libntlm-0.21/test/getargs.h create mode 100644 memmove.c create mode 100644 mime64/Makefile create mode 100644 mime64/README create mode 100644 mime64/mime.txt create mode 100644 mime64/mime64.c create mode 100755 missing create mode 100755 mkinstalldirs create mode 100644 po/.cvsignore create mode 100644 po/.pot create mode 100644 po/Makefile.in.in create mode 100644 po/POTFILES.in create mode 100644 po/ca.gmo create mode 100644 po/ca.po create mode 100644 po/cat-id-tbl.c create mode 100644 po/cs.gmo create mode 100644 po/cs.po create mode 100644 po/da.gmo create mode 100644 po/da.po create mode 100644 po/de.gmo create mode 100644 po/de.po create mode 100644 po/el.gmo create mode 100644 po/el.po create mode 100644 po/es.gmo create mode 100644 po/es.po create mode 100644 po/fetchmail.diff create mode 100644 po/fetchmail.pot create mode 100644 po/fr.gmo create mode 100644 po/fr.po create mode 100644 po/fr.po.orig create mode 100644 po/fr.po.rej create mode 100644 po/gl.gmo create mode 100644 po/gl.po create mode 100644 po/ja.gmo create mode 100644 po/ja.po create mode 100644 po/pl.gmo create mode 100644 po/pl.po create mode 100644 po/pl.po.orig create mode 100644 po/pl.po.rej create mode 100644 po/pt_BR.gmo create mode 100644 po/pt_BR.po create mode 100644 po/sk.gmo create mode 100644 po/sk.po create mode 100644 po/stamp-cat-id create mode 100644 po/tr.gmo create mode 100644 po/tr.po create mode 100644 progtest.m4 create mode 100644 rh-config/fetchmailconf.init create mode 100644 rh-config/fetchmailconf.wmconfig create mode 100644 rh-config/fetchmailconf.xpm create mode 100644 smb.h create mode 100644 smbbyteorder.h create mode 100644 smbdes.c create mode 100644 smbdes.h create mode 100644 smbencrypt.c create mode 100644 smbencrypt.h create mode 100644 smbmd4.c create mode 100644 smbmd4.h create mode 100644 smbutil.c create mode 100644 test-request create mode 100755 testmail create mode 100755 testmda create mode 100644 testrc create mode 100644 testservers.html create mode 100755 timeplot create mode 100644 torturetest.gladep create mode 100755 uploadfaq diff --git a/.cvsignore b/.cvsignore new file mode 100644 index 00000000..883dc490 --- /dev/null +++ b/.cvsignore @@ -0,0 +1,8 @@ +aclocal.m4 +config.h.in +configure +config.guess +config.sub +install-sh +mkinstalldirs +missing diff --git a/ABOUT-NLS b/ABOUT-NLS new file mode 100644 index 00000000..28d38c76 --- /dev/null +++ b/ABOUT-NLS @@ -0,0 +1,226 @@ +Notes on the Free Translation Project +************************************* + + Free software is going international! The Free Translation Project +is a way to get maintainers of free software, translators, and users all +together, so that will gradually become able to speak many languages. +A few packages already provide translations for their messages. + + If you found this `ABOUT-NLS' file inside a distribution, you may +assume that the distributed package does use GNU `gettext' internally, +itself available at your nearest GNU archive site. But you do *not* +need to install GNU `gettext' prior to configuring, installing or using +this package with messages translated. + + Installers will find here some useful hints. These notes also +explain how users should proceed for getting the programs to use the +available translations. They tell how people wanting to contribute and +work at translations should contact the appropriate team. + + When reporting bugs in the `intl/' directory or bugs which may be +related to internationalization, you should tell about the version of +`gettext' which is used. The information can be found in the +`intl/VERSION' file, in internationalized packages. + +One advise in advance +===================== + + If you want to exploit the full power of internationalization, you +should configure it using + + ./configure --with-included-gettext + +to force usage of internationalizing routines provided within this +package, despite the existence of internationalizing capabilities in the +operating system where this package is being installed. So far, only +the `gettext' implementation in the GNU C library version 2 provides as +many features (such as locale alias or message inheritance) as the +implementation here. It is also not possible to offer this additional +functionality on top of a `catgets' implementation. Future versions of +GNU `gettext' will very likely convey even more functionality. So it +might be a good idea to change to GNU `gettext' as soon as possible. + + So you need not provide this option if you are using GNU libc 2 or +you have installed a recent copy of the GNU gettext package with the +included `libintl'. + +INSTALL Matters +=============== + + Some packages are "localizable" when properly installed; the +programs they contain can be made to speak your own native language. +Most such packages use GNU `gettext'. Other packages have their own +ways to internationalization, predating GNU `gettext'. + + By default, this package will be installed to allow translation of +messages. It will automatically detect whether the system provides +usable `catgets' (if using this is selected by the installer) or +`gettext' functions. If neither is available, the GNU `gettext' own +library will be used. This library is wholly contained within this +package, usually in the `intl/' subdirectory, so prior installation of +the GNU `gettext' package is *not* required. Installers may use +special options at configuration time for changing the default +behaviour. The commands: + + ./configure --with-included-gettext + ./configure --with-catgets + ./configure --disable-nls + +will respectively bypass any pre-existing `catgets' or `gettext' to use +the internationalizing routines provided within this package, enable +the use of the `catgets' functions (if found on the locale system), or +else, *totally* disable translation of messages. + + When you already have GNU `gettext' installed on your system and run +configure without an option for your new package, `configure' will +probably detect the previously built and installed `libintl.a' file and +will decide to use this. This might be not what is desirable. You +should use the more recent version of the GNU `gettext' library. I.e. +if the file `intl/VERSION' shows that the library which comes with this +package is more recent, you should use + + ./configure --with-included-gettext + +to prevent auto-detection. + + By default the configuration process will not test for the `catgets' +function and therefore they will not be used. The reasons are already +given above: the emulation on top of `catgets' cannot provide all the +extensions provided by the GNU `gettext' library. If you nevertheless +want to use the `catgets' functions use + + ./configure --with-catgets + +to enable the test for `catgets' (this causes no harm if `catgets' is +not available on your system). If you really select this option we +would like to hear about the reasons because we cannot think of any +good one ourself. + + Internationalized packages have usually many `po/LL.po' files, where +LL gives an ISO 639 two-letter code identifying the language. Unless +translations have been forbidden at `configure' time by using the +`--disable-nls' switch, all available translations are installed +together with the package. However, the environment variable `LINGUAS' +may be set, prior to configuration, to limit the installed set. +`LINGUAS' should then contain a space separated list of two-letter +codes, stating which languages are allowed. + +Using This Package +================== + + As a user, if your language has been installed for this package, you +only have to set the `LANG' environment variable to the appropriate +ISO 639 `LL' two-letter code prior to using the programs in the +package. For example, let's suppose that you speak German. At the +shell prompt, merely execute `setenv LANG de' (in `csh'), +`export LANG; LANG=de' (in `sh') or `export LANG=de' (in `bash'). This +can be done from your `.login' or `.profile' file, once and for all. + + An operating system might already offer message localization for +many of its programs, while other programs have been installed locally +with the full capabilities of GNU `gettext'. Just using `gettext' +extended syntax for `LANG' would break proper localization of already +available operating system programs. In this case, users should set +both `LANGUAGE' and `LANG' variables in their environment, as programs +using GNU `gettext' give preference to `LANGUAGE'. For example, some +Swedish users would rather read translations in German than English for +when Swedish is not available. This is easily accomplished by setting +`LANGUAGE' to `sv:de' while leaving `LANG' to `sv'. + +Translating Teams +================= + + For the Free Translation Project to be a success, we need interested +people who like their own language and write it well, and who are also +able to synergize with other translators speaking the same language. +Each translation team has its own mailing list, courtesy of Linux +International. You may reach your translation team at the address +`LL@li.org', replacing LL by the two-letter ISO 639 code for your +language. Language codes are *not* the same as the country codes given +in ISO 3166. The following translation teams exist, as of December +1997: + + Chinese `zh', Czech `cs', Danish `da', Dutch `nl', English `en', + Esperanto `eo', Finnish `fi', French `fr', German `de', Hungarian + `hu', Irish `ga', Italian `it', Indonesian `id', Japanese `ja', + Korean `ko', Latin `la', Norwegian `no', Persian `fa', Polish + `pl', Portuguese `pt', Russian `ru', Slovenian `sl', Spanish `es', + Swedish `sv', and Turkish `tr'. + +For example, you may reach the Chinese translation team by writing to +`zh@li.org'. + + If you'd like to volunteer to *work* at translating messages, you +should become a member of the translating team for your own language. +The subscribing address is *not* the same as the list itself, it has +`-request' appended. For example, speakers of Swedish can send a +message to `sv-request@li.org', having this message body: + + subscribe + + Keep in mind that team members are expected to participate +*actively* in translations, or at solving translational difficulties, +rather than merely lurking around. If your team does not exist yet and +you want to start one, or if you are unsure about what to do or how to +get started, please write to `translation@iro.umontreal.ca' to reach the +coordinator for all translator teams. + + The English team is special. It works at improving and uniformizing +the terminology in use. Proven linguistic skill are praised more than +programming skill, here. + +Available Packages +================== + + Languages are not equally supported in all packages. The following +matrix shows the current state of internationalization, as of December +1997. The matrix shows, in regard of each package, for which languages +PO files have been submitted to translation coordination. + + Ready PO files cs da de en es fi fr it ja ko nl no pl pt ru sl sv + .----------------------------------------------------. + bash | [] [] [] | 3 + bison | [] [] [] | 3 + clisp | [] [] [] [] | 4 + cpio | [] [] [] [] [] [] | 6 + diffutils | [] [] [] [] [] | 5 + enscript | [] [] [] [] [] [] | 6 + fileutils | [] [] [] [] [] [] [] [] [] [] | 10 + findutils | [] [] [] [] [] [] [] [] [] | 9 + flex | [] [] [] [] | 4 + gcal | [] [] [] [] [] | 5 + gettext | [] [] [] [] [] [] [] [] [] [] [] | 12 + grep | [] [] [] [] [] [] [] [] [] [] | 10 + hello | [] [] [] [] [] [] [] [] [] [] [] | 11 + id-utils | [] [] [] | 3 + indent | [] [] [] [] [] | 5 + libc | [] [] [] [] [] [] [] | 7 + m4 | [] [] [] [] [] [] | 6 + make | [] [] [] [] [] [] | 6 + music | [] [] | 2 + ptx | [] [] [] [] [] [] [] [] | 8 + recode | [] [] [] [] [] [] [] [] [] | 9 + sh-utils | [] [] [] [] [] [] [] [] | 8 + sharutils | [] [] [] [] [] [] | 6 + tar | [] [] [] [] [] [] [] [] [] [] [] | 11 + texinfo | [] [] [] | 3 + textutils | [] [] [] [] [] [] [] [] [] | 9 + wdiff | [] [] [] [] [] [] [] [] | 8 + `----------------------------------------------------' + 17 languages cs da de en es fi fr it ja ko nl no pl pt ru sl sv + 27 packages 6 4 25 1 18 1 26 2 1 12 20 9 19 7 4 7 17 179 + + Some counters in the preceding matrix are higher than the number of +visible blocks let us expect. This is because a few extra PO files are +used for implementing regional variants of languages, or language +dialects. + + For a PO file in the matrix above to be effective, the package to +which it applies should also have been internationalized and +distributed as such by its maintainer. There might be an observable +lag between the mere existence a PO file and its wide availability in a +distribution. + + If December 1997 seems to be old, you may fetch a more recent copy +of this `ABOUT-NLS' file on most GNU archive sites. + diff --git a/CHANGES b/CHANGES new file mode 100644 index 00000000..8a943ee9 --- /dev/null +++ b/CHANGES @@ -0,0 +1,4 @@ + Changelog for fetchmail + +* Mon Jan 12 2004 +- See the project news file for recent changes. diff --git a/FetchmailOfSatan.gif b/FetchmailOfSatan.gif new file mode 100644 index 00000000..15cfdc31 Binary files /dev/null and b/FetchmailOfSatan.gif differ diff --git a/OPTIONS b/OPTIONS new file mode 100644 index 00000000..96886366 --- /dev/null +++ b/OPTIONS @@ -0,0 +1,77 @@ +Summary of responses on `Nuke the options?': + +Yes: + +Felix Morley Finch +Nathan Myers +Irving Wolfe +Craig Metz +Alexander Kourakos +John Swinbank +Alexandros Manoussakis + +No: + +Guenther Leber +Dave Bodenstab +Erik Soosalu +Jonathan Marten + +Other: + +Chris Hanson thinks --smtphost can be useful, +but says the change won't affect him. + +Matt Simmons didn't express a general opinion but wants +-B/fetchlimit kept. + +Steffen Opel makes a good argument +that --limit should be settable from the command line as a way to throttle +fetches according to day-night rates. + +Comments: + felix@crowfix.com: "Using --fetchmailrc, someone could +write a Perl wrapper which would dummy up a temporary control file +using the soon-to-be-banned options, if someone really wanted such a +program." + ncm@cantrip.org doesn't want fetchmailrc to require a control file. + gleber@gams.at: "I like the flexibility I get from [command-line +options] and use it very often." + awk@bnt.com: keep -u, -p, nuke the others. + alx@beryl.kapatel.gr: keep -u, -p, -t, nuke the others. + esoosalu@geocities.com: "I would have an objection to removing +command line options: It makes it a lot harder to debug the inital setup." + jonathan.marten@uk.Sun.COM: particularly (and not unreasonably) +objects to losing -r. + +Alexandros Manoussakis offered the following summary: + +It seems like many of us want to be able to use +fetchmail without the need of a .fetchmailrc file. +Regarding your list of commands to remove from +the command line, taking into account the feedback +regarding the matter we have (* denotes wanted options): + + -I, --interface interface required specification + -M, --monitor monitor interface for activity +* -p, --protocol specify pop2, pop3, imap, apop, rpop, kpop, etrn + -U, --uidl force the use of UIDLs (pop3 only) + -P, --port TCP/IP service port to connect to + -A, --auth authentication type (password or kerberos) + -E, --envelope envelope address header + -Q, --qvirtual prefix to remove from local user id +* -u, --username specify users's login on server + -n, --norewrite don't rewrite header addresses +* -l, --limit don't fetch messages over given size +* -K, --nokeep delete new messages after retrieval +* -S, --smtphost set SMTP forwarding host + -D, --smtpaddress set SMTP delivery domain to use + -Z, --antispam, set antispam response value + -b, --batchlimit set batch limit for SMTP connections + -B, --fetchlimit set fetch limit for server connections + -e, --expunge set max deletions between expunges +* -r, --folder specify remote folder name +* -t, --timeout server nonresponse timeout + +Let's see how it goes and you can remove at least the options +no-one complains about! diff --git a/README.NTLM b/README.NTLM new file mode 100644 index 00000000..964ba598 --- /dev/null +++ b/README.NTLM @@ -0,0 +1,83 @@ +NTLM support by Grant Edwards + +This directory contains sources for a library which provides +routines to manipulate the structures used for the client end +of Microsoft NTLM authentication. + +This code (the ntlm.h file and smb*.[ch] files) was taken mostly from +the Samba project and was initially intended for use with Microsoft +Exchange Server when it is configured to require NTLM authentication +for clients of its IMAP server. + +Not much effort has been put into making this portable, and the author +only know for sure that it works on i386 Linux glibc systems -- though +there shouldn't be anything all that system-specific anywhere. System +byte order differences should already be taken care of. + +USAGE + +The application program must convert these structures to/from base64 +which is used to transfer data for IMAP authentication. For example +usage see the sources for the mutt MUA or here in the fetchmail +package. + +In general the usage is something like shown below (no, I don't +know if this code even compiles, but you get the idea +hopefully): + + +#include + +extern char *seqTag; /* IMAP sequence number */ + +int imap_auth_ntlm(char *user, char *domain, char *pass) +{ + tSmbNtlmAuthRequest request; + tSmbNtlmAuthChallenge challenge; + tSmbNtlmAuthResponse response; + char buffer[512]; + char tmpstr[32]; + + writeToServer("%s AUTHENTICATE NTLM\r\n",seqTag); + readFromServer(buffer) + + /* buffer should be "+", but we won't show code to check */ + + /* + * prepare the request, convert to base64, and send it to + * the the server. My server didn't care about domain, and NULL + * worked fine. + */ + + buildSmbNtlmAuthRequest(&request,user,domain); + convertToBase64(buffer, &request, SmbLength(&request)); + writeToServer("%s\r\n",buffer); + + /* read challange data from server, convert from base64 */ + + readFromServer(buffer); + + /* buffer should contain the string "+ [base 64 data]" */ + + convertFromBase64(&challenge, buffer+2); + + /* prepare response, convert to base64, send to server */ + + buildSmbNtlmAuthResponse(&challenge, &response, user, pass); + convertToBase64(buffer,&response,SmbLength(&response)); + writeToServer("%s\r\n",buffer); + + /* read line from server, it should be "[seq] OK blah blah blah" */ + + readFromServer(buffer); + + sprintf(tmpstr,"%s OK",seqTag); + + if (strncmp(buffer,tmpstr,strlen(tmpstr))) + { + /* login failed */ + return -1; + } + + return 0; +} diff --git a/README.SSL b/README.SSL new file mode 100644 index 00000000..44f0c195 --- /dev/null +++ b/README.SSL @@ -0,0 +1,92 @@ +Fetchmail SSL support +===================== + +NOTE: This text is maybe not explanatory enough, so a little knowledge about +public-key-cryptography and associated topics is required. + +Using the fetchmail ssl option, you can have the data transferred between you +and the server in an encrypted form, so that eavesdropping should become +practically impossible. + +This works as following: the server has a key pair (a secret and a public key), +and it sends the client it's public key. Messages encrypted with the public key +can be decrypted using the private one and vice versa. +A symmetric session key (symmetric means that the same key is used for +encryption and decryption) can now be agreed upon by the two parties using +the secure channel the key pair builds. The session key is now used to encrypt +the traffic. + +In the fetchmail case, the client can now authenticate itself to the server by +using the usual POP/IMAP/whatever authentication mechanisms. + +However, so called man-in-the-middle attacks are still possible: in such a +setting, an attacker imposes the server, and thus can e.g. get your +authentication information if you don't use a challenge based authentication +mechanism (because he is thought to be the real server, fetchmail will try to +authenticate against it by telling it your password). + +So, not only you need to prove your identity to the server, the server likewise +needs to prove it's to you. +In the standard setting, the server has a certificate (the client can have a +certificate too to prove its identity, but this is not covered by this +document). This certificate contains the server's public key, some data about +the server, and a digital signature and data about the signer. +Digital signatures can also be made using a key pair as described earlier. + +To check this certificate, you may use the new option sslcertck. When it is +specified, the signature of server certificate is checked against local trusted +certificates to see whether the owner of one of the ceritificates has signed +that server certificate, and if so, whether the signature is valid. +So, if the server certificate is signed by a Certification Authority (CA), +you put the CA's certificate into a directory where you keep trusted +certificates, and point fetchmail to it. Fetchmail will then accept certificates +signed by the owner of that certificate with the private key belonging to the +public key in the certificate. +You can specifiy this path using the sslcertpath option. +The idea is that the CA only gives certificates to entities of which it has +checked and verified the identity of (and in this case, that the server name you +specify does belong to it). So, if you chose the intentions and the thoroughness +of a CA, you can be reasonably sure that if a certificate is signed by the CA, +it really belongs to the server and owner that it claims to. + +Certificates are only valid in a certain time window, so your system clock +should be reasonably accurate when checking certificates. + +Additionally, CAs keep Certificate Revocation Lists (CRLs) in which they note +the certificates that are to be treated as invalid (e.g. because the server +name has changed, another ceritifcate was granted, or even because the +certificate was not granted to the rightful owner). + +The really paranoid (who chose to not trust a CA) can check the fingerprint of +the public key that is used by the server. The fingerprint is a hash of that +key that (hopefully) has few collisions and is hard to attack using a "birthday +attack", i.e. nobody can generate a second key that hashes to the same value +of the original key in reasonable time. So, if the fingerprint matches, you +can be reasonable sure that you talk to the original server, because only that +knows the secret key, and it is very hard to generate a matching secret key from +the public key. If it doesn't, it might be an attack, but keep in mind that the +server key may also have changed legitimately before panicing ;) + +fetchmail will present the fingerprint to you. Another mode, that strictly +checks the fingerprint, is available (using the sslfingerprint option, and +giving the desired fingerprint as an argument). If you want to check finger- +prints, you should use that option, because otherwise, it may be too late +to cancel if you see the fingerprint (your password may already have been +transmitted)! + +The certificate directory must be hashed in a way OpenSSL expects it: each +time you modify a file in that directory or add a file to it, you need +to use the c_rehash perl script that comes with OpenSSL (in the tools/ +subdirectory, in case that it isn't installed). Additionally, you might +need to convert the ceriticates to different formats (the PEM format is expected +and usually is available, DER is another one; you can convert between +both using the openssl(1) utility). + +The fingerprints fetchmail uses are MD5 sums. You can generate them e.g. useing +the openssl(1) "x509 -fingerprint" command. The format is a hexadecimal string +with a ":" separating two byes (i.e. a ":" every two hex "digits"). The letter +hex digits must be in upper case! + +*CAVEAT*: OpenSSL seems to be unable to check CRLs at the moment! + + - Thomas Moestl diff --git a/RELEASE-INSTRUCTIONS b/RELEASE-INSTRUCTIONS new file mode 100644 index 00000000..e40b2b57 --- /dev/null +++ b/RELEASE-INSTRUCTIONS @@ -0,0 +1,10 @@ +To do a release: + +1. Torture-test the code against the list of test sites usuing the + torturetest script. + +2. Check in all files to RCS with an appropriate release label. + +3. Run "makerelease" is root. Read the script to see what it generates. + +4. Run "upload" as yourself. diff --git a/RFC/draft-klensin-cram-03.txt b/RFC/draft-klensin-cram-03.txt new file mode 100644 index 00000000..bfac1d5b --- /dev/null +++ b/RFC/draft-klensin-cram-03.txt @@ -0,0 +1,261 @@ + +Network Working Group J Klensin +Internet Draft R Catoe +Document: draft-klensin-cram-03.txt P Krumviede + MCI + September 1996 + + + + + IMAP/POP AUTHorize Extension for Simple Challenge/Response + +Status of this Memo + + This document is an Internet Draft. Internet Drafts are working + documents of the Internet Engineering Task Force (IETF), its Areas, + and its Working Groups. Note that other groups may also distribute + working documents as Internet Drafts. + + Internet Drafts are draft documents valid for a maximum of six + months. Internet Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet + Drafts as reference material or to cite them other than as a + ``working draft'' or ``work in progress``. + + To learn the current status of any Internet-Draft, please check the + 1id-abstracts.txt listing contained in the Internet-Drafts Shadow + Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or + munnari.oz.au. + + A revised version of this draft document will be submitted to the + IESG for processing as a Proposed Standard for the Internet + Community, updating RFC 1731. Discussion and suggestions for + improvement are requested. This document reflects editorial + comments received during the last call period; the protocol is + unchanged from the previous version. This draft will expire + before February 22, 1997. Distribution of this draft is + unlimited. + + +Abstract + + While IMAP4 supports a number of strong authentication mechanisms + as described in RFC 1731, it lacks any mechanism that neither passes + cleartext, reusable passwords across the network nor requires either a + significant security infrastructure or that the mail server update a + mail-system-wide user authentication file on each mail access. This + specification provides a simple challenge-response authentication + protocol that is suitable for use with IMAP4. Since it utilizes + Keyed-MD5 digests and does not require that the secret be stored in the + clear on the server, it may also constitute an improvement on APOP for + POP3 use as specified in RFC 1734. + +1. Introduction + + Existing Proposed Standards specify an AUTHENTICATE mechanism for + the IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for + the POP3 protocol [POP3-AUTH]. The AUTHENTICATE mechanism is intended + to be extensible; the four methods specified in [IMAP-AUTH] are all + fairly powerful and require some security infrastructure to support. + The base POP3 specification [POP3] also contains a lightweight + challenge-response mechanism called APOP. APOP is associated with + most of the risks associated with such protocols: in particular, it + requires that both the client and server machines have access to the + shared secret in cleartext form. CRAM offers a method for avoiding + such cleartext storage while retaining the algorithmic simplicity + of APOP in using only MD5, though in a "keyed" method. + + At present, IMAP [IMAP] lacks any facility corresponding to APOP. + The only alternative to the strong mechanisms identified in + [IMAP-AUTH] is a presumably cleartext username and password, + supported through the LOGIN command in [IMAP]. This document + describes a simple challenge-response mechanism, similar to APOP and + PPP CHAP [PPP], that can be used with IMAP (and, in principle, with + POP3). + + This mechanism also has the advantage over some possible + alternatives of not requiring that the server maintain information + about email "logins" on a per-login basis. While mechanisms that + do require such per-login history records may offer enhanced + security, protocols such as IMAP, which may have several + connections between a given client and server open more or less + simultaneous, may make their implementation particularly + challenging. + + +2. Challenge-Response Authentication Mechanism (CRAM) + + The authentication type associated with CRAM is "CRAM-MD5". + + The data encoded in the first ready response contains an + presumptively arbitrary string of random digits, a timestamp, + and the fully-qualified primary host name of the server. The + syntax of the unencoded form must correspond to that of an + RFC 822 'msg-id' [RFC822] as described in [POP3]. + + The client makes note of the data and then responds with a string + consisting of the user name, a space, and a 'digest'. The latter is + computed by applying the keyed MD5 algorithm from [KEYED-MD5] + where the key is a shared secret and the digested text is + the timestamp (including angle-brackets). + + This shared secret is a string known only to the client and server. + The `digest' parameter itself is a 16-octet value which is + sent in hexadecimal format, using lower-case ASCII characters. + + When the server receives this client response, it verifies the digest + provided. If the digest is correct, the server should consider the + client authenticated and respond appropriately. + + Keyed MD5 is chosen for this application because of the greater + security imparted to authentication of short messages. In addition, + the use of the techniques described in [KEYED-MD5] for + precomputation of intermediate results make it possible to avoid + explicit cleartext storage of the shared secret on the server system + by instead storing the intermediate results which are known as + "contexts". + + CRAM does not support a protection mechanism. + + + Example: + + The examples in this document show the use of the CRAM mechanism with + the IMAP4 AUTHENTICATE command [IMAP-AUTH]. The base64 encoding of + the challenges and responses is part of the IMAP4 AUTHENTICATE + command, not part of the CRAM specification itself. + + S: * OK IMAP4 Server + C: A0001 AUTHENTICATE CRAM-MD5 + S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ + C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw + S: A0001 OK CRAM authentication successful + + In this example, the shared secret is the string 'tanstaaftanstaaf'. + Hence, the Keyed MD5 digest is produced by calculating + + MD5((tanstaaftanstaaf XOR opad), + MD5((tanstaaftanstaaf XOR ipad), + <1896.697170952@postoffice.reston.mci.net>)) + + where ipad and opad are as defined in the keyed-MD5 draft + [KEYED-MD5] and the string shown in the challenge is the base64 + encoding of <1896.697170952@postoffice.reston.mci.net>. The + shared secret is null-padded to a length of 64 bytes. If the + shared secret is longer than 64 bytes, the MD5 digest of the + shared secret is used as a 16 byte input to the keyed MD5 + calculation. + + This produces a digest value (in hexadecimal) of + + + b913a602c7eda7a495b4e6e7334d3890 + + The user name is then prepended to it, forming + + tim b913a602c7eda7a495b4e6e7334d3890 + + Which is then base64 encoded to meet the requirements of the IMAP4 + AUTHENTICATE command (or the similar POP3 AUTH command), yielding + + dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw + + + +3. References + + [CHAP] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", + RFC 1334, October 1992. + + [IMAP] Crispin, M. "Internet Message Access Protocol - Version 4", + RFC 1730, University of Washington, December, 1994. + + [IMAP-AUTH] Myers, J. "IMAP4 Authentication Mechanisms", + RFC 1731, Carnegie Mellon, December, 1994 + + [KEYED-MD5] Krawczyk, H "HMAC-MD5: Keyed-MD5 for Message + Authentication" work in progess (draft-ietf-ipsec-hmac-md5-00.txt), + IBM, March 1996. + + [MD5] Rivest, R. "The MD5 Message Digest Algorithm", + RFC 1321, MIT Laboratory for Computer Science, April, 1992. + + [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3 ", + RFC 1939 (STD 53), Carnegie Mellon, May 1996. + + [POP3-AUTH] Myers, J. "POP3 AUTHentication command", RFC 1734, Carnegie + Mellon, December, 1994. + + +4. Security Considerations + + It is conjectured that use of the CRAM authentication mechanism + provides origin identification and replay protection for a session. + Accordingly, a server that implements both a cleartext password + command and this authentication type should not allow both methods of + access for a given user. + + While the saving, on the server, of "contexts" (see section 2) is + marginally better than saving the shared secrets in cleartext as is + required by CHAP [CHAP] and APOP [POP3], it is not sufficient to + protect the secrets if the server itself is compromised. + Consequently, servers that store the secrets or contexts must both + be protected to a level appropriate to the potential information + value in user mailboxes and identities. + + As the length of the shared secret increases, so does the difficulty + of deriving it. + + While there are now suggestions in the literature that the use of + MD5 and keyed MD5 in authentication procedures probably has a + limited effective lifetime, the technique is now widely deployed and + widely understood. It is believed that this general understanding + may assist with the rapid replacement, by CRAM-MD5, of the current + uses of permanent cleartext passwords in IMAP. This document has + been deliberately written to permit easy upgrading to use SHA (or + whatever alternatives emerge) when they are considered to be widely + available and adequately safe. + + Even with the use of CRAM, users are still vulnerable to active + attacks. An example of an increasingly common active attack is 'TCP + Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95]. + + See section 1 above for additional discussion. + + +5. Acknowledgements + + This memo borrows ideas and some text liberally from [POP3] and + [RFC-1731] and thanks are due the authors of those documents. Ran + Atkinson made a number of valuable technical and editorial + contributions to the current draft. + + +6. Authors' Addresses + + John C. Klensin + MCI Telecommunications + 800 Boylston St, 7th floor + Boston, MA 02199 + USA + Email: klensin@mci.net + Tel: +1 617 960 1011 + + Randy Catoe + MCI Telecommunications + 2100 Reston Parkway + Reston, VA 22091 + USA + Email: randy@mci.net + Tel: +1 703 715 7366 + + Paul Krumviede + MCI Telecommunications + 2100 Reston Parkway + Reston, VA 22091 + USA + Email: paul@mci.net + Tel: +1 703 715 7251 + + diff --git a/RFC/draft-newman-tls-imappop-05.txt b/RFC/draft-newman-tls-imappop-05.txt new file mode 100644 index 00000000..680556e8 --- /dev/null +++ b/RFC/draft-newman-tls-imappop-05.txt @@ -0,0 +1,618 @@ + + + + + + +Network Working Group C. Newman +Internet Draft: Using TLS with IMAP4, POP3 and ACAP Innosoft +Document: draft-newman-tls-imappop-05.txt November 1998 + + + Using TLS with IMAP4, POP3 and ACAP + + +Status of this memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + To view the entire list of current Internet-Drafts, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net + (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au + (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US + West Coast). + +Abstract + + This specification defines extensions to IMAP [IMAP4], POP [POP3] + and ACAP [ACAP] which activate TLS [TLS]. This also defines a + simple PLAIN SASL [SASL] mechanism for use underneath strong TLS + encryption with ACAP or other protocols lacking a clear-text login + command. + +1. Motivation + + The TLS protocol [TLS] (formerly known as SSL) provides a way to + secure a TCP connection from tampering and eavesdropping. + Obviously, the option of using such security is desirable for IMAP + [IMAP4], POP [POP3] and ACAP [ACAP]. Although advanced SASL [SASL] + authentication mechanisms can provide a lightweight version of this + service, TLS is a full service security layer and is complimentary + to simple authentication-only SASL mechanisms or clear-text + password login commands. Furthermore, many sites have a high + investment in authentication infrastructure (e.g., a large database + of a one-way-function applied to user passwords), so a privacy + + + +Newman [Page 1] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + + layer which is not tightly bound to user authentication can protect + against network eavesdropping attacks without requiring a new + authentication infrastructure and/or forcing all users to change + their password. + +1.1. Conventions Used in this Document + + The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD + NOT", "MAY", and "OPTIONAL" in this document are to be interpreted + as described in "Key words for use in RFCs to Indicate Requirement + Levels" [KEYWORDS]. + + Formal syntax is defined using ABNF [ABNF]. + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + +2. Basic Interoperability and Security Requirements + + The following requirements apply to all implementations of the + STARTTLS extension for IMAP4, POP3 and ACAP. + +2.1. Cipher Suite Requirements + + Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher + suite is REQUIRED. This is important as it assures that any two + compliant implementations can be configured to interoperate. + + All other cipher suites are OPTIONAL. + +2.2. TLS Operational Mode Security Requirements + + Both clients and servers SHOULD have an operational mode where use + of TLS encryption is required to login. Clients MAY have an + operational mode where TLS is used only when advertised by the + server, but login occurs regardless. For backwards compatibility, + servers SHOULD have an operational mode which permits clients to + login when TLS is not used. + +2.3. Clear-Text Password Requirement + + A server which implements both STARTTLS and a clear-text password + authentication mechanism (including but not limited to the IMAP4 + LOGIN command, POP3 PASS command and the PLAIN mechanism in section + 6) MUST have an operational mode where all clear-text login + commands and mechanisms are disabled unless TLS encryption is + active. + + + + +Newman [Page 2] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + +2.4. Server Identity Check + + During the TLS negotiation, the client MUST check its understanding + of the server hostname against the server's identity as presented + in the server Certificate message, in order to prevent + man-in-the-middle attacks. Matching is performed according to + these rules: + + o The client MUST use the server hostname it used to open the + connection as the value to compare against the server name as + expressed in the server certificate. The client MUST NOT use + any form of the server hostname derived from an insecure remote + source (e.g., insecure DNS reverse lookup). + + o If a subjectAltName extension of type dNSName is present in the + certificate, it SHOULD be used as the source of the server's + identity. + + o Matching is case-insensitive. + + o A "*" wildcard character MAY be used as the left-most name + component in the certificate. For example, *.example.com would + match a.example.com, foo.example.com, etc. but would not match + example.com. + + o If the certificate contains multiple names (e.g. more than one + dNSName field), then a match with any one of the fields is + considered acceptable. + + If the match fails, the client SHOULD either ask for explicit user + confirmation, or terminate the connection and indicate the server's + identity is suspect. + +3. IMAP4 STARTTLS extension + + When the TLS extension is present in IMAP4, "STARTTLS" is listed as + a capability in response to the CAPABILITY command. This extension + adds a single command, "STARTTLS" to the IMAP4 protocol which is + used to begin a TLS negotiation. + +3.1. STARTTLS Command + + Arguments: none + + Responses: no specific responses for this command + + Result: OK - begin TLS negotiation + NO - security layer already active + + + +Newman [Page 3] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + + BAD - command unknown or arguments invalid + + A TLS negotiation begins immediately after the CRLF at the end of + the tagged OK response from the server. Once a client issues a + STARTTLS command, it MUST NOT issue further commands until a + server response is seen and the TLS negotiation is complete. + + The STARTTLS command is only valid in non-authenticated state. + The server remains in non-authenticated state, even if client + credentials are supplied during the TLS negotiation. The SASL + [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS + client credentials are successfully exchanged, but servers + supporting the STARTTLS command are not required to support the + EXTERNAL mechanism. + + Once TLS has been started, the client SHOULD discard cached + information about server capabilities and re-issue the CAPABILITY + command. This is necessary to protect against man-in-the-middle + attacks which alter the capabilities list prior to STARTTLS. The + server MAY advertise different capabilities after STARTTLS. + + The formal syntax for IMAP4 is amended as follows: + + command_any =/ "STARTTLS" + + Example: C: a001 CAPABILITY + S: * CAPABILITY IMAP4rev1 STARTTLS + S: a001 OK CAPABILITY completed + C: a002 STARTTLS + S: a002 OK Begin TLS negotiation now + + C: a003 CAPABILITY + S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL + S: a003 OK CAPABILITY completed + C: a004 LOGIN joe password + S: a004 OK LOGIN completed + +4. POP3 STARTTLS extension + + The POP3 STARTTLS extension adds the STLS command to POP3 servers. + If this is implemented, the POP3 extension mechanism [POP3EXT] MUST + also be implemented to avoid the need for client probing of multiple + commands. The capability name "STLS" indicates this command is + present. + + STLS + + Arguments: none + + + +Newman [Page 4] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + + Restrictions: + Only permitted in AUTHORIZATION state. + + Discussion: + A TLS negotiation begins immediately after the CRLF at the + end of the +OK response from the server. A -ERR response + MAY result if a security layer is already active. Once a + client issues a STLS command, it MUST NOT issue further + commands until a server response is seen and the TLS + negotiation is complete. + + The STLS command is only permitted in AUTHORIZATION state + and the server remains in AUTHORIZATION state, even if + client credentials are supplied during the TLS negotiation. + The AUTH command [POP-AUTH] with the EXTERNAL mechanism + [SASL] MAY be used to authenticate once TLS client + credentials are successfully exchanged, but servers + supporting the STLS command are not required to support the + EXTERNAL mechanism. + + Once TLS has been started, the client SHOULD discard cached + information about server capabilities and re-issue the CAPA + command. This is necessary to protect against + man-in-the-middle attacks which alter the capabilities list + prior to STLS. The server MAY advertise different + capabilities after STLS. + + Possible Responses: + +OK -ERR + + Examples: + C: STLS + S: +OK Begin TLS negotiation + + ... + C: STLS + S: -ERR Security Layer already active + +5. ACAP STARTTLS extension + + When the TLS extension is present in ACAP, "STARTTLS" is listed as + a capability in the ACAP greeting. No arguments to this capability + are defined at this time. This extension adds a single command, + "STARTTLS" to the ACAP protocol which is used to begin a TLS + negotiation. + + + + + + +Newman [Page 5] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + +5.1. STARTTLS Command + + Arguments: none + + Responses: no specific responses for this command + + Result: OK - begin TLS negotiation + NO - security layer already active + BAD - command unknown or arguments invalid + + A TLS negotiation begins immediately after the CRLF at the end of + the tagged OK response from the server. Once a client issues a + STARTTLS command, it MUST NOT issue further commands until a + server response is seen and the TLS negotiation is complete. + + The STARTTLS command is only valid in non-authenticated state. + The server remains in non-authenticated state, even if client + credentials are supplied during the TLS negotiation. The SASL + [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS + client credentials are successfully exchanged, but servers + supporting the STARTTLS command are not required to support the + EXTERNAL mechanism. + + After the TLS layer is established, the server MUST re-issue an + untagged ACAP greeting. This is necessary to protect against + man-in-the-middle attacks which alter the capabilities list prior + to STARTTLS. The client SHOULD discard cached capability + information and replace it with the information from the new ACAP + greeting. The server MAY advertise different capabilities after + STARTTLS. + + The formal syntax for ACAP is amended as follows: + + command_any =/ "STARTTLS" + + Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) + C: a002 STARTTLS + S: a002 OK "Begin TLS negotiation now" + + S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") + +6. PLAIN SASL mechanism + + Clear-text passwords are simple, interoperate with almost all + existing operating system authentication databases, and are useful + for a smooth transition to a more secure password-based + authentication mechanism. The drawback is that they are + unacceptable for use over an unencrypted network connection. + + + +Newman [Page 6] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + + This defines the "PLAIN" SASL mechanism for use with ACAP and other + protocols with no clear-text login command. This MUST NOT be + implemented unless strong TLS encryption or an equivalent strong + encryption layer is also implemented. + + The mechanism consists of a single message from the client to the + server. The client sends the authorization identity (identity to + login as), followed by a US-ASCII NUL character, followed by the + authentication identity (identity whose password will be used), + followed by a US-ASCII NUL character, followed by the clear-text + password. The client may leave the authorization identity empty to + indicate that it is the same as the authentication identity. + + The server will verify the authentication identity and password + with the system authentication database and verify that the + authentication credentials permit the client to login as the + authorization identity. If both steps succeed, the user is logged + in. + + The server MAY also use the password to initialize any new + authentication database, such as one suitable for CRAM-MD5 + [CRAM-MD5]. + + Non-US-ASCII characters are permitted as long as they are + represented in UTF-8 [UTF-8]. Use of non-visible characters or + characters which a user may be unable to enter on some keyboards is + discouraged. + + Clients are encouraged to support pure-binary passwords as they may + be safe from dictionary attacks. However, if the client offers a + character-based interface for password entry it MUST use UTF-8 + encoding for the characters. + + The formal grammar for the client message using Augmented BNF + [ABNF] follows. + + message = [authorize-id] NUL authenticate-id NUL password + authenticate-id = 1*UTF8-SAFE ; MUST accept up to 255 octets + authorize-id = 1*UTF8-SAFE ; MUST accept up to 255 octets + password = *NZ-OCTET ; MUST accept up to 255 octets + NUL = %x00 + NZ-OCTET = %x01-FF ; all non-NUL octet values + UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 / + UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 + UTF8-1 = %x80-BF + UTF8-2 = %xC0-DF UTF8-1 + UTF8-3 = %xE0-EF 2UTF8-1 + UTF8-4 = %xF0-F7 3UTF8-1 + + + +Newman [Page 7] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + + UTF8-5 = %xF8-FB 4UTF8-1 + UTF8-6 = %xFC-FD 5UTF8-1 + + Here is an example of how this might be used to initialize a + CRAM-MD5 authentication database for ACAP: + + Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) + C: a001 AUTHENTICATE "CRAM-MD5" + S: + "<1896.697170952@postoffice.reston.mci.net>" + C: "tim b913a602c7eda7a495b4e6e7334d3890" + S: a001 NO (TRANSITION-NEEDED) + "Please change your password, or use TLS to login" + C: a002 STARTTLS + S: a002 OK "Begin TLS negotiation now" + + S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") + C: a003 AUTHENTICATE "PLAIN" {21+} + C: timtanstaaftanstaaf + S: a003 OK CRAM-MD5 password initialized + + Note: In this example, represents a single ASCII NUL octet. + + Here is an example session where a client erroneously attempts to + use PLAIN prior to starting TLS: + + Example: S: * ACAP (SASL "CRAM-MD5" "PLAIN") (STARTTLS) + C: a001 AUTHENTICATE "PLAIN" {21} + S: a001 NO (ENCRYPT-NEEDED) + "Can't use PLAIN without encryption" + +7. imaps and pop3s ports + + The common practice of using a separate port for a "secure" version + of each protocol has a number of disadvantages in the IMAP [IMAP4], + ACAP [ACAP] and POP [POP3] environment. Rather than using the best + security available, it means that clients have to be explicitly + configured to use the separate secure port or suffer the + performance loss of probing for active ports. Furthermore this is + even more serious as it would require a new URL scheme which could + only be resolved by TLS-enabled clients. + + Separate "imaps" and "pop3s" ports were registered for use with + TLS. Use of these ports is discouraged in favor of the STARTTLS or + STLS command. + + One of the arguments used in favor of the separate port technique + is that it simplifies configuration of firewalls which filter by IP + port. However, a quality server implementation running on the + + + +Newman [Page 8] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + + standard port can be configured to require use of the STARTTLS + command or a suitably strong SASL mechanism for non-local + connections. This provides superior functionality as the client + need not be re-configured for use outside the firewall and faster + non-clear-text SASL mechanisms may be acceptable to many sites for + non-local connections. + +8. IANA Considerations + + This document constitutes registration of the "STARTTLS" IMAP4 + capability as required by section 7.2.1 of RFC 2060. + + This document defines the "STLS" POP3 capability as follows: + + CAPA tag: STLS + Arguments: none + Added commands: STLS + Standard commands affected: May enable USER/PASS as a side-effect. + CAPA command should be re-issued after successful completion. + Announced states/Valid states: AUTHORIZATION state only. + Specification reference: this memo + + This document defines the "STARTTLS" ACAP capability as follows: + + Capability name: STARTTLS + Capability keyword: STARTTLS + Capability arguments: none + Published Specification(s): this memo + Person and email address for further information: + see author's address section below + + This document defines the "PLAIN" SASL mechanism as follows: + + SASL mechanism name: PLAIN + Security Considerations: See section 9 of this memo + Published specification: this memo + Person & email address to contact for further information: + see author's address section below + Intended usage: COMMON + Author/Change controller: see author's address section below + +9. Security Considerations + + TLS only provides protection for data sent over a network + connection. Messages transferred over IMAP or POP3 are still + available to server administrators and usually subject to + eavesdropping, tampering and forgery when transmitted through SMTP + or NNTP. TLS is no substitute for an end-to-end message security + + + +Newman [Page 9] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + + mechanism using MIME security multiparts [MIME-SEC]. + + An active attacker can remove STARTTLS from the capability list. + In order to detect such an attack, clients SHOULD either warn the + user when session privacy is not active, or be configurable to + refuse to proceed without an acceptable level of security. + + Both client and server MUST verify the level of protection + negotiated by TLS is adequate for local security policy, and + terminate the TCP connection if it is not. An active attacker can + always cause a down-negotiation to the weakest authentication + mechanism or cipher suite available. For this reason, + implementations need to be configurable to refuse weak mechanisms + or cipher suites. + + Any protocol interactions prior to the TLS handshake are performed + in the clear and can be modified by an active attacker. For this + reason, clients SHOULD discard cached information about server + capabilities advertised prior to the start of the TLS handshake. + + Clients are encouraged to clearly distinguish between a level of + encryption known to be vulnerable to a reasonable attack using + modern hardware (such as encryption with a 40-bit key) and one + which is believed to be safe from such an attack. + + When the PLAIN mechanism (or the IMAP4 LOGIN or POP3 PASS command) + is used, the server gains the ability to impersonate the user to + all services with the same password regardless of any encryption + provided by TLS or other network privacy mechanisms. Stronger SASL + authentication mechanisms such as Kerberos address this issue. + + Use of clear-text login mechanisms (e.g., the IMAP4 LOGIN command, + POP3 PASS command or the PLAIN mechanism) without a suitable + encryption layer such as that provided by TLS expose the user's + password to a common network eavesdropping attack. Therefore, the + PLAIN mechanism MUST NOT be implemented unless a suitable + encryption layer, such as that provided by TLS is also implemented. + + Additional security requirements are discussed in section 2. + +10. References + + [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: + ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, + November 1997. + + [ACAP] Newman, Myers, "ACAP -- Application Configuration Access + Protocol", RFC 2244, Innosoft, Netscape, November 1997. + + + +Newman [Page 10] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + + [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension + for Simple Challenge/Response", RFC 2195, MCI, September 1997. + + [IMAP4] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, University of Washington, December 1996. + + [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731, + Carnegie-Mellon University, December 1994. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, Harvard University, March 1997. + + [MIME-SEC] Galvin, Murphy, Crocker, Freed, "Security Multiparts for + MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Trusted + Information Systems, CyberCash, Innosoft International, October + 1995. + + [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC + 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. + + [POP3EXT] Gellens, Newman, Lundblade "POP3 Extension Mechanism", + Work in progress. + + [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, + Carnegie Mellon, December 1994. + + [SASL] Myers, J., "Simple Authentication and Security Layer + (SASL)", RFC 2222, Netscape Communications, October 1997. + + [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", Work in + progress. + + [UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646", + RFC 2279, Alis Technologies, January 1998. + +11. Author's Address + + Chris Newman + Innosoft International, Inc. + 1050 Lakes Drive + West Covina, CA 91790 USA + + Email: chris.newman@innosoft.com + + + + + + + + +Newman [Page 11] diff --git a/RFC/lan-mail-protocols b/RFC/lan-mail-protocols new file mode 100644 index 00000000..13e984ee --- /dev/null +++ b/RFC/lan-mail-protocols @@ -0,0 +1,1330 @@ + + SERVING DESKTOP COMPUTERS USING A CENTRAL MAIL SERVER ON AN INTERNET + + + _________________________________________________________________ + + Author + John Wobus, jmwobus@syr.edu (corrections welcome) + + Date + 2/4/1997 + + This file + http://web.syr.edu/~jmwobus/comfaqs/lan-mail-protocols.html + + Other LAN Info + http://web.syr.edu/~jmwobus/lans/ + + + _________________________________________________________________ + +Contents + + * Introduction + * List of Protocols and RFCs + * Other Sources of Information + * Capabilities of Well-known mail clients + * List of Implementations + * Some other packages for desktop systems + * Key and Other Issues + + + _________________________________________________________________ + +Introduction + + + + There are advantages to having a central server receive the mail + destined to desktop computers and having the desktop computer collect + the mail from the server on demand: + * Your desktop computer may be down quite a bit and less network + bandwidth and less of the processing resources of the sending + computer are used if the computer receiving your mail is ready to + receive. + * Some people use more than one desktop computer to read mail. + * A desktop computer may not have the resources to store all the + mail you receive. + * It can make your e-mail address more like other users'. + + + + The easiest way to "implement" this is to run the central mail server + like any multi-user system: let people sign on to it and use some mail + utility. Then desktop computer users can use "terminal sessions" to + sign on to the central mail server and read their mail (e.g. with Unix + "pine"). This has the disadvantage of making the desktop computer + users learn and use the central mail server's procedures. + + SMTP, the "internet" mail protocol used to deliver mail between + multi-user systems only supports mail transfer initiated by the sender + to actually, it has a method to initiate reception, but the method + didn't catch on and is not used). Other protocols have been devised to + allow a desktop computer to request transfer of mail, thus able to + make use of a central server. These include the published variants of + POP, IMAP, and DMSP. + + POP, POP2, POP3 + + + + These are rather minimal and are designed to be so. The three are + similar but not enough alike to be interoperable. They are basically + designed to identify the user by username and password, to transfer + the mail from server to desktop computer and to delete the mail + transferred. It is assumed that SMTP will be used to send mail. + Messages can be retrieved individually, but the only information you + can get about a message without transferring it is its length in + bytes-- useful for desktop computers with limited storage. + + POP3 has a number of optional extensions including Xtnd Xmit which + allows clients to send mail through the POP3 session rather than using + SMTP. Another extension is APOP which allows RSA MD5 encryption of + passwords passed over the network. + + POP3 is now by far the most-used variant of POP, but POP2 may still be + used at a few sites. POP3 has a couple of optional extensions: one to + avoid sending passwords, and one to aid in reading bulletin boards. + + IMAP2, IMAP2BIS, IMAP3, IMAP4, IMAP4REV1 + + + + The IMAP family is similar to the POP family, but also gives clients a + way to do string searches through mail that still resides on the + server. This is designed to allow the desktop computer to be more + selective as to which mail will be transferred. The POP protocols, on + the other hand, are designed for simpler server software. + + IMAP2 is used quite a bit. IMAP3 is an incompatible offshoot that has + not been implemented much. IMAP4 is a relatively recent extension of + IMAP2 which makes the servers cognizant of the MIME-structure of a + message. IMAP2bis was the original name of IMAP4, which has since been + refined, but there are/were some implementations of IMAP2bis that are + not IMAP4 compliant. IMAP4 also extends IMAP to have many other + features including some of DMSP's. IMAP4rev1 includes a few + enhancements to IMAP4. + + ACAP + + + + ACAP (Application Configuration Access Protocol), formerly IMSP + (Interactive Mail Support Protocol), is a protocol which is being + developed to compliment IMAP4 by offering related e-mail services + beyond the scope of IMAP4. It includes the ability to subscribe find & + subscribe to bulletin boards, mailboxes, and to find and search + address books. + + IMAP VS POP + + + + As of this writing (10/96), there are a many more POP than IMAP client + implementations and an Internet Service Provider is much more likely + to provide POP3 service than IMAP4. But interest in IMAP4 is growing + with big-time software houses announcing support. IMAP4 has more + features, basically designed to support a model where users store + their received mail on a server rather than on their own computer. The + big advantage cited for IMAP is that people who "do e-mail" from + different computers at different times have the same access to their + message store from any of the client-computers they use. The cost of + this model (aside from issues such as the complexity and the + availability of implementations) is in running a server with + sufficient space for the clients' message stores. With personal + computer disks now often above a gigabyte (presumeably growing to 10s + of gigabytes over the next few years) and multimedia messaging in our + future, people storing e-mail on their own hard disk will have a lot + of space and ways to use it. A central store serving 10-20 users will + not be overly difficult, but one for 1,000 or 10,000 users will be + very large (terabytes?) if it is to offer comparable space. The + question comes down to the tradeoff between the advantage to users who + computer-hop against the costs of managing the large amount of central + store. See also online document imap.vs.pop.html (reference below) and + section below "Issue of Remote Access". + + DMSP + + + + Also know as PCMAIL. Desktop computers can use this protocol to both + send and receive mail. The system is designed around the idea that + each user can own more than one workstation; however, the system + doesn't seem to handle the idea of a "public workstation" very well. + The desktop computers are assumed to hold state information about the + mail, a directory so to speak, and when the desktop computer is + connected to the server, this directory is updated to "reality". Note: + DMSP never gained the following of IMAP or POP and I've heard the + software is no longer available. + + WHO USES THESE PROTOCOLS? + + + + These protocols were designed and implemented mostly by + Internet-connected universities with some participation by other + Internet-connected research institutions. They were certainly devised + to handle the type of electronic mail that universities must do. A + typical site has probably 10 to 10,000 desktop computers and has an + Internet connection and also runs Unix, giving them the Unix sysadmin + expertise that makes running a Unix-based server attractive. Most of + the servers listed here run under Unix though some run under other + large systems and as time goes on, we are seeing more servers that run + on PCs and Macintoshes. + + A more recent use of these protocols has been by Internet Service + Providers and their customers. Internet Service Providers require a + way to offer e-mail services to however many customers they provide, + to customers who are connected to the network only part of the time. + Like a campus application, they may have 10 or 10,000 customers to + serve. These protocols offer a distinct advantage over SMTP for such + purposes and form an attractive complementary e-mail service for WWW + users. + + DISADVANTAGES + + + + There are a number of disadvantages associated with the use of these + protocols: + * since these have long been no more than a small part of the e-mail + market, software using these methods is often incompatible with + other useful and/or well-known software. A couple of examples are: + + Use of mail-enabled applications on desktop computers (there + is no fundamental reason that mail software using these + protocols can't provide the API used by mail-enabled + applications, but in general this hasn't come about yet) + + Use of the usual Unix mail readers & the Unix .forward files. + * since the server is holding mail for the person, the person can + use the server for storage. This leaves the potential for all the + disk-space problems inherent in shared disks: people hogging + disk-space or forgetting to clean up, etc. + * sizing the server: a perennial question people ask is "How big a + machine do I need to serve my campus (or department, or + whatever)". Naturally no one can give a straight answer because it + depends upon so many factors. + + ISSUE OF REMOTE ACCESS + + + + Modern commercial e-mail packages typically have features designed to + assist in remote access of ones e-mail. Features include: + * ability to download mail through a modem + * ability to synchronize two different systems which you are using + to read your e-mail by plugging them together. + + + + Any method of reading e-mail using PCs or Macintoshes can be used + remotely via remote control (the "PCanywhere(tm)" method, e.g. by + dialing up your own office PC/Macintosh and using one of the several + kinds of software that allow you to control your PC/Macintosh over the + phone). Also, any LAN-based method can be used by using one of the + several methods of providing the same protocol support over dialup + lines as are on LANs (SLIP or PPP for the above-mentioned, + TCP/IP-based protocols, ARA for Appletalk-based protocols, etc, and + sometimes using two different protocols, one incapsulated in the + other) under the constraint that any operations that use the network + will be much slower. Also, POP3 is sometime used directly over modems + (for example, Eudora can be used in this manner). + + The ideal protocol for remote access would not penalize the user for + the much slower communications speed (usually slower by a factor of + 100: note that a lot of LAN-based software was written without regard + to minimizing the necessary communication, thus is really hurt by such + slow speeds), yet would allow the same software to run both remotely + and locally, with a wonderful user interface. It would also not be + overly expensive in communications equipment or services. This is a + difficult set of objectives and the above-three protocols can achieve + some of them for some users, but what they actually achieve depends a + lot on the user's pattern of e-mail usage. If a user reads just a + small amount of mail, then we would not worry about the length of time + necessary to download it remotely with POP3, but if the person + receives a lot of mail, but just wants to read a small amount of it at + home, then with IMAP2, they could pick and choose what to read, + eliminating some download time. If someone is paying for the telephone + line time (possibly the user if it is a long distance call; in any + case, the institution pays a monthly fee for each line it offers, + which is dependent upon how many users it is serving, how often they + call, and how long their calls are) then IMAP2's natural method of + usage which requires the phone call to remain while a user is reading, + poking around, sending, and rearranging mail can be much more costly + than using POP3 if one call is used to quickly download all the mail + and another later call is used to send any replies. Thus with POP3 a + user might have two 1 minute calls before and after a 30 minute e-mail + session instead of keeping the call for 30 minutes with IMAP2, and + each phone line the institution offers could be serving 15 times as + many such users who would each pay a lot less in long-distance phone + bills. Note that with the advent of multimedia mail (see MIME below) + whose messages can be very large, it is possible that downloading even + one message that you end up not reading remotely could ruin such a + nice-sounding scenario. + + Note that with the growth of Internet Service Providers, remote access + is becoming the normal way for many people to do their e-mail, and + offering such services is one of the major growth areas for POP and + IMAP. + + MIME + + + + MIME (Multipurpose Internet Mail Extensions) is a relatively new + Internet standard for the format for messages with multiple parts, and + with non-ASCII data. Any client that can import or export files can + use MIME in a clumsy way if you have a program to create and/or decode + a MIME message. Some clients have built-in features to do this. + Client-server mail protocols generally only deal with entire messages, + and can retrieve MIME messages as well as any other messages since + MIME was carefully designed to be transparent to existing mail + systems. However, IMAP4 has features to allow retrieval of individual + parts of MIME-encoded messages. The chart below lists whether a + package has MIME support. Servers for protocols that don't offer any + special MIME features are marked na for Not Applicable since they need + do nothing for users to use MIME. All IMAP4 servers can also do this, + but the chart lists whether they include explicit MIME support. + + APPROACHES NOT COVERED BY THIS MEMO + * Proprietary protocols + * file sharing + * APIs + * X.400. + + + + Vendors can invent their own protocols similar to those listed above, + and some have. + + LAN e-mail can also be implemented using file sharing, e.g. using NFS + to allow separate Unix workstations to share the same mail spool area + just as if it were mail being stored on one system, or using Novell's + SMF (Simple Message Format) in a Novell file server. If the + applications are written so that they are careful to lock files + correctly, then this works. An advantage is that any network file + protocol can be used and the e-mail application can be somewhat + independent of the file protocol. For example, Unix systems could use + either AFS or NFS. Pegasus is a PC & Mac application that uses Novell + file service to do something similar. Specifications for client-server + interaction consist of the file service protocol along with the server + directory structures & conventions used for storing e-mail. + + A very popular approach with commercial vendors is the use of APIs. + The client talks to the server using an API (Applications Programming + Interface), i.e., a set of subroutine/procedure library call + definitions for a library providing subroutines/procedures to send, + receive, and manipulate e-mail. With the use of any remote procedure + call mechanism, the client can be located on a different computer from + the server. This allows some mixing and matching of RPC mechanisms, + underlying protocol stacks and APIs: e.g., a vendor defines an API, + and it can be run over IPX or TCP/IP, in each case over the protocol + stack's RPC mechanism. There are a number of APIs now being pushed by + vendors: MAPI (Microsoft); VIM (Lotus); AOCE (Apple). These API's have + been the basis for numerous mail-enabled applications: e.g. a word + processor that allows you to send or receive documents through e-mail + simply uses one of these APIs allowing it to communicate with any + server supporting the same API. Specifications for client-server + interaction consist of the protocol stack up to the RPC protocol, then + the API itself. + + Note that though the API approach in combination with remote procedure + calls allows one to implement client-server e-mail without the use of + the protocols covered by this document (IMAP, POP, etc), that there is + no theoretical reason why such APIs can't be used in an IMAP or POP + environment. The necessary software would be a "driver" or piece of + "middleware" that provides the APIs calls to mail-enabled applications + and uses POP, IMAP, or whatever over a LAN to reach a server. The + advantages/disadvantages of such an approach as compared to the use of + RPCs is open to debate. UniPalm's Mail-IT is an example of client + software that provides MAPI within the client and uses POP3 to access + the server. + + X.400 is the message transport defined for use between + telecommunications vendors and customers by the international + consortium of national standards bodies known as ISO. It roughly + corresponds to TCP/IP's SMTP and RFC822 header format. A consortium of + X.400 vendors (XAPIA) have developed an API for X.400 applications + called CMC. + + LDAP + + + + LDAP is a protocol (the Lightweight Directory Access Protocol) being + incorporated in some clients as an Internet way for the client to get + information about e-mail addresses from a server, i.e. to give you the + capability to type in someone's name and have the mail client software + retrieve the address from a server-based directory. LDAP also has + other uses. There are plans to incorporate LDAP clients into some IMAP + and POP clients. LDAP is essentially an Internet-based, simplified + X.500-like protocol and one of the original intentions of its creators + was to be gatewayed to X.500, thus giving relatively simple Internet + clients access to X.500 servers. Both LDAP and X.500 provide a method + for naming, retrieving, and searching fields in a directory, but do + not define the field-names or what is supposed to go in the fields. + Thus server/client interoperability requires further conventions. + + JAVA + + + + Java is a programming language currently (1996) touted as a tool for + web-based applications. It can affect the use of LAN protocols in a + number of ways: first of all, POP or IMAP clients can be written in + Java, using its cross-platform development capabilities to create + version for a number of platforms. Second, clients could be written as + "Applets", i.e. applications designed to be downloaded into web + browsers such as Netscape from a server. With such a design, a user + would only need access to a web browser to see their e-mail, e.g. drop + into a library and see your e-mail from one of its Internet-browser + kyosks. Applets are not normally allowed to access the + client-machine's disk files (which would result in too much risk when + browsing the Internet from the kind of people who develop computer + viruses), so such an application fits a little better into the IMAP + model (server storage of e-mail folders) than the POP model (client + storage of e-mail folders). Thirdly, Applets enable more practical use + of e-mail clients that use non-standard protocols rather than POP or + IMAP; interoperability is achieved because the server itself + distributes a compatible client applet right when the user accesses + the server. + _________________________________________________________________ + +List of Protocols and RFCs + + + + Note: for up-to-date information on the RFCs, get an index from an RFC + repository. For up-to-date information on the state of each RFC as to + the Internet Standards, see the most recent RFC called "Internet + Official Protocol Standards". + +Name: Simple Mail Transfer Protocol +Nickname: SMTP +Document: RFC 821 (Postel, August 1982) +TCP-port: 25 +Status: Internet standard (STD 10) + +Name: Post Office Protocol, Version 2 +Nickname: POP2 +Document: RFC 937 (Butler et al, February 1985) +TCP-port: 109 +Status: Functionally replaced by incompatible POP3 but still used some + +Name: Post Office Protocol, Version 3 +Nickname: POP3 +Document: RFC 1939 (Myers & Rose, May 1996) +TCP-port: 110 (109 also often used) +Status: In use, standards track +Sites: UC Irvine, MIT + +Name Post Office Protocol, Version 3 Authentication command +Nickname: POP3 AUTH +Document: RFC1734 (Myers, December 1994) + +Name: Post Office Protocol, Version 3 Extended Service Offerings +Nickname: POP3 XTND +Document: RFC 1082 (Rose, November 1988) + +Name: Distributed Mail Service Protocol +Nickname: DMSP, Pcmail +Document: RFC 1056 (Lambert, June 1988) +TCP-port: 158 +Status: Used very little +Sites: MIT + +Name: Interactive Mail Access Protocol, Version 2 +Nickname: IMAP2 +Document: RFC 1176 (Crispin, August 1990) +TCP-port: 143 +Status: In use, being replaced by upward-compatible IMAP4 +Sites: Stanford, U Washington + +Name: Interactive Mail Access Protocol, Version 2bis +Nickname: IMAP2bis +TCP-port: 143 +Status: Experimental, but in use, being replaced by upward-compatible IMAP4 + +Name: Interactive Mail Access Protocol, Version 3 +Nickname: IMAP3 +Document: RFC 1203 (Rice, February 1991) +TCP-port: 220 +Status: Historical, not used +Sites: Stanford + +Name: Internet Message Access Protocol, Version 4 +Nickname: IMAP4 +Document: RFC 1730 (Crispin, December 1994) +TCP-port: 143 +Status: Implementations exist, being replaced by revised version IMAP4rev1 +Sites: U Washington +Related: RFC 1731 (Myers, December 1994), + RFC 1732 (Crispin, December 1994), + RFC 1733 (Crispin, December 1994) + +Name: Internet Message Access Protocol, Version 4rev1 +Nickname: IMAP4rev1 +Document: RFC 2060 (Crispin, December 1996) +TCP-port: 143 +Status: Being implemented, Standards track +Sites: U Washington +Related: RFC 2061 (Crispin, December 1996), + RFC 2062 (Crispin, December 1996) + +Name: Interactive Mail Support Protocol +Nickname: IMSP +Document: Draft RFC: ? (Myers, June 1995) +TCP Port: 406 +Status: Experimental, renamed ACAP +Sites: Carnegie Mellon + +Name: Application Configuratino Access Protocol +Nickname: ACAP +Document: Draft RFC: ? (Myers, June 1996) +Status: ? +Sites: Carnegie Mellon + + + + Note: The "I" in IMAP used to stand for "Interactive". Now it stands + for "Internet" and the "M" stands for "Message" rather than "Mail". + Also, Internet drafts are available at ds.internic.net, munnari.oz.au, + and nic.nordu.net in directory internet-drafts. IMAP2bis is + essentially an early version of IMAP4. + _________________________________________________________________ + +Other Sources of Information + + My own info + http://web.syr.edu/~jmwobus/lans/#imappop + http://web.syr.edu/~jmwobus/internet/ + + The IMAP Connection web site + + http://www.imap.org + Main page + + http://www.imap.org/products.html + List of IMAP implementations + + http://www.imap.org/imap.vs.pop.brief.html + Outlines differences between IMAP and POP. + + http://www.imap.org/imap.vs.pop.html + Same, with more detail. + + http://www.imap.org/biblio.html + Bibliography of IMAP Documents. + + Information from University of Washington + http://www.washington.edu/imap/ + + By anonymous ftp from ftp.cac.washington.edu + mail/* (miscellaneous information) + + Information from andrew2.andrew.cmu.edu + + http://andrew2.andrew.cmu.edu/cyrus/email/clients-IMAP.html + List of IMAP clients + + http://andrew2.andrew.cmu.edu/cyrus/acap/acap.html + The ACAP Home Page + + Mailing lists: + pop@jhunix.hcf.jhu.edu + imap@cac.washington.edu + CW-EMAIL@EARNCC.EARN.NET + + By anonymous ftp from rtfm.mit.edu + This memo + comp.os.msdos.mail-news FAQ Memo + Mini FAQ on client-server mail protocols (similar to this memo + but shorter and more practical: + ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/mailclient-fa + q) + + Consortium + "The IMAP Consortium" (Getting under way as of March 1995). + + Page on MAPI API + http://www.wp.com/davidb/emapi.html + + + _________________________________________________________________ + +Capabilities of Well-known mail clients + + + + This section covers what I've been able to find out so far about the + well-known mail clients' ability to retrieve mail from a POP or IMAP + server. + +Client POP3 IMAP MIME +------ ---- ---- ---- +Apple PowerMail client ? ? ? +BeyondMail yes planned- yes +CE QuickMail client planned= planned= yes +Claris Emailer yes ? yes +DaVinci eMAIL client yes* ? yes* +Lotus cc:Mail Client no no no +Lotus Notes mail client no no ? +Microsoft Mail client no no no +Microsoft Exchange client yes+ no yes& +Netscape yes planned% yes + +Notes: +(-) Announced early 1996: target delivery: 4th quarter 1996. +(=) CE plans to rename the successor to their current client + QuickMail LAN, while introducing both a free and a commercial + POP3 client, then upgrade the commercial POP3 client to also + support IMAP. +(*) DaVinci SMTP eMAIL: I'm not sure if this is different from + the normal DaVinci client. +(+) Requires Internet Mail Client for Exhange, downloadable from + http://www.windows.microsoft.com or included in "Microsoft Plus". +(&) qp/base64 +(%) Planned for Netscape 4.0 + + + + + _________________________________________________________________ + +List of Implementations + + + +Prot Computer Implementation End MIME Source +------ ---------- ------------------- ---- ---- ------------------------------- +DMSP PC pc-epsilon (3.1) clnt ? allspice.lcs.mit.edu +DMSP PC pc-netmail (3.1) clnt ? allspice.lcs.mit.edu +DMSP PC pc-reader clnt ? allspice.lcs.mit.edu +DMSP Unix Pcmail 3.1 reposit. srvr na allspice.lcs.mit.edu +DMSP Unix/EMACS Pcmail 4.2 clnt ? allspice.lcs.mit.edu +DMSP PC PC/TCP 2.3 clnt ? FTP Software 8/4/94 +DMSP OS/2 PC/TCP clnt ? FTP Software +DMSP OS/2 TCP/2 clnt ? Essex Systems +DMSP OS/2 TCP/2 SERVER PACK srvr na Essex Systems +DMSP OS/2 TCP/2 ADV CLIENT clnt ? Essex Systems +IMAP1 MacOS MacMS 2.2.1 (obs) clnt no sumex-aim.stanford.edu* 7/13/95 +IMAP24 MacOS Mailstrom 1.04 clnt no sumex-aim.stanford.edu* 11/7/93 +IMAP24 MacOS Mailstrom 1.05 clnt no ftp-camis.stanford.edu 5/21/96 +IMAP24 MacOS Mailstrom 2(beta) clnt yes Tree Star Inc. 12/18/96 +IMAP? MacOS Mailstrom clnt ? lindy.stanford.edu 9/22/95 +IMAP? MacOS Mulberry (beta) clnt no mulberry@dial.pipex.com 7/30/96 +IMAP? MacOS Mulberry 1.1 clnt ? CyDaSoft 12/19/96 +IMAPb4 Mac/OT SIMEON 4.1 clnt yes ESYS Corp www.esys.ca 8/5/96 +IMAPb4 MacOS SIMEON 4.1 clnt yes ESYS Corp www.esys.ca 8/5/96 +IMAPb4 MS-WIN SIMEON 4.1 clnt yes ESYS Corp www.esys.ca 8/5/96 +IMAPb4 WIN32 SIMEON 4.1 clnt yes ESYS Corp www.esys.ca 8/5/96 +IMAPb4 Unix/Motif SIMEON 4.1 clnt yes ESYS Corp www.esys.ca 8/5/96 +IMAP4 ? SIMEON SERVER srvr ? ESYS Corp www.esys.ca 8/1/96 +IMAP2 MacOS PathWay clnt no The Wollongong Group 2/25/94 +IMAP2 Unix/X PathWay clnt no The Wollongong Group 2/25/94 +POP3 MacOS PathWay clnt no The Wollongong Group 2/25/94 +POP3 Unix/X PathWay clnt no The Wollongong Group 2/25/94 +POP3 OS/2 ? (in testing) srvr no kf5mg@computek.net 11/28/95 +POP2 MacOS MacPOP 1.5 clnt ? ? 10/24/94 +POP2 MS-DOS PC POP 2.1 clnt ? ? 10/24/94 +POP3 MacOS TCP/Connect II clnt ? InterCon Systems Corp +POP3 MS-WIN TCP/Connect II f W clnt yes InterCon Systems Corp 7/8/94 +POP3 NeXT EasyMail clnt yes ftp.cac.washington.edu 11/7/93 +IMAP2 NeXT MailManager srvr yes ftp.cac.washington.edu 11/7/93 +IMAP2 TOPS20 MAPSER srvr na ? 11/7/93 +IMAP2 Unix imap kit srvr na ftp.cac.washington.edu 2/1/94 +POP23 Unix imap kit srvr na ftp.cac.washington.edu 2/1/94 +POP23 Unix IPOP srvr na ftp.cac.washington.edu 2/23/96 +IMAP4 Unix imap4 kit (alpha) srvr na ftp.cac.washington.edu 5/31/95 +IMAP24 Unix Pine 3.90 clnt yes ftp.cac.washington.edu 9/23/94 +IMAP24 Unix Pine 3.91 clnt yes ftp.cac.washington.edu 10/14/94 +IMAP2b Unix Pine 3.95 clnt yes ftp.cac.washington.edu 7/30/96 +IMAP24 Unix Pine 4.0 (future) clnt yes ftp.cac.washington.edu 7/30/96 +IMAP24 MS-DOSl+ PC-Pine 3.90 clnt yes ftp.cac.washington.edu 9/23/94 +IMAP24 MS-DOSl+ PC-Pine 3.91 clnt yes ftp.cac.washington.edu 10/14/94 +POP23r Unix popclient x.x (rep) clnt no Renamed 'fetchmail' 10/7/96 +IMAPb4 Unix popclient x.x (rep) clnt no Renamed 'fetchmail' 10/7/96 +POP23r Unix fetchmail 2.0 clnt no www.ccil.org/~esr 11/19/96 +IMAPb4 Unix fetchmail 2.0 clnt no www.ccil.org/~esr 11/19/96 +POP23r Unix fetchmail 2.2 clnt no www.ccil.org/~esr 12/10/96 +IMAPb4 Unix fetchmail 2.2 clnt no www.ccil.org/~esr 12/10/96 +POP23r Unix fetchmail 2.3 clnt no www.ccil.org/~esr 12/18/96 +POP3k Unix fetchmail 2.3 clnt no www.ccil.org/~esr 12/18/96 +IMAPb4 Unix fetchmail 2.3 clnt no www.ccil.org/~esr 12/18/96 +POP23r Unix fetchmail 2.6 clnt no www.ccil.org/~esr 12/18/96 +POP3k Unix fetchmail 2.6 clnt no www.ccil.org/~esr 12/18/96 +IMAPb4 Unix fetchmail 2.6 clnt no www.ccil.org/~esr 12/18/96 +POP23r Unix fetchmail 3.3 clnt no www.ccil.org/~esr 2/4/97 +POP3k Unix fetchmail 3.3 clnt no www.ccil.org/~esr 2/4/97 +IMAPb4 Unix fetchmail 3.3 clnt no www.ccil.org/~esr 2/4/97 +POP? Unix gwpop clnt ? ftp.pasteur.fr 2/9/96 +POP? Unix popc clnt ? ftp.imag.fr 2/9/96 +POP? Unix popmail clnt ? ftp.cic.net 2/9/96 +POP? Unix movemail clnt ? GNU 2/9/96 +IMAP2 VMS Pine 3.88 port clnt yes vms.huji.ac.il 4/12/94 +IMAP? VMS Pine in PMDF 4.3 clnt ? Innosoft 4/1/94 +IMAP2 VMS ImapD port srvr yes vms.huji.ac.il 4/12/94 +POP3u Win3/95/NT Navigator 2.x clnt yes Netscape 7/29/96 +IMAP? Windows? pcMail (future) clnt ? OzMail 3/19/96 +POP? Solaris Navigator 3.0b4(fut)clnt ? Netscape 6/25/96 +IMAP4 ? Navigator 4.0 (fut) clnt yes Netscape 7/30/96 +IMAP4 MacOS Navigator 4.0 (fut) clnt yes Netscape 12/18/96 +POP3 Macintosh6 Eudora 1.3.1 clnt no ftp.qualcomm.com 7/14/94 +POP3 Mac7/PM7 Eudora 1.5.3 clnt yes ftp.qualcomm.com 8/4/95 +POP3mr Macintosh7 Eudora 2.0.2 clnt yes Qualcomm 5/10/94 +POP3mr Mac7/PM7 Eudora 2.0.3 clnt yes Qualcomm 9/13/94 +POP3mrkMac7/PM7 Eudora 2.1 clnt yes Qualcomm 9/13/94 +POP3mrkMac7/PM7 Eudora 2.1.1 clnt yes Qualcomm 8/4/95 +POP3mrkMac7/PM7 Eudora 2.1.2 clnt yes Qualcomm 8/4/95 +POP3mrkMac7/PM7 Eudora 2.1.3 clnt yes Qualcomm 8/4/95 +POP3 MS-WINw Eudora 1.4.4 clnt yes ftp.qualcomm.com 6/23/95 +POP3 MS-WINw Eudora 1.5.2b1 clnt yes ftp.qualcomm.com 8/4/95 +POP3 MS-WINw Eudora 2.0.3 clnt yes Qualcomm 9/13/94 +POP3 MS-WINw Eudora 2.1.1 clnt yes Qualcomm 8/4/95 +POP3 WIN32 Eudora Pro 2.2b8 clnt yes Qualcomm 12/5/95 +POP3 WIN3/95/NT Eudora Pro ? clnt yes Qualcomm 7/29/96 +POP3 Mac Eudora Pro 3.0 clnt yes Qualcomm 8/14/96 +POP3 OS/2 PMMail 11 clnt yes hobbes.nmsu.edu 6/2/95 +POP3 OS/2 POP3D 12 srvr yes hobbes.nmsu.edu 6/2/95 +POP3 OS/2 POP3D 14A srvr yes hobbes.nmsu.edu 9/12/95 +POP3 OS/2 POP3D 14B srvr yes hobbes.nmsu.edu 4/5/96 +POP? OS/2 popsrv99.zip srvr ? hobbes.nmsu.edu 2/15/96 +POP3r OS/2 popsrv10.zip srvr na ftp-os2.mnsu.edu 3/15/96 +POP3 MS-WIN Mi'Mail clnt yes http://www.irisoft.be 6/30/95 + +IMAP2b Unix/XM ML 1.3.1 clnt yes ftp-camis.stanford.edu 7/13/95 +IMAP24 Unix/XM ML 2.0 (future) clnt yes Stanford 7/13/95 +IMAP1 Unix imapd 3.2 (obs) srvr na ftp-camis.stanford.edu 7/13/95 +IMAP2b Unix imapd 3.4/UW srvr ? ftp.cac.washington.edu 12/13/94 +IMAP2b Unix imapd 3.5/UW srvr ? ftp.cac.washington.edu 4/25/95 +IMAP2b Unix imapd 3.6.BETA srvr ? ftp.cac.washington.edu 4/25/95 +IMAP2b Unix imapd 4.0/UW (fut) srvr ? U Wash 4/25/95 +IMAP? Unix imapd 8.0(124) srvr ? U Wash 1/31/97 +IMAP? Unix imapd 9.0(161) srvr ? U Wash 1/31/97 +IMAP4 ? imap-4 srvr yes ftp.cac.washington.edu 10/25/96 +POP3u ? imap-4 srvr na ftp.cac.washington.edu 10/25/96 +IMAP4 ? imap-4.1 ALPHA srvr yes ftp.cac.washington.edu 10/25/96 +POP3u ? imap-4.1 ALPHA srvr na ftp.cac.washington.edu 10/25/96 +IMAP? Unix/X Palm (in dev) clnt ? UMiami 11/7/93 +IMAP? Unix/X Cyrus (dev on hold) clnt yes CMU 10/4/94 +IMAP Unix Cyrus 1.4 srvr yes ftp.andrew.cmu.edu 12/1/95 +POP3 Unix Cyrus 1.4 srvr na ftp.andrew.cmu.edu 12/1/95 +KPOP Unix Cyrus 1.4 srvr na ftp.andrew.cmu.edu 12/1/95 +POP3u Unix Cyrus ? srvr na 3/12/96 +IMAP41 Unix Cyrus 1.5 srvr yes ftp.andrew.cmu.edu 1/3/97 +POP3k Unix Cyrus 1.5 srvr na ftp.andrew.cmu.edu 1/3/97 +KPOP Unix Cyrus 1.5 srvr na ftp.andrew.cmu.edu 1/3/97 +IMAP4 ? Futr Andrew Msg Sys ? ? Carnegie-Mellon 9/20/94 +IMAP? Xrx Lsp Mc Yes-Way clnt yes Stanford U 11/7/93 +IMAP2b MacOS ECSMail clnt yes ESYS Corp www.esys.ca 12/16/96 +IMAP2b MS-WINw ECSMail clnt yes ESYS Corp www.esys.ca 12/16/96 +IMAP2 Unix/XM ECSMail Motif clnt yes ESYS Corp www.esys.ca 12/16/96 +IMAP2b Solaris ECSMail clnt yes ESYS Corp www.esys.ca 12/16/96 +IMAP2 MS-DOS ECSMail DOS clnt yes ESYS Corp www.esys.ca 12/16/96 +IMAP? NT ECSMail clnt yes ESYS Corp www.esys.ca 12/16/96 +IMAP? OS/2 ECSMail OS/2 clnt yes ESYS Corp www.esys.ca 12/16/96 +IMAP? Unix UMAIL clnt no umail@umail.umd.edu 11/7/93 +IMAP? Unix MS clnt no ftp.cac.washington.edu 11/7/93 +IMAP2 MS-WIN PathWay clnt no The Wollongong Group 2/25/94 +POP3 MS-WIN PathWay clnt no The Wollongong Group 2/25/94 +POP? MS-WIN PathWay Access 3.0 clnt ? The Wollongong Group 8/4/94 +POP3 NT sendmail/POP3 (bet) srvr na www.metainfo.com 9/15/95 +POP3 NT sendmail/POP3 srvr na emwac.ed.ac.uk 12/5/95 (www.emw +ac.ed.ac.uk) +IMAP4 NT sendmail/POP3 (fut) srvr ? emwac.ed.ac.uk 5/21/96 (www.emw +ac.ed.ac.uk) +IMAP2 Amiga Pine 3.8x (in dev) clnt yes UWashington 11/7/93 +POP MacOS POPmail 1.7 clnt ? boombox.micro.umn.edu 9/1/95 +POP23 MacOS POPmail 2.09b clnt ? boombox.micro.umn.edu 9/1/95 +IMAP2 MacOS POPmail 2.09b clnt ? boombox.micro.umn.edu 9/1/95 +POP23 MacOS POPmail 2.2 clnt ? boombox.micro.umn.edu 9/1/95 +IMAP2 MacOS POPmail 2.2 clnt ? boombox.micro.umn.edu 9/1/95 +POP3 MacOS POPmail/Lab clnt ? boombox.micro.umn.edu 9/1/95 +POP NeXT OS BlitzMail srvr na ftp.dartmouth.edu 10/23/95 +POP DEC OSF/1 BlitzMail srvr na ftp.dartmouth.edu 10/23/95 +POP AIX BlitzMail (in dev) srvr na ftp.dartmouth.edu 10/23/95 +POP3 MS-WINw5 POPmail/Lab clnt ? boombox.micro.umn.edu 9/1/95 +POP3 MacOS Emailer 1.1 clnt yes Claris 7/29/96 +POP3 MacOS OfficeMail srvr na Claris 6/6/96 +IMAP2b Unix imapperl-0.6 clnt ? dnpap.et.tudelft.nl 2/6/96 +POP2 MacOS MailStop 1.1.3 srvr na boombox.micro.umn.edu 1/18/94 +POP3r MacOS MailShare 1.0(beta) srvr na glenn.anderson@stonebow.otago.a +c.nz 8/16/94 +POP3r MacOS MailShare 1.0fc6 srvr na ftp.qualcomm.com 8/4/95 +POP3r MacOS AIMS 1.0 srvr na Apple 10/27/95 +POP3r MacOS AIMS 1.1 srvr na Apple 5/21/96 (www.cybertech.ap +ple.com) +POP3r MacOS AIMS 1.1.1 srvr na Apple 10/17/96 +POP3r MacOS AIMS 2.0 (fut: '97) srvr ? Apple 10/17/96 +POP3r MacOS AIMS 2.1 (fut) srvr ? Apple 10/17/96 +IMAP MacOS AIMS 2.1 (fut) srvr ? Apple 10/17/96 +POP3 MacOS POPGate 1.1 gway ? Stalker 3/25/96 (www.stalker.co +m) +IMAP? MacOS MailDrop 1.1 clnt ? ackmo.baylor.edu 3/22/96 +IMAP2? MacOS MailDrop 1.2d6a clnt ? ackmo.baylor.edu 3/22/96 +IMAP? MacOS MailDrop 2 (dev) clnt ? Baylor 1/19/96 +POP2 MS-DOS LifeLine Mail 2.0 clnt ? SunSelect 12/7/93 +POP23 MS-DOS SelectMail 2.1 clnt ? SunSelect 1/25/94 +POP2 MS-DOSk ? srvr na ucsd.edu +POP2 MS-DOSk net091b srvr na boombox.micro.umn.edu 12/3/93 +POP3 MS-DOSk pop3nos v1.86 srvr na boombox.micro.umn.edu 12/3/93 +POP2 MS-DOSp POPMail 3.2.2 clnt ? boombox.micro.umn.edu 9/1/95 +IMAP? MS-DOSp POPMail/PC 3.2.2 clnt ? boombox.micro.umn.edu 1/11/94 +POP2 MS-DOSp POPMail 3.2.3 beta2 clnt ? boombox.micro.umn.edu 9/1/95 +IMAP? MS-DOSp POPMail 3.2.3 beta2 clnt ? boombox.micro.umn.edu 9/1/95 +POP3 MS-DOSk pop3serv srvr na biochemistry.crwu.edu +POP3 MS-DOSk nos11c-a.exe srvr na biochemistry.bioc.cwru.edu 9/16 +/94 +POP2 MS-DOS MD/DOS-IP clnt ? U Maryland +POP2 MS-DOS PC/TCP clnt ? FTP Software +POP2 OS/2 PC/TCP for OS/2 clnt ? FTP Software 11/2/93 +POP23 MS-WIN BW-Connect clnt no Beame & Whiteside 8/4/94 +POP3 MS-WIN Air Series 2.06 clnt no Spry 7/7/94 +IMAP? MS-WIN Air Mail ? ? AIR Co. Ltd 9/20/94 +IMAP? MS-WIN EMBLA ? ? ICL ProSystems 9/20/94 +IMAP4 ? Intrnt Msging Srvr srvr ? ICL TeamWare 9/8/1 +POP3 ? Intrnt Msging Srvr srvr ? ICL TeamWare 9/8/1 +POP23 MS-DOSp Minuet 1.0b18a(beta)clnt no minuet.micro.umn.edu 9/1/95 +POP? MS-WINls TCPMail clnt ? Pinesoft (pinesoft@net.com) +POP2 Unix U Minn popd 1.5c srvr na boombox.micro.umn.edu 11/19/93 +POP2 Unix/AIX aix_new_popd srvr na boombox.micro.umn.edu 9/1/95 +POP2 Unix/HP9k hp9000_popd srvr na boombox.micro.umn.edu 9/1/95 +POP23 MS-WINw POPmail clnt ? boombox.micro.umn.edu 9/1/95 +IMAP2 MS-WINw POPmail clnt ? boombox.micro.umn.edu 9/1/95 +POP2 Unix USC-ISI popd srvr na ? 10/24/94 +POP2 Unix imapd/ipop2d 3.4 srvr na ftp.cac.washington.edu 12/13/94 +POP3 Unix/curs Z-Mail Lite 3.2 clnt yes NetManage 8/23/96 www.netmanage +.com +POP3 Unix/line Z-Mail Lite 3.2 clnt yes NetManage 8/23/96 www.netmanage +.com +POP3 Unix/XM Z-Mail Motif 3.2.1 clnt yes NetManage 8/23/96 www.netmanage +.com +POP3 WIN3/95/NT Z-Mail 4.0.1 clnt yes NetManage 8/23/96 www.netmanage +.com +POP3 MacOS Z-Mail 3.3.1 clnt yes NetManage 8/23/96 www.netmanage +.com +IMAP4 WIN3/95/NT Z-Mail Pro clnt yes NetManage 8/23/96 www.netmanage +.com +IMAP4 WIN3/95/NT Z-Mail Pro 6.0 clnt yes NetManage 1/31/97 www.netmanage +.com +IMAP? MacOS Z-Mail ? clnt yes NetManage 5/21/96 +POP? Unix zync ? clnt ? NCD 9/23/94 (www.ncd.com) +POP23k UnixX xmh clnt ? ftp.x.org 2/15/94 +POP23k UnixX exmh clnt yes ? 8/8/95 +POP23k UnixX dxmail/mh clnt ? DEC +POP? Unix ucbmail clone clnt ? rtfm.mit.edu 12/16/94 +POP? Unix pop-perl-1.0 clnt ? sunsite.unc.edu 9/13/94 +POP? Unix/XO SXMail 0.9.74a (b) clnt ? ftp.uni-stuttgart.de 10/12/95 +POP2 VM FAL srvr na IBM +POP2 MS-WIN IBM TCP/IP for DOS clnt no IBM 7/7/94 +POP2 VM ? srvr na Texas Tech University +POP? VM ?POPD srvr na vmd.cso.uiuc.edu 2/4/94 +POP3 VM vmpop3.200 srvr na uriacc.uri.edu 1/10/95 +POP3 MUSIC/SP POPD 1.0 srvr na McGill Univ. Sys. Inc. 01/11/95 +POP2 OS/2 TCP/2 SERVER PACK srvr na Essex Systems +POP2 VMS MultiNet srvr na TGV, Inc. 07/26/95 +POP2 HP3000/MPE NetMail/3000 srvr na 3K Associates +POP3 ? NetMail/3000 srvr na 3K Associates +POP3k MacOS Eudora 1.3a8k clnt ? ftp.brown.edu 8/19/94 +POP3 MacOS MacPOP (Berkeley) clnt ? ftp.cc.berkeley.edu +POP3k MacOS TechMail 2.0 clnt ? net-dist.mit.edu +POP3 MacOS MacMH clnt ? jessica.stanford.edu/info +POP3 MacOS VersaTerm Link clnt ? Synergy Software 10/8/93 +POP3 MacOS LeeMail 2.0.2 (shw) clnt ? chs.cusd.claremont.edu 10/12/93 +POP3 Mac7pro Mail*Link Internet clnt yes StarNine Technologies 2/18/94 +POP3t Unix popper-1.7 srvr na ftp.cc.berkeley.edu 10/15/93 +POP3k Unix popper-1.7k srvr na ftp.brown.edu 10/19/94 +POP3k Unix hacked ucbmail clnt no UCSC 6/29/95 +POP3k Unix hacked pine clnt yes UCSC 6/29/95 +POP3 Unix popper-1.831 srvr na ftp.cc.berkeley.edu 11/3/93 +POP3 Solaris2.X popper-1.831/uore srvr na ftp.uoregon.edu 10/19/93 +POP3 Solaris2.X popper-1.9 srvr na ftp.chalmers.se 7/26/94 +POP3 Unix popperQC3 srvr na ftp.qualcomm.com 8/4/95 +POP3 Unix qpopper 2.1.3-r5 srvr na ftp.qualcomm.com 8/4/95 +POP3 Unix qpopper 2.1.4-r1 srvr na ftp.qualcomm.com 8/4/95 +POP3u Unix qpopper 2.1.4-r3 srvr na ftp.qualcomm.com 2/26/96 +POP3u Unix qpopper 2.1.4-r4 srvr na QualComm 5/16/95 +POP3r Unix Vers of qpopper srvr na QualComm 1/26/96 +POP3u Unix qpopper 2.2 beta srvr na Qualcomm 2/26/96 +POP? Unix zpop srvr na NCD 9/1/95 +POP3 Unix popper.rs2 srvr na ftp.qualcomm.com 8/4/95 +POP3 Unix perl popper srvr na ftp.xensei.com/users/ccrlphr 9/ +1/95 +POP23k Unix mh-6.8 (UCI RandMH) both yes ftp.ics.uci.edu 8/30/94 +POP23krUnix mh-6.8.3 (UCI RndMH)both yes ftp.ics.uci.edu 9/27/94 +POP23 Unix/EMACS RMAIL clnt no ? 8/2/95 +POP23 Unix/EMACS vm clnt no ftp.uu.net 8/2/95 +POP3 Linux miniclient clnt ? sunsite.unc.edu 8/30/94 +POP3 Unix imapd/ipop3d 3.4 srvr na ftp.cac.washington.edu 12/13/94 +POP3 Unix pop3d 1.004 srvr na ftp.ucdavis.edu 12/3/93 +POP2 Unix pop2d 1.001 srvr na ftp.ucdavis.edu 12/3/93 +POP3 Unix mush 7.2.5 clnt ? ? 12/16/94 +POP23k Unix popmaild srvr na ftp.wu-wien.ac.at 4/5/95 +IMAP AIX imap server srvr ? ftp.wu-wien.ac.at 4/5/95 +POP3 MacOS/AOCE MailConnect clnt yes ? 7/5/95 +POP3t MS-DOSnpo PC/TCP clnt ? FTP Software +POP3 OS/2 PC/TCP for OS/2 clnt ? FTP Software 11/2/93 +POP3 MS-DOS TechMail(future) clnt ? ? +POP3 MS-WINl TechMail for Wind. clnt ? net-dist.mit.edu 2/25/94 +POP3 OS/2l TechMail for Wind. clnt ? net-dist.mit.edu 2/25/94 +POP3 MS-DOSp NUPop 1.03 clnt no ftp.acns.nwu.edu 11/5/93 +POP3 MS-DOSp NUPop 2.02 clnt no ftp.acns.nwu.edu 1/18/94 +POP3 MS-DOSp NUPop 2.10 (alpha) clnt yes ftp.acns.nwu.edu 6/10/94 +POP23 MS-WINw Trumpet clnt no ftp.psychol.utas.edu.au 7/7/94 +POP3 MS-WIN Pceudora clnt ? ftp.qualcomm.com 9/24/93 +POP3 MS-WINw WinPmail 2.0b4 clnt ? risc.ua.edu 6/6/95 +POP3 MS-DOSp POPgate (Pmail gw) clnt ? risc.ua.edu 4/1/94 +POP3 MS-DOSl PMPOP (Pmail gw) clnt ? risc.ua.edu 4/1/94 +POP3x MS-WIN WinQVT (2.1) clnt ? QPC Software (shareware) 7/12/9 +4 +POP3 MS-WINp wnqvtnet 3.0 clnt ? ftp.cica.indiana.edu +POP3 MS-WINp wnqvtnet 3.9 clnt ? ftp.cica.indiana.edu 2/1/94 +POP3 MS-WIN Open Systems Mail clnt ? Pine Software +POP3 MS-WIN? IMAIL both ? Ipswitch 7/12/94 +POP3 NT Ipswitch srvr ? Ipswitch 5/24/96 +POP3 VMS IUPOP3 v1.7 srvr na ftp.indiana.edu 7/25/94 +POP3 VMS IUPOP3 v1.7-CMU-TEK srvr na ftp.indiana.edu 7/25/94 +POP3 VMS IUPOP3 v1.8-1 srvr na ftp.indiana.edu 7/25/94 +POP3 MS-DOS POP3 0.9 clnt na ftp.indiana.edu 7/25/94 +POP3 VMS MultiNet both ? TGV, Inc. 07/26/95 +POP3 VMS PMDF 5.1 srvr na Innosoft 9/24/96 www.innosoft.c +om +POP3 Solaris PMDF 5.1 srvr na Innosoft 9/24/96 www.innosoft.c +om +POP3 DigUNIX PMDF 5.1 srvr na Innosoft 9/24/96 www.innosoft.c +om +POP3 OpenVMS PMDF 5.1 srvr na Innosoft 9/24/96 www.innosoft.c +om +IMAP? VMS PMDF 5.1 srvr ? Innosoft 9/24/96 www.innosoft.c +om +IMAP? Solaris PMDF 5.1 srvr ? Innosoft 9/24/96 www.innosoft.c +om +IMAP? DigUNIX PMDF 5.1 srvr ? Innosoft 9/24/96 www.innosoft.c +om +IMAP? OpenVMS PMDF 5.1 srvr ? Innosoft 9/24/96 www.innosoft.c +om +IMAP? MS-DOS PMDF E-mail Interc clnt ? Innosoft 3/2/94 www.innosoft.co +m +IMAP? MacOS PMDF E-mail Interc clnt ? Innosoft 3/2/94 www.innosoft.co +m +POP? VMS PMDF E-mail Interc ? ? Innosoft 6/24/96 www.innosoft.c +om +IMAP? VMS PMDF E-mail Interc ? ? Innosoft 6/24/96 www.innosoft.c +om +POP3r VMS PMDF popstore clnt ? Innosoft 9/24/96 www.innosoft.c +om +IMAP4 SolarisX Roam (Future) clnt ? Sun 9/26/95 +IMAP? Windows? Roam (Future) clnt ? Sun 3/19/96 +IMAP4 SolarisX imapd (Future) clnt ? Sun 9/26/95 +IMAP4 Solaris Solstice IMS1.0 srvr yes SunSoft 10/17/96 http://www.sun +.com +POP3 Solaris Solstice IMS1.0 srvr yes SunSoft 10/17/96 http://www.sun +.com + +IMAP4 Solaris Solstice IMS2.0 (f) srvr yes SunSoft 10/17/96 http://www.sun +.com +POP3 Solaris Solstice IMS2.0 (f) srvr yes SunSoft 10/17/96 http://www.sun +.com +IMAP4 Solaris Solstice IMC0.9 clnt yes SunSoft 4/5/96 http://www.sun.c +om +IMAP4 Solaris Solstice IMC? (fut) clnt yes SunSoft 4/5/96 http://www.sun.c +om +IMAP4 MS-WIN3.11 Solstice IMC0.9 clnt yes SunSoft 4/5/96 http://www.sun.c +om +IMAP4 MS-WIN3.11 Solstice IMC? (fut) clnt yes SunSoft 4/5/96 http://www.sun.c +om +IMAP4 MS-WIN95 Solstice IMC0.9 clnt yes SunSoft 4/5/96 http://www.sun.c +om +IMAP4 MS-WIN95 Solstice IMC? (fut) clnt yes SunSoft 4/5/96 http://www.sun.c +om +IMAP4 NT Solstice IMC0.9 clnt yes SunSoft 4/5/96 http://www.sun.c +om +IMAP4 NT Solstice IMC? (fut) clnt yes SunSoft 4/5/96 http://www.sun.c +om +IMAP4 Win95 SOlstice 2.0 clnt ? SunSoft 1/31/97 +POP3 OS/2 TCP/2 SERVER PACK srvr na Essex Systems +POP3 OS/2 TCP/2 ADV CLIENT clnt ? Essex Systems +POP? MS-DOS UCDmail clnt ? ftp.ucdavis.edu 10/24/94 +POP? MS-DOS PC POP clnt ? ?Bill Schweickert/Sterling Fed +POP23 MS-WINnpo Super-TCP for W e.0 clnt yes Frontier Technologies 6/10/94 +POP? MS-WINnpo Super-TCP for W e.0 srvr yes Frontier Technologies 7/12/94 +POP3 WIN3/95/NT SuperHghwy Access 2 clnt yes Frontier Technologies 7/29/96 +POP? MS-WINw Windows ELM clnt ? lister.cc.ic.ac.uk 7/12/94 +IMAP? ? ELM patches clnt ? www.math.fu-berlin.de/~guckes/e +lm/patches 7/16/96 +POP23 MS-DOSni ChameleonNFS both ? NetManage 8/4/94 +POP23 MS-DOSni Chameleon beta clnt yes NetManage +POP23 MS-WINw Internet Chameleon clnt yes NetManage 7/12/94 +POP23 NT Chameleon V5.0 f NT both ? NetManage 11/28/95 +IMAP? Windows? Chameleon (future) clnt ? NetManage 3/19/96 +POP? MacOS MEWS clnt ? ? +POP? MacOS byupopmail clnt ? ? +POP? VM ? srvr na TTUVM1 +POP3 MacOS HyperMail ? ? ? +? OS/2 lamailpop ? ? ftp-so2.cdrom.com +POP? OS/2 Popclient clnt yes ? 1/19/96 +POP? OS/2 Emacs 19.xx clnt yes ? 1/19/96 +POP3 MS-DOSs pcelm clnt ? lister.cc.ic.ac.uk 1/25/94 +POP3 MS-WINs winelm clnt ? lister.cc.ic.ac.uk 1/25/94 +POP3 NetWare Mercury 1.11 srvr na risc.ua.edu 2/4/94 +POP3 NetWare34 Mercury 1.2.1 srvr na risc.ua.edu 3/29/96 +POP3 NetWare34 Mercury 1.3 srvr na risc.ua.edu 8/2/96 +POP3 MS-WINw IMail srvr na Ipswitch 7/15/94 +POP3 MS-Windows Pegasus/Win 2.3 clnt ? risc.ua.edu 6/6/96 +POP3 MS-Windows Pegasus/Win 2.2(r3) clnt ? risc.ua.edu 6/6/96 +POP3 MS-Windows Pegasus/Win 2.0(r1) clnt ? risc.ua.edu 6/6/96 +POP3 MS-DOS Pegasus/DOS 3.2(r2) clnt ? risc.ua.edu 6/6/96 +POP3 MacOS Pegasus/MAC 2.1.2 clnt ? risc.ua.edu 6/6/96 +POP23 MS-WINw Mail-IT 2 clnt yes mail-it@unipalm.co.uk 7/12/94 +POP23 Unix Mail-IT 2 clnt yes mail-it@unipalm.co.uk 9/9/94 +POP23 Unix servers w Mail-IT srvr na mail-it@unipalm.co.uk 12/16/94 +POP? MS-WIN RFD Mail 1.22 clnt ? ftp.std.com 7/19/94 +POP? MS-WIN RFD Mail 1.23 clnt ? ftp.std.com 9/16/94 +POP3 MS-WINw ws_gmail srvr na buckshot.usma.edu 9/16/94 +POP3 MS-WINw IMAIL srvr na Ipswitch 9/16/94 +POP3 MS-WINw Pronto Mail 2.01 clnt yes Commtouch 4/24/96 (www.commtouc +h.com) +IMAP MS-WINw Pronto clnt yes Commtouch 9/5/95 +IMAP4 ? Pronto97 clnt yes CommTouch 1/7/97 (www.commtouch +.com) +POP3 ? Pronto97 clnt yes CommTouch 1/7/97 (www.commtouch +.com) +POP23 MS-WINw Turnpike clnt yes Turnpike Ltd, http:www.turnpike +.com 8/11/95 +POP3 MS-WIN WinSmtp srvr na Seattle Labs, http://wildside.k +wnet.on.ca/winsmtp.html 11/3/95 +POP3r WIN95 SLmail95 srvr na http://www.seattlelab.com/ 5/14 +/96 +POP3r NT SLmailNT srvr na http://www.seattlelab.com/ 3/29 +/96 +POP3 ? VA Professional clnt yes Ashmount 4/30/96 http://www.asn +mount.com +POP3 ? VA Workgroup clnt yes Ashmount 4/30/96 http://www.asn +mount.com +POP3 NT post.office srvr na Software.com, Inc. 12/11/95 (ww +w.software.com) +POP3 Solaris post.office srvr na Software.com, Inc. 12/11/95 (ww +w.software.com) +POP? MS-? Exchange clnt ? Microsoft 10/24/95 +POP3 MS-? Exchange Server (f) srvr yes Microsoft 9/11/96 +IMAP4 MS-? Exch Server (maybe) srvr ? Microsoft 6/21/96 +POP3 MS-? Exchange Server 5.0 srvr ? Microsoft 1/14/97 +POP3 MS-? Inter. Mail & News clnt yes Microsoft 6/4/96 (www.microsoft +.com) +POP3 MS-? Inter. Mail Service gway ? Microsoft 6/4/96 (www.microsoft +.com) +POP3u NT Exchpop(?) 1.0 gway yes http://www.sts.co.il/pop3.htm 6 +/14/96 +POP3 MacOS Powertalk ? ? ? 11/7/95 +IMAP2 MS-WIN Siren Mail clnt yes Siren Software 12/28/95 +IMAP? Windows? Siren Mail 3.0 clnt yes Siren Software 3/19/96 +POP3 MS-WIN Siren Mail clnt yes Siren Software 12/28/95 +IMAP2 WIN95 Siren Mail clnt yes Siren Software 12/28/95 +POP3 WIN95 Siren Mail clnt yes Siren Software 12/28/95 +IMAP2 NTclient Siren Mail clnt yes Siren Software 12/28/95 +POP3 NTclient Siren Mail clnt yes Siren Software 12/28/95 +? Unix Siren Mail srvr ? Siren Software 12/28/95 +IMAP2 ? Siren Mail Server srvr ? Siren Software 8/1/96 +POP3 ? Siren Mail Server srvr ? Siren Software 8/1/96 +IMAP4 ? Siren Mail (future) clnt yes Siren Software 12/28/95 +IMAP? MacOS Siren Mail (future) clnt yes Siren Software 1/21/96 +IMAP? WIN95 Siren Mail (beta) clnt yes Siren Software 7/30/96 +POP3 MacOS NetAlly srvr na Delphic (www.delphic.com) 11/17 +/95 +POP3 DOSWIN BeyondMail clnt yes Banyan (beyondmail.banyan.com) +2/6/96 +IMAP4 ? BeyondMail (future) clnt yes Banyan (beyondmail.banyan.com) +9/6/96 +POP? NT MailSrv from Res K. srvr na Microsoft? +IMAP WIN? ? clnt ? Email connection 12/8/95 +POP3 NetWare34 SoftNet WEBserv srvr na Puzzle Systems 12/15/95 (info@p +uzzle.com) +POP3 NT Netscape Mail Srvr srvr na Netscape 12/18/95 (info@netscap +e.com) +POP3 SunOS Netscape Mail Srvr srvr na Netscape 12/18/95 (info@netscap +e.com) +POP3 Solaris Netscape Mail Srvr srvr na Netscape 12/18/95 (info@netscap +e.com) +IMAP4 NT Netscape M S 2.0(f) srvr ? Netscape 6/21/96 +IMAP4 NT Netscape M S 2.02 srvr ? Netscape 1/31/97 +POP3 OpenVMS TCPware Internet Sr srvr na Process Software 12/20/95 (info +@process.com) +POP3 Unix UMT (beta) clnt ? ftp.topaz.kiev.ua 12/29/95 (www +.topaz.kiev.ua) +POP3 NetWare 4 LAN WorkGroup 5 ???? na Novell 1/1/96 +IMAP2 Solaris MMail clnt yes Atelier de Software Ltd. 5/21/9 +6 +IMAP2 MacOS MMail (planned) clnt yes Atelier de Software Ltd. 5/21/9 +6 +POP? OS/2 Yarn/Souper(?) clnt ? ? 1/16/96 +POP3 NT Sendmail w POP3 1.0 srvr na MetaInfo 1/19/96 http://www.met +ainfo.com +POP3 NT Sendmail w POP3 1.1 srvr na MetaInfo 12/4/96 http://www.met +ainfo.com +POP3 ? PopGate gway na ftp.esi sys.com 1/19/96 +POP3 OS/2 ? (future) srvr na Secant 1/23/96 +?POP3 NT NT MAIL ? ? http://bhs.com 1/26/96 +POP3 NT MAILbus Internet srvr na Digital 2/20/96 (www.digital.co +m) +POP3 DEC UNIX MAILbus Internet srvr na Digital 2/20/96 (www.digital.co +m) +POP3r NT MAILbus Internet(b) srvr na Digital 2/20/96 (www.digital.co +m) +POP3r DEC UNIX MAILbus Internet(b) srvr na Digital 2/20/96 (www.digital.co +m) +POP? OS/2 lampop(?) clnt ? ? 1/26/96 +POP? NT NTMail clnt ? www.mortimer.com 2/9/96 +POP3 DOSWINMac OpenMail (future) clnt ? HP 3/29/96 http://www.openmail. +external.hp.com +IMAP DOSWINMac OpenMail (future) clnt ? HP 3/29/96 http://www.openmail. +external.hp.com +POP3 NetWare4 Connect2SMTP srvr ? Infinite Technologies 3/29/96 +POP3 OS/2 PowerWeb Server++ srvr na CompuSource 4/16/96 http://www. +compusource.co.za +POP3 OS/2 SIDIS/2 srvr na stargate.rz.fh-offenburg.de 6/4 +/96 +POP3 ? WIG v2.0 gway ? http://www.demon.co.uk/ 4/19/96 +POP3 WIN95 Windis32 srvr na Demon Internet 6/6/96 (www.demo +n.co.uk) +POP3 DOSWINMac DaVinci SMTP eMAIL clnt yes On Technology 4/24/96 +POP? WIN32 Mail OnNet (OnNet32)clnt yes FTP Software 5/3/96 (www.ftp.co +m) +POP? Unix xfmail clnt ? burka.netvision.net.il 5/110/96 +POP3rutOS/2 POP3s v1.01 srvr ? www.secant.com 5/14/96 +POP3 Java Aplt Yamp clnt ? www.mcs.net/~faisal/Yamp/yampix +.html 5/24/96 +POP3 NT NT Mail gway ? www.net-shopper.co.uk 5/31/96 +POP3 WIN? Mailcall chkr na ? 6/11/96 +POP3 WIN? Mailcheck chkr na ? 6/11/96 +POP3 DOS C2SMTP srvr na Infinite Technologies 6/11/96 +POP MacOS Quarterdeck v4(fut) clnt yes Starnine 6/11/96 (www.starnine. +com) +POP MacOS List Star ? ? Starnine 6/24/96 (www.starnine. +com) +POP3 MacOS Marionet 1.0 srvr na Allegiant 6/12/96 (www.allegian +t.com) +POP3 ? Mailcoach V1.0 srvr na http://www.multi.se/ymex/mailco +ach.htm 6/14/96 +IMAP4 WIN3/NT/95 JetMail clnt yes NetManage 7/29/96 +POP3 WIN3/NT/95 JetMail clnt yes NetManage 7/29/96 +POP3 NT Post.Office srvr na NetManage 8/22/96 www.netmanage +.com +POP3 SunOS Post.Office srvr na NetManage 8/22/96 www.netmanage +.com +POP3 Solaris Post.Office srvr na NetManage 8/22/96 www.netmanage +.com +POP3 Unix Z-Pop 1.0 srvr na NetManage 8/22/96 www.netmanage +.com +POP3 AppleShare FutureShare (fut) srvr na Apple 6/14/96 +POP? ? Applixware ? ? Applix 6/24/96 +POP3 Unix Mail*Hub srvr ? CDC 10/23/96 www.cdc.com +IMAP4 Unix Mail*Hub srvr ? CDC 10/23/96 www.cdc.com +POP? Unix TkRat clnt ? www.dtek.chalmers.se/~maf/ratat +osk 6/24/96 +IMAP? Unix TkRat clnt ? www.dtek.chalmers.se/~maf/ratat +osk 6/24/96 +IMAP? Unix Elm clnt ? ? 7/1/96 +POP3 WIN16/32 Virtual Access clnt yes www.ashmount.com 8/9/96 +POP3 ? pop-perl5 clnt ? ? 7/23/96 +POP3 WIN95 Agent clnt ? ? 7/23/96 +POP3 ? Mail eXtension 1.60 clnt ? Terckland 7/26/96 (ourworld.com +puserve.com/homepages/mailx) +POP3 WIN3/95/NT Emissary Office 1.1 clnt yes Attachmate 7/29/96 +POP3 WIN3/95 Pronto Mail 2.0 clnt yes CommTouch 7/29/96 +POP3 ? gcMail 081b (beta) clnt ? www.greencedars.com 8/9/96 +POP3r Java shareware Java cls clnt ? Koehn Consulting 8/2/96 +POP3 ? cucipop (future) srvr na cuci.nl 8/6/96 +POP3 MacOS QuickMail Pro clnt ? CE Software www.cesoft.com 12/1 +9/96 +POP3 ? QuickMail Pro (fut) clnt ? CE Software www.cesoft.com 8/9/ +96 +IMAP? ? QuickMail Pro (fut) clnt ? CE Software www.cesoft.com 8/9/ +96 +POP3 ? QuickMail POP (fut) clnt ? CE Software www.cesoft.com 8/9/ +96 +POP3 ? QM-Internet Gateway ? ? CE Software 6/24/96 +POP3 ? Lotus Notes 4.5 srv srvr ? Lotus 10/17/97 +POP3 Be BeMail clnt ? www.be.com 11/25/96 +POP3 NT Metainfo/Intergate srvr na ? 11/26/96 +POP3 Java Novita Mail clnt ? Novita Comm 12/10/96 +IMAP? Java Novita Mail clnt ? Novita Comm 12/10/96 +IMAP? Windows Winbox 3.1 Beta 1 clnt ? ftp.uv.es 12/13/96 +POP? Windows Winbox 3.1 Beta 1 clnt ? ftp.uv.es 12/13/96 +POP3 MacOS Bluto (future) clnt yes Bare Bones www.barebones.com 12 +/18/96 +POP3 WIN95/NT ExpressIT! 2000 clnt ? Infinite Technologies www.ihub. +com 1/14/97 +IMAP WIN95/NT ExpressIT! 2000 clnt ? Infinite Technologies www.ihub. +com 1/14/97 +------ ---------- ------------------- ---- ---- ------------------------------- + + + _________________________________________________________________ + +Some other packages for desktop systems + + +------ ---------- ------------------- ---- ---- ------------------------------- +? MS-DOSs CMM peer ? Cinetic Systems 1/25/94 +? MS-DOSs WinMail 1.1a peer ? Obsolete +SMTP MacOS LeeMail 1.2.4 peer ? Shareware, laf@mitre.org +SMTP MacOS LeeMail 2.0.2 (shw) peer ? chs.cusd.claremont.edu 10/12/93 +SMTP MS-DOSni ChameleonNFS peer ? NetManage 2/25/94 +SMTP MS-WINw ws_gmail peer ? buckshot.usma.edu 5/26/94 +uucp MacOS FernMail peer ? Shareware, dplatt@snulbug.mtvie +w.ca.us +prop MacOS MacPost both ? ftp.lu.se 10/19/93 +uucp MacOS Eudora >1.3.1 peer yes ftp.qualcomm.com 5/10/94 +MAPI WIN3/95/NT Eudora Pro ? clnt yes Qualcomm 7/29/96 +uucp MacOS UUPC peer ? dplatt@snulbug.mtview.ca.us +uucp MacOS gnuucp peer ? jim@fpr.com +uucp MS-DOS waffle peer ? ? dell@vox.darkside.com 10/24/9 +4 +uucp MS-DOS UUPC peer ? ? help@kew.com 10/24/94 +fshare MS-Windows Pegasus/Win 2.3 clnt ? risc.ua.edu 6/6/96 +fshare MS-Windows Pegasus/Win 2.2(r3) clnt ? risc.ua.edu 6/6/96 +fshare MS-Windows Pegasus/Win 2.0(r1) clnt ? risc.ua.edu 6/6/96 +fshare MS-DOS Pegasus/DOS 3.2(r2) clnt ? risc.ua.edu 6/6/96 +fshare MacOS Pegasus/MAC 2.1.2 clnt ? risc.ua.edu 6/6/96 +fshare MS-Windows Pegasus/Win 2.4.2 clnt ? risc.ua.edu 8/2/96 +fshare MS-DOS Pegasus/DOS 3.3.1 clnt ? risc.ua.edu 8/2/96 +SMTP MS-DOS Charon gway ? risc.ua.edu 10/15/93 +Waffle MS-WIN Boxer clnt ? ftp.halcyon.com 12/3/93 +? MS-? pcelm clnt ? simtel 12/3/93 +? MS-? elm-pc clnt ? lister.cc.ic.ac.uk 12/3/93 +SMTP MS-WINw Internt Ex for cc:m gway yes IMA 1/31/94 +SMTP Netware Mercury 1.11 gway ? risc.ua.edu 2/4/94 +? MacOS PowerMail clnt ? Apple 2/18/94 +SMTP OS/2 PC/TCP v1.3 peer ? FTP Software 2/18/94 +MAPI MS-DOS? Microsoft Mail clnt ? Microsoft 3/2/94 +? MacOS Microsoft Mail clnt ? Microsoft 3/15/94 +VIM DOSWINMac cc:mail clnt ? Lotus 3/15/94 +MHS/G DOSWINMac DaVinci eMAIL clnt ? On Technology 4/24/96 +P7uucp DOSWINMac OpenMail clnt ? HP 3/2/94 +? DOSWINMac WordPerfect Office clnt ? WordPerfect Corp. 3/15/94 +? DOSMac MailWorks clnt ? DEC 3/2/94 +MHS/G DOSWIN BeyondMail clnt yes Banyan (beyondmail.banyan.com) +2/6/96 +? DOSOS/2 Higgins Mail clnt ? Enable Software 1/26/95 +? MacOS QuickMail 3.6 clnt ? CE Software 6/6/96 +? DOS QuickMail 3.0 clnt ? CE Software 6/6/96 +? MS-WIN QuickMail 3.5 clnt ? CE Software 6/6/96 +? MacOS QuickMail 4.0 (fut) clnt ? CE Software 6/6/96 +? ? QuickMail ? clnt yes CE Software 7/15/96 +? MS-WIN Team clnt ? Futurus 1/26/95 +? DOSWIN ExpressIT! clnt ? Infinite Technologies 1/26/95 +MAPI WIN95/NT ExpressIT! 2000 clnt ? Infinite Technologies www.ihub. +com 1/14/97 +MHS WIN95/NT ExpressIT! 2000 clnt ? Infinite Technologies www.ihub. +com 1/14/97 +VIM WIN95/NT ExpressIT! 2000 clnt ? Infinite Technologies www.ihub. +com 1/14/97 +? ? GroupWise cnlt ? Novell 1/26/95 +? DOSWINMac Lotus Notes clnt ? Lotus 3/15/94 +FCP MacOS FirstClass 2.5 clnt no SoftArc 7/12/94 +FCP MS-WIN FirstClass 2.5 clnt no SoftArc 7/12/94 +FCP MacOS FirstClass 2.5 srvr no SoftArc 7/12/94 +MHS MacOS FirstClass/MHS gway no SoftArc 7/12/94 +UUCP MacOS FirstClass/UUCP gway no SoftArc 7/12/94 +MAPI MS-WINw Mail-IT 2 clnt yes mail-it@unipalm.co.uk 7/12/94 +MAPI ? ECSmail clnt ? ESYS Corp www.esys.ca 12/16/96 +VIM ? ECSmail clnt ? ESYS Corp www.esys.ca 12/16/96 +MAPI MS-WIN SIMEON 4.1 clnt ? ESYS Corp 222.esys.ca 12/16/96 +MAPI WIN3/95/NT Z-Mail 4.0.1 clnt yes NetManage 8/22/96 www.netmanage +.com +MAPI MS-WIN Air Mail ? ? AIR Co. Ltd 10/7/94 +MAPIs MS-WIN Siren Mail ? ? Siren Software 12/28/95 +MAPIs WIN95 Siren Mail ? ? Siren Software 12/28/95 +MAPIs NTclient Siren Mail ? ? Siren Software 12/28/95 +SMTP MS-WINw Mail-IT 2 peer yes mail-it@unipalm.co.uk 7/12/94 +? MS-WINw Panda ? ? ftp.cica.indiana.edu 7/12/94 +PSS MS-Win pMail 3.0 clnt no CommTouch 9/27/94 +PSS MS-DOS pMail 3.0 clnt no CommTouch 9/27/94 +PROP MacOS BlitzMail clnt no ftp.dartmouth.edu 10/23/95 +PROP NeXT OS BlitzMail srvr no ftp.dartmouth.edu 10/23/95 +PROP DEC OSF/1 BlitzMail srvr no ftp.dartmouth.edu 10/23/95 +PROP AIX BlitzMail (in dev) srvr no ftp.dartmouth.edu 10/23/95 +PROP ? FreeMail ? ? whttp://www.montana.com/freemai +l 95/12/8 +PROP MacOS CommuniGate both ? Stalker 5/21/96 (www.stalker.co +m) +SMPT MacOS SMTPGate gway ? Stalker 3/25/96 (www.stalker.co +m) +UUCP MacOS UUCPGate gway ? Stalker 3/25/96 (www.stalker.co +m) +? MacOS Quarterdeck Mail both yes Starnine 6/11/96 (www.starnine. +com) +MAPI WIN3/NT/95 JetMail clnt yes NetManage 7/29/96 +------ ---------- ------------------- ---- ---- ------------------------------- + + + _________________________________________________________________ + +Key and Other Issues + + +(a) What are the common extensions to POP3 and which clients/servers + support them? +POP3k - Kerberos +POP3a - AFS Kerberos +POP3x - ? +POP3t - xtnd xmit facility--allows client to send mail through additional + POP commands, thus allowing server to verify/log source of mail. +POP3r - APOP +POP3m - ? +POP3u - with UIDL command. +(b) What DOS protocol stacks are supported? +MS-DOSm - Lan Manager +MS-DOSn - NDIS Drivers +MS-DOSl - Lan Workplace for Dos +MS-DOSs - Sun PCNFS +MS-DOSp - Packet Drivers +MS-DOSo - ODI Drivers +MS-DOSi - IPXLink +MS-DOSf - FTP Software PC/TCP +MS-DOSk - KA9Q I think +MS-WIN? - similar +MS-WINw - WinSock compliant +MS-WIN5 - Windows 95 +WIN3 - Windows 3.x winsock +WIN3/95/NT - Windows 3.x Winsock, Windows 95 and Windows NT +WIN3/95 - Windows 3.x Winsock and WIndows 95 +NetWare3 - NetWare 3.x +NetWare4 - NetWare 4.x +NetWare34 - NetWare 3.x and 4.x +(c) Other notes +IMAP1 - Original IMAP: I've heard that MacMS actually uses a unique + dialect of it. Definitely obselete, unsupported, discouraged. +IMAP2b - IMAP2bis: name applied to various improved versions of IMAP2. + This development effort culminated in IMAP4. +IMAP24 - IMAP2 or IMAP4 +fshare - uses file sharing. +IMAPb4 - IMAP2, IMAP2bis, or IMAP4. +IMAP41 - IMAP4rev1 +MAPI - Microsoft's Messaging API +MAPIs - Simple MAPI. +VIM - Lotus's Vendor Independent Messaging API +CMC - XAPIA's Common Message Calls API +AOCE - Apple Open Collaborative Environment +PROP - System-specific proprietary protocol +FCP - Softarc's proprietary client-server protocol. +Unix/X - X Windows based +Unix/XM - Motif based +Unix/XO - OpenWindows based +PSS - PROFS Screen Scraper +sumex-aim.stanford.edu* - almost dead as of 7/13/95, to be replaced by + info-mac.org. +Metamail - a package with which MIME messages can be processed from + basically any Unix-based mail client. +POPGate (Stalker Software) - gateway to/from Stalker's CommuniGate + system: enables both use of POP3 to get software from a POP3 server + for use within a CommuniGate community, and to allow POP3 clients to + retrieve mail from a CommuniGate server. +DigUNIX - Digital Unix +Solaris - Solaris 2.x +(d) IMAP/MAPI adaptors: +Wollongong's Pathway Access 7/12/94 +mail-it@unipalm.co.uk's Mail-IT 7/12/94 +(e) IMAP/POP3 adaptors: +Included with NCD Z-mail 4.0 for Windows 9/14/95 +------ ----------- ------------------- ------- ------------------------------- diff --git a/RFC/rfc1081.txt b/RFC/rfc1081.txt new file mode 100644 index 00000000..c21d6e48 --- /dev/null +++ b/RFC/rfc1081.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group M. Rose +Request for Comments: 1081 TWG + November 1988 + + Post Office Protocol - Version 3 + + +Status of this Memo + + This memo suggests a simple method for workstations to dynamically + access mail from a mailbox server. This RFC specifies a proposed + protocol for the Internet community, and requests discussion and + suggestions for improvements. Distribution of this memo is + unlimited. + + This memo is based on RFC 918 (since revised as RFC 937). Although + similar in form to the original Post Office Protocol (POP) proposed + for the Internet community, the protocol discussed in this memo is + similar in spirit to the ideas investigated by the MZnet project at + the University of California, Irvine. + + Further, substantial work was done on examining POP in a PC-based + environment. This work, which resulted in additional functionality + in this protocol, was performed by the ACIS Networking Systems Group + at Stanford University. The author gratefully acknowledges their + interest. + +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 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 is used + to allow a workstation to retrieve mail that the server is holding + for it. + + + + +Rose [Page 1] + +RFC 1081 POP3 November 1988 + + + 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. + +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 (this relay host could be, but need not be, the + POP3 server host for the client host). + + If this method is followed, then the client host appears to the MTS + as a user agent, and should NOT be regarded as a "trusted" MTS entity + in any sense whatsoever. This concept, along with the role of the + POP3 as a part of a split-UA model is discussed later in this memo. + + 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 keyword possibly followed by an + argument. All commands are terminated by a CRLF pair. + + Responses in the POP3 consist of a success indicator and a keyword + possibly followed by additional information. All responses are + terminated by a CRLF pair. There are currently two success + indicators: positive ("+OK") and negative ("-ERR"). + + 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 the first octet of the line (the + termination octet) is stripped away. If so and if CRLF immediately + + + +Rose [Page 2] + +RFC 1081 POP3 November 1988 + + + 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 + finished its transactions, 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. + +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 string terminated + by CRLF. An example might be: + + S. +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU) + + Note that this greeting is a POP3 reply. The POP3 server should + always give a positive response as the greeting. + + The POP3 session is now in the AUTHORIZATION state. The client must + now issue the USER command. If the POP3 server responds with a + positive success indicator ("+OK"), then the client may issue either + the PASS command to complete the authorization, or the QUIT command + to terminate the POP3 session. If the POP3 server responds with a + negative success indicator ("-ERR") to the USER command, then the + client may either issue a new USER command or may issue the QUIT + command. + + 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. If so, + the POP3 server then acquires an exclusive-access lock on the + maildrop. If the lock is successfully acquired, the POP3 server + parses the maildrop into individual messages (read note below), + determines the last message (if any) present in the maildrop that was + referenced by the RETR command, and responds with a positive success + indicator. The POP3 session now enters the TRANSACTION state. If + the lock can not be acquired or the client should is denied access to + the appropriate maildrop or the maildrop can't be parsed for some + + + +Rose [Page 3] + +RFC 1081 POP3 November 1988 + + + reason, the POP3 server responds with a negative success indicator. + (If a lock was acquired but the POP3 server intends to respond with a + negative success indicator, the POP3 server must release the lock + prior to rejecting the command.) At this point, the client may + either issue a new USER command and start again, or the client may + issue the QUIT command. + + NOTE: Minimal implementations of the POP3 need only be + able to break a maildrop into its component messages; + they need NOT be able to parse individual messages. + More advanced implementations may wish to have this + capability, for reasons discussed later. + + After the POP3 server has parsed the maildrop into individual + messages, it assigns a message-id to each message, and notes the size + of the message in octets. The first message in the maildrop is + assigned a message-id of "1", the second is assigned "2", and so on, + so that the n'th message in a maildrop is assigned a message-id of + "n". In POP3 commands and responses, all message-id's and message + sizes are expressed in base-10 (i.e., decimal). + + It sets the "highest number accessed" to be that of the last message + referenced by the RETR command. + + Here are summaries for the three POP3 commands discussed thus far: + + USER name + Arguments: a server specific user-id (required) + Restrictions: may only be given in the AUTHORIZATION + state after the POP3 greeting or after an + unsuccessful USER or PASS command + Possible Responses: + +OK name is welcome here + -ERR never heard of name + Examples: + C: USER mrose + S: +OK mrose is a real hoopy frood + ... + C: USER frated + S: -ERR sorry, frated doesn't get his mail here + + PASS string + Arguments: a server/user-id specific password (required) + Restrictions: may only be given in the AUTHORIZATION + state after a successful USER command + Possible Responses: + +OK maildrop locked and ready + -ERR invalid password + + + +Rose [Page 4] + +RFC 1081 POP3 November 1988 + + + -ERR unable to lock maildrop + Examples: + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + S: +OK mrose's maildrop has 2 messages + (320 octets) + ... + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + S: -ERR unable to lock mrose's maildrop, file + already locked + + QUIT + Arguments: none + Restrictions: none + Possible Responses: + +OK + Examples: + C: QUIT + S: +OK dewey POP3 server signing off + + +The TRANSACTION State + + Once the client has successfully identified itself to the POP3 server + and the POP3 server has locked and burst 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. + + 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 first octets present must indicate the number of + messages in the maildrop. Following this is the size + + + +Rose [Page 5] + +RFC 1081 POP3 November 1988 + + + 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-id (optionally) If a message-id is + given, it 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 "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 called a "scan listing" for that message. + + In order to simplify parsing, all POP3 servers are + required to use a certain format for scan listings. + The first octets present must be the message-id of + the message. Following the message-id is the size of + the message in octets. This memo makes no requirement + on what follows the message size in the scan listing. + Minimal implementations should just end that line of + + + +Rose [Page 6] + +RFC 1081 POP3 November 1988 + + + 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 + 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-id (required) This message-id 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-id, being careful to byte-stuff the + termination character (as with all multi-line + responses). + + If the number associated with this message is higher + than the "highest number accessed" in the maildrop, the + POP3 server updates the "highest number accessed" to + the number associated with this message. + + + + + +Rose [Page 7] + +RFC 1081 POP3 November 1988 + + + Possible Responses: + +OK message follows + -ERR no such message + Examples: + C: RETR 1 + S: +OK 120 octets + S: + S: . + + DELE msg + Arguments: a message-id (required) This message-id + may NOT refer to a message marked as deleted. + Restrictions: may only be given in the TRANSACTION state. + Discussion: + + The POP3 server marks the message as deleted. Any + future reference to the message-id 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. + + If the number associated with this message is higher + than the "highest number accessed" in the maildrop, + the POP3 server updates the "highest number accessed" + to the number associated with this message. + + 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 + + + + + +Rose [Page 8] + +RFC 1081 POP3 November 1988 + + + Examples: + C: NOOP + S: +OK + + LAST + Arguments: none + Restrictions: may only be issued in the TRANSACTION state. + Discussion: + + The POP3 server issues a positive response with a line + containing the highest message number which accessed. + Zero is returned in case no message in the maildrop has + been accessed during previous transactions. A client + may thereafter infer that messages, if any, numbered + greater than the response to the LAST command are + messages not yet accessed by the client. + + Possible Response: + +OK nn + + Examples: + C: STAT + S: +OK 4 320 + C: LAST + S: +OK 1 + C: RETR 3 + S: +OK 120 octets + S: + S: . + C: LAST + S: +OK 3 + C: DELE 2 + S: +OK message 2 deleted + C: LAST + S: +OK 3 + C: RSET + S: +OK + C: LAST + S: +OK 1 + + RSET + Arguments: none + Restrictions: may only be given in the TRANSACTION + state. + Discussion: + + If any messages have been marked as deleted by the POP3 + + + +Rose [Page 9] + +RFC 1081 POP3 November 1988 + + + server, they are unmarked. The POP3 server then + replies with a positive response. In addition, the + "highest number accessed" is also reset to the value + determined at the beginning of the POP3 session. + + Possible Responses: + +OK + Examples: + C: RSET + S: +OK maildrop has 2 messages (320 octets) + + + +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.) + + QUIT + Arguments: none + Restrictions: none + Discussion: + + The POP3 server removes all messages marked as deleted + from the maildrop. It then releases the + exclusive-access lock on the maildrop and replies as + to the success of + these operations. The TCP connection is then closed. + + Possible Responses: + +OK + Examples: + C: QUIT + S: +OK dewey POP3 server signing off (maildrop + empty) + ... + C: QUIT + S: +OK dewey POP3 server signing off (2 messages + left) + ... + + +Optional POP3 Commands + + The POP3 commands discussed above must be supported by all minimal + implementations of POP3 servers. + + + +Rose [Page 10] + +RFC 1081 POP3 November 1988 + + + 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-id (required) and a number. This + message-id 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 headers of the message, + the blank line separating the headers from the body, + and then the number of lines 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 10 + S: +OK + S: + S: . + ... + C: TOP 100 + S: -ERR no such message + + RPOP user + Arguments: a client specific user-id (required) + Restrictions: may only be given in the AUTHORIZATION + state after a successful USER command; in addition, + may only be given if the client used a reserved + + + +Rose [Page 11] + +RFC 1081 POP3 November 1988 + + + (privileged) TCP port to connect to the server. + Discussion: + + The RPOP command may be used instead of the PASS + command to authenticate access to the maildrop. In + order for this command to be successful, the POP3 + client must use a reserved TCP port (port < 1024) to + connect tothe server. The POP3 server uses the + argument pair from the USER and RPOP commands to + determine if the client should be given access to + the appropriate maildrop. Unlike the PASS command + however, the POP3 server considers if the remote user + specified by the RPOP command who resides on the POP3 + client host is allowed to access the maildrop for the + user specified by the USER command (e.g., on Berkeley + UNIX, the .rhosts mechanism is used). With the + exception of this differing in authentication, this + command is identical to the PASS command. + + Note that the use of this feature has allowed much wider + penetration into numerous hosts on local networks (and + sometimes remote networks) by those who gain illegal + access to computers by guessing passwords or otherwise + breaking into the system. + + Possible Responses: + +OK maildrop locked and ready + -ERR permission denied + Examples: + C: USER mrose + S: +OK mrose is a real hoopy frood + C: RPOP mrose + S: +OK mrose's maildrop has 2 messages (320 + octets) + + 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 + LAST + RSET + + + + +Rose [Page 12] + +RFC 1081 POP3 November 1988 + + + QUIT valid in the UPDATE state + + Optional POP3 Commands: + RPOP user valid in the AUTHORIZATION state + + TOP msg n valid in the TRANSACTION state + + POP3 Replies: + +OK + -ERR + + Note that with the exception of the STAT command, 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. + +Example POP3 Session + + S: + ... + C: + S: +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU) + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + 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: + S: . + C: DELE 1 + S: +OK message 1 deleted + C: RETR 2 + S: +OK 200 octets + S: + S: . + C: DELE 2 + S: +OK message 2 deleted + C: QUIT + + + + + +Rose [Page 13] + +RFC 1081 POP3 November 1988 + + + S: +OK dewey POP3 server signing off (maildrop empty) + C: + S: + +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 byte 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 client + can calculate the size of each message in octets when it parses the + maildrop into messages. 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 be counted twice, since the POP3 + client will remove all byte-stuffed termination characters when it + receives a multi-line response. + +The POP and the Split-UA model + + The underlying paradigm in which the POP3 functions is that of a + split-UA model. The POP3 client host, being a remote PC based + workstation, acts solely as a client to the message transport system. + It does not provide delivery/authentication services to others. + Hence, it is acting as a UA, on behalf of the person using the + workstation. Furthermore, the workstation uses SMTP to enter mail + into the MTS. + + In this sense, we have two UA functions which interface to the + message transport system: Posting (SMTP) and Retrieval (POP3). The + entity which supports this type of environment is called a split-UA + (since the user agent is split between two hosts which must + interoperate to provide these functions). + + ASIDE: Others might term this a remote-UA instead. + There are arguments supporting the use of both terms. + + This memo has explicitly referenced TCP as the underlying transport + agent for the POP3. This need not be the case. In the MZnet split- + UA, for example, personal micro-computer systems are used which do + not have IP-style networking capability. To connect to the POP3 + server host, a PC establishes a terminal connection using some simple + protocol (PhoneNet). A program on the PC drives the connection, + first establishing a login session as a normal user. The login shell + + + +Rose [Page 14] + +RFC 1081 POP3 November 1988 + + + for this pseudo-user is a program which drives the other half of the + terminal protocol and communicates with one of two servers. Although + MZnet can support several PCs, a single pseudo-user login is present + on the server host. The user-id and password for this pseudo-user + login is known to all members of MZnet. Hence, the first action of + the login shell, after starting the terminal protocol, is to demand a + USER/PASS authorization pair from the PC. This second level of + authorization is used to ascertain who is interacting with the MTS. + Although the server host is deemed to support a "trusted" MTS entity, + PCs in MZnet are not. Naturally, the USER/PASS authorization pair + for a PC is known only to the owner of the PC (in theory, at least). + + After successfully verifying the identity of the client, a modified + SMTP server is started, and the PC posts mail with the server host. + After the QUIT command is given to the SMTP server and it terminates, + a modified POP3 server is started, and the PC retrieves mail from the + server host. After the QUIT command is given to the POP3 server and + it terminates, the login shell for the pseudo-user terminates the + terminal protocol and logs the job out. The PC then closes the + terminal connection to the server host. + + The SMTP server used by MZnet is modified in the sense that it knows + that it's talking to a user agent and not a "trusted" entity in the + message transport system. Hence, it does performs the validation + activities normally performed by an entity in the MTS when it accepts + a message from a UA. + + The POP3 server used by MZnet is modified in the sense that it does + not require a USER/PASS combination before entering the TRANSACTION + state. The reason for this (of course) is that the PC has already + identified itself during the second-level authorization step + described above. + + NOTE: Truth in advertising laws require that the author + of this memo state that MZnet has not actually been + fully implemented. The concepts presented and proven + by the project led to the notion of the MZnet + split-slot model. This notion has inspired the + split-UA concept described in this memo, led to the + author's interest in the POP, and heavily influenced + the the description of the POP3 herein. + + In fact, some UAs present in the Internet already support the notion + of posting directly to an SMTP server and retrieving mail directly + from a POP server, even if the POP server and client resided on the + same host! + + ASIDE: this discussion raises an issue which this memo + + + +Rose [Page 15] + +RFC 1081 POP3 November 1988 + + + purposedly avoids: how does SMTP know that it's talking + to a "trusted" MTS entity? + +References + + [MZnet] Stefferud, E., J. Sweet, and T. Domae, "MZnet: Mail + Service for Personal Micro-Computer Systems", + Proceedings, IFIP 6.5 International Conference on + Computer Message Systems, Nottingham, U.K., May 1984. + + [RFC821] Postel, J., "Simple Mail Transfer Protocol", + USC/Information Sciences Institute, August 1982. + + [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet + Text Messages", University of Delaware, August 1982. + + [RFC937] Butler, M., J. Postel, D. Chase, J. Goldberger, and J. + Reynolds, "Post Office Protocol - Version 2", RFC 937, + USC/Information Sciences Institute, February 1985. + + [RFC1010] Reynolds, J., and J. Postel, "Assigned Numbers", RFC + 1010, USC/Information Sciences Institute, May 1987. + +Author's Address: + + + Marshall Rose + The Wollongong Group + 1129 San Antonio Rd. + Palo Alto, California 94303 + + Phone: (415) 962-7100 + + Email: MRose@TWG.COM + + + + + + + + + + + + + + + + + +Rose [Page 16] + \ No newline at end of file diff --git a/RFC/rfc1123.txt b/RFC/rfc1123.txt new file mode 100644 index 00000000..51cdf83c --- /dev/null +++ b/RFC/rfc1123.txt @@ -0,0 +1,5782 @@ + + + + + + +Network Working Group Internet Engineering Task Force +Request for Comments: 1123 R. Braden, Editor + October 1989 + + + Requirements for Internet Hosts -- Application and Support + +Status of This Memo + + This RFC is an official specification for the Internet community. It + incorporates by reference, amends, corrects, and supplements the + primary protocol standards documents relating to hosts. Distribution + of this document is unlimited. + +Summary + + This RFC is one of a pair that defines and discusses the requirements + for Internet host software. This RFC covers the application and + support protocols; its companion RFC-1122 covers the communication + protocol layers: link layer, IP layer, and transport layer. + + + + Table of Contents + + + + + 1. INTRODUCTION ............................................... 5 + 1.1 The Internet Architecture .............................. 6 + 1.2 General Considerations ................................. 6 + 1.2.1 Continuing Internet Evolution ..................... 6 + 1.2.2 Robustness Principle .............................. 7 + 1.2.3 Error Logging ..................................... 8 + 1.2.4 Configuration ..................................... 8 + 1.3 Reading this Document .................................. 10 + 1.3.1 Organization ...................................... 10 + 1.3.2 Requirements ...................................... 10 + 1.3.3 Terminology ....................................... 11 + 1.4 Acknowledgments ........................................ 12 + + 2. GENERAL ISSUES ............................................. 13 + 2.1 Host Names and Numbers ................................. 13 + 2.2 Using Domain Name Service .............................. 13 + 2.3 Applications on Multihomed hosts ....................... 14 + 2.4 Type-of-Service ........................................ 14 + 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY ............... 15 + + + + +Internet Engineering Task Force [Page 1] + + + + +RFC1123 INTRODUCTION October 1989 + + + 3. REMOTE LOGIN -- TELNET PROTOCOL ............................ 16 + 3.1 INTRODUCTION ........................................... 16 + 3.2 PROTOCOL WALK-THROUGH .................................. 16 + 3.2.1 Option Negotiation ................................ 16 + 3.2.2 Telnet Go-Ahead Function .......................... 16 + 3.2.3 Control Functions ................................. 17 + 3.2.4 Telnet "Synch" Signal ............................. 18 + 3.2.5 NVT Printer and Keyboard .......................... 19 + 3.2.6 Telnet Command Structure .......................... 20 + 3.2.7 Telnet Binary Option .............................. 20 + 3.2.8 Telnet Terminal-Type Option ....................... 20 + 3.3 SPECIFIC ISSUES ........................................ 21 + 3.3.1 Telnet End-of-Line Convention ..................... 21 + 3.3.2 Data Entry Terminals .............................. 23 + 3.3.3 Option Requirements ............................... 24 + 3.3.4 Option Initiation ................................. 24 + 3.3.5 Telnet Linemode Option ............................ 25 + 3.4 TELNET/USER INTERFACE .................................. 25 + 3.4.1 Character Set Transparency ........................ 25 + 3.4.2 Telnet Commands ................................... 26 + 3.4.3 TCP Connection Errors ............................. 26 + 3.4.4 Non-Default Telnet Contact Port ................... 26 + 3.4.5 Flushing Output ................................... 26 + 3.5. TELNET REQUIREMENTS SUMMARY ........................... 27 + + 4. FILE TRANSFER .............................................. 29 + 4.1 FILE TRANSFER PROTOCOL -- FTP .......................... 29 + 4.1.1 INTRODUCTION ...................................... 29 + 4.1.2. PROTOCOL WALK-THROUGH ............................ 29 + 4.1.2.1 LOCAL Type ................................... 29 + 4.1.2.2 Telnet Format Control ........................ 30 + 4.1.2.3 Page Structure ............................... 30 + 4.1.2.4 Data Structure Transformations ............... 30 + 4.1.2.5 Data Connection Management ................... 31 + 4.1.2.6 PASV Command ................................. 31 + 4.1.2.7 LIST and NLST Commands ....................... 31 + 4.1.2.8 SITE Command ................................. 32 + 4.1.2.9 STOU Command ................................. 32 + 4.1.2.10 Telnet End-of-line Code ..................... 32 + 4.1.2.11 FTP Replies ................................. 33 + 4.1.2.12 Connections ................................. 34 + 4.1.2.13 Minimum Implementation; RFC-959 Section ..... 34 + 4.1.3 SPECIFIC ISSUES ................................... 35 + 4.1.3.1 Non-standard Command Verbs ................... 35 + 4.1.3.2 Idle Timeout ................................. 36 + 4.1.3.3 Concurrency of Data and Control .............. 36 + 4.1.3.4 FTP Restart Mechanism ........................ 36 + 4.1.4 FTP/USER INTERFACE ................................ 39 + + + +Internet Engineering Task Force [Page 2] + + + + +RFC1123 INTRODUCTION October 1989 + + + 4.1.4.1 Pathname Specification ....................... 39 + 4.1.4.2 "QUOTE" Command .............................. 40 + 4.1.4.3 Displaying Replies to User ................... 40 + 4.1.4.4 Maintaining Synchronization .................. 40 + 4.1.5 FTP REQUIREMENTS SUMMARY ......................... 41 + 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP ................. 44 + 4.2.1 INTRODUCTION ...................................... 44 + 4.2.2 PROTOCOL WALK-THROUGH ............................. 44 + 4.2.2.1 Transfer Modes ............................... 44 + 4.2.2.2 UDP Header ................................... 44 + 4.2.3 SPECIFIC ISSUES ................................... 44 + 4.2.3.1 Sorcerer's Apprentice Syndrome ............... 44 + 4.2.3.2 Timeout Algorithms ........................... 46 + 4.2.3.3 Extensions ................................... 46 + 4.2.3.4 Access Control ............................... 46 + 4.2.3.5 Broadcast Request ............................ 46 + 4.2.4 TFTP REQUIREMENTS SUMMARY ......................... 47 + + 5. ELECTRONIC MAIL -- SMTP and RFC-822 ........................ 48 + 5.1 INTRODUCTION ........................................... 48 + 5.2 PROTOCOL WALK-THROUGH .................................. 48 + 5.2.1 The SMTP Model .................................... 48 + 5.2.2 Canonicalization .................................. 49 + 5.2.3 VRFY and EXPN Commands ............................ 50 + 5.2.4 SEND, SOML, and SAML Commands ..................... 50 + 5.2.5 HELO Command ...................................... 50 + 5.2.6 Mail Relay ........................................ 51 + 5.2.7 RCPT Command ...................................... 52 + 5.2.8 DATA Command ...................................... 53 + 5.2.9 Command Syntax .................................... 54 + 5.2.10 SMTP Replies ..................................... 54 + 5.2.11 Transparency ..................................... 55 + 5.2.12 WKS Use in MX Processing ......................... 55 + 5.2.13 RFC-822 Message Specification .................... 55 + 5.2.14 RFC-822 Date and Time Specification .............. 55 + 5.2.15 RFC-822 Syntax Change ............................ 56 + 5.2.16 RFC-822 Local-part .............................. 56 + 5.2.17 Domain Literals .................................. 57 + 5.2.18 Common Address Formatting Errors ................. 58 + 5.2.19 Explicit Source Routes ........................... 58 + 5.3 SPECIFIC ISSUES ........................................ 59 + 5.3.1 SMTP Queueing Strategies .......................... 59 + 5.3.1.1 Sending Strategy .............................. 59 + 5.3.1.2 Receiving strategy ........................... 61 + 5.3.2 Timeouts in SMTP .................................. 61 + 5.3.3 Reliable Mail Receipt ............................. 63 + 5.3.4 Reliable Mail Transmission ........................ 63 + 5.3.5 Domain Name Support ............................... 65 + + + +Internet Engineering Task Force [Page 3] + + + + +RFC1123 INTRODUCTION October 1989 + + + 5.3.6 Mailing Lists and Aliases ......................... 65 + 5.3.7 Mail Gatewaying ................................... 66 + 5.3.8 Maximum Message Size .............................. 68 + 5.4 SMTP REQUIREMENTS SUMMARY .............................. 69 + + 6. SUPPORT SERVICES ............................................ 72 + 6.1 DOMAIN NAME TRANSLATION ................................. 72 + 6.1.1 INTRODUCTION ....................................... 72 + 6.1.2 PROTOCOL WALK-THROUGH ............................. 72 + 6.1.2.1 Resource Records with Zero TTL ............... 73 + 6.1.2.2 QCLASS Values ................................ 73 + 6.1.2.3 Unused Fields ................................ 73 + 6.1.2.4 Compression .................................. 73 + 6.1.2.5 Misusing Configuration Info .................. 73 + 6.1.3 SPECIFIC ISSUES ................................... 74 + 6.1.3.1 Resolver Implementation ...................... 74 + 6.1.3.2 Transport Protocols .......................... 75 + 6.1.3.3 Efficient Resource Usage ..................... 77 + 6.1.3.4 Multihomed Hosts ............................. 78 + 6.1.3.5 Extensibility ................................ 79 + 6.1.3.6 Status of RR Types ........................... 79 + 6.1.3.7 Robustness ................................... 80 + 6.1.3.8 Local Host Table ............................. 80 + 6.1.4 DNS USER INTERFACE ................................ 81 + 6.1.4.1 DNS Administration ........................... 81 + 6.1.4.2 DNS User Interface ........................... 81 + 6.1.4.3 Interface Abbreviation Facilities ............. 82 + 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ........... 84 + 6.2 HOST INITIALIZATION .................................... 87 + 6.2.1 INTRODUCTION ...................................... 87 + 6.2.2 REQUIREMENTS ...................................... 87 + 6.2.2.1 Dynamic Configuration ........................ 87 + 6.2.2.2 Loading Phase ................................ 89 + 6.3 REMOTE MANAGEMENT ...................................... 90 + 6.3.1 INTRODUCTION ...................................... 90 + 6.3.2 PROTOCOL WALK-THROUGH ............................. 90 + 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY ................... 92 + + 7. REFERENCES ................................................. 93 + + + + + + + + + + + + +Internet Engineering Task Force [Page 4] + + + + +RFC1123 INTRODUCTION October 1989 + + +1. INTRODUCTION + + This document is one of a pair that defines and discusses the + requirements for host system implementations of the Internet protocol + suite. This RFC covers the applications layer and support protocols. + Its companion RFC, "Requirements for Internet Hosts -- Communications + Layers" [INTRO:1] covers the lower layer protocols: transport layer, + IP layer, and link layer. + + These documents are intended to provide guidance for vendors, + implementors, and users of Internet communication software. They + represent the consensus of a large body of technical experience and + wisdom, contributed by members of the Internet research and vendor + communities. + + This RFC enumerates standard protocols that a host connected to the + Internet must use, and it incorporates by reference the RFCs and + other documents describing the current specifications for these + protocols. It corrects errors in the referenced documents and adds + additional discussion and guidance for an implementor. + + For each protocol, this document also contains an explicit set of + requirements, recommendations, and options. The reader must + understand that the list of requirements in this document is + incomplete by itself; the complete set of requirements for an + Internet host is primarily defined in the standard protocol + specification documents, with the corrections, amendments, and + supplements contained in this RFC. + + A good-faith implementation of the protocols that was produced after + careful reading of the RFC's and with some interaction with the + Internet technical community, and that followed good communications + software engineering practices, should differ from the requirements + of this document in only minor ways. Thus, in many cases, the + "requirements" in this RFC are already stated or implied in the + standard protocol documents, so that their inclusion here is, in a + sense, redundant. However, they were included because some past + implementation has made the wrong choice, causing problems of + interoperability, performance, and/or robustness. + + This document includes discussion and explanation of many of the + requirements and recommendations. A simple list of requirements + would be dangerous, because: + + o Some required features are more important than others, and some + features are optional. + + o There may be valid reasons why particular vendor products that + + + +Internet Engineering Task Force [Page 5] + + + + +RFC1123 INTRODUCTION October 1989 + + + are designed for restricted contexts might choose to use + different specifications. + + However, the specifications of this document must be followed to meet + the general goal of arbitrary host interoperation across the + diversity and complexity of the Internet system. Although most + current implementations fail to meet these requirements in various + ways, some minor and some major, this specification is the ideal + towards which we need to move. + + These requirements are based on the current level of Internet + architecture. This document will be updated as required to provide + additional clarifications or to include additional information in + those areas in which specifications are still evolving. + + This introductory section begins with general advice to host software + vendors, and then gives some guidance on reading the rest of the + document. Section 2 contains general requirements that may be + applicable to all application and support protocols. Sections 3, 4, + and 5 contain the requirements on protocols for the three major + applications: Telnet, file transfer, and electronic mail, + respectively. Section 6 covers the support applications: the domain + name system, system initialization, and management. Finally, all + references will be found in Section 7. + + 1.1 The Internet Architecture + + For a brief introduction to the Internet architecture from a host + viewpoint, see Section 1.1 of [INTRO:1]. That section also + contains recommended references for general background on the + Internet architecture. + + 1.2 General Considerations + + There are two important lessons that vendors of Internet host + software have learned and which a new vendor should consider + seriously. + + 1.2.1 Continuing Internet Evolution + + The enormous growth of the Internet has revealed problems of + management and scaling in a large datagram-based packet + communication system. These problems are being addressed, and + as a result there will be continuing evolution of the + specifications described in this document. These changes will + be carefully planned and controlled, since there is extensive + participation in this planning by the vendors and by the + organizations responsible for operations of the networks. + + + +Internet Engineering Task Force [Page 6] + + + + +RFC1123 INTRODUCTION October 1989 + + + Development, evolution, and revision are characteristic of + computer network protocols today, and this situation will + persist for some years. A vendor who develops computer + communication software for the Internet protocol suite (or any + other protocol suite!) and then fails to maintain and update + that software for changing specifications is going to leave a + trail of unhappy customers. The Internet is a large + communication network, and the users are in constant contact + through it. Experience has shown that knowledge of + deficiencies in vendor software propagates quickly through the + Internet technical community. + + 1.2.2 Robustness Principle + + At every layer of the protocols, there is a general rule whose + application can lead to enormous benefits in robustness and + interoperability: + + "Be liberal in what you accept, and + conservative in what you send" + + Software should be written to deal with every conceivable + error, no matter how unlikely; sooner or later a packet will + come in with that particular combination of errors and + attributes, and unless the software is prepared, chaos can + ensue. In general, it is best to assume that the network is + filled with malevolent entities that will send in packets + designed to have the worst possible effect. This assumption + will lead to suitable protective design, although the most + serious problems in the Internet have been caused by + unenvisaged mechanisms triggered by low-probability events; + mere human malice would never have taken so devious a course! + + Adaptability to change must be designed into all levels of + Internet host software. As a simple example, consider a + protocol specification that contains an enumeration of values + for a particular header field -- e.g., a type field, a port + number, or an error code; this enumeration must be assumed to + be incomplete. Thus, if a protocol specification defines four + possible error codes, the software must not break when a fifth + code shows up. An undefined code might be logged (see below), + but it must not cause a failure. + + The second part of the principle is almost as important: + software on other hosts may contain deficiencies that make it + unwise to exploit legal but obscure protocol features. It is + unwise to stray far from the obvious and simple, lest untoward + effects result elsewhere. A corollary of this is "watch out + + + +Internet Engineering Task Force [Page 7] + + + + +RFC1123 INTRODUCTION October 1989 + + + for misbehaving hosts"; host software should be prepared, not + just to survive other misbehaving hosts, but also to cooperate + to limit the amount of disruption such hosts can cause to the + shared communication facility. + + 1.2.3 Error Logging + + The Internet includes a great variety of host and gateway + systems, each implementing many protocols and protocol layers, + and some of these contain bugs and mis-features in their + Internet protocol software. As a result of complexity, + diversity, and distribution of function, the diagnosis of user + problems is often very difficult. + + Problem diagnosis will be aided if host implementations include + a carefully designed facility for logging erroneous or + "strange" protocol events. It is important to include as much + diagnostic information as possible when an error is logged. In + particular, it is often useful to record the header(s) of a + packet that caused an error. However, care must be taken to + ensure that error logging does not consume prohibitive amounts + of resources or otherwise interfere with the operation of the + host. + + There is a tendency for abnormal but harmless protocol events + to overflow error logging files; this can be avoided by using a + "circular" log, or by enabling logging only while diagnosing a + known failure. It may be useful to filter and count duplicate + successive messages. One strategy that seems to work well is: + (1) always count abnormalities and make such counts accessible + through the management protocol (see Section 6.3); and (2) + allow the logging of a great variety of events to be + selectively enabled. For example, it might useful to be able + to "log everything" or to "log everything for host X". + + Note that different managements may have differing policies + about the amount of error logging that they want normally + enabled in a host. Some will say, "if it doesn't hurt me, I + don't want to know about it", while others will want to take a + more watchful and aggressive attitude about detecting and + removing protocol abnormalities. + + 1.2.4 Configuration + + It would be ideal if a host implementation of the Internet + protocol suite could be entirely self-configuring. This would + allow the whole suite to be implemented in ROM or cast into + silicon, it would simplify diskless workstations, and it would + + + +Internet Engineering Task Force [Page 8] + + + + +RFC1123 INTRODUCTION October 1989 + + + be an immense boon to harried LAN administrators as well as + system vendors. We have not reached this ideal; in fact, we + are not even close. + + At many points in this document, you will find a requirement + that a parameter be a configurable option. There are several + different reasons behind such requirements. In a few cases, + there is current uncertainty or disagreement about the best + value, and it may be necessary to update the recommended value + in the future. In other cases, the value really depends on + external factors -- e.g., the size of the host and the + distribution of its communication load, or the speeds and + topology of nearby networks -- and self-tuning algorithms are + unavailable and may be insufficient. In some cases, + configurability is needed because of administrative + requirements. + + Finally, some configuration options are required to communicate + with obsolete or incorrect implementations of the protocols, + distributed without sources, that unfortunately persist in many + parts of the Internet. To make correct systems coexist with + these faulty systems, administrators often have to "mis- + configure" the correct systems. This problem will correct + itself gradually as the faulty systems are retired, but it + cannot be ignored by vendors. + + When we say that a parameter must be configurable, we do not + intend to require that its value be explicitly read from a + configuration file at every boot time. We recommend that + implementors set up a default for each parameter, so a + configuration file is only necessary to override those defaults + that are inappropriate in a particular installation. Thus, the + configurability requirement is an assurance that it will be + POSSIBLE to override the default when necessary, even in a + binary-only or ROM-based product. + + This document requires a particular value for such defaults in + some cases. The choice of default is a sensitive issue when + the configuration item controls the accommodation to existing + faulty systems. If the Internet is to converge successfully to + complete interoperability, the default values built into + implementations must implement the official protocol, not + "mis-configurations" to accommodate faulty implementations. + Although marketing considerations have led some vendors to + choose mis-configuration defaults, we urge vendors to choose + defaults that will conform to the standard. + + Finally, we note that a vendor needs to provide adequate + + + +Internet Engineering Task Force [Page 9] + + + + +RFC1123 INTRODUCTION October 1989 + + + documentation on all configuration parameters, their limits and + effects. + + + 1.3 Reading this Document + + 1.3.1 Organization + + In general, each major section is organized into the following + subsections: + + (1) Introduction + + (2) Protocol Walk-Through -- considers the protocol + specification documents section-by-section, correcting + errors, stating requirements that may be ambiguous or + ill-defined, and providing further clarification or + explanation. + + (3) Specific Issues -- discusses protocol design and + implementation issues that were not included in the walk- + through. + + (4) Interfaces -- discusses the service interface to the next + higher layer. + + (5) Summary -- contains a summary of the requirements of the + section. + + Under many of the individual topics in this document, there is + parenthetical material labeled "DISCUSSION" or + "IMPLEMENTATION". This material is intended to give + clarification and explanation of the preceding requirements + text. It also includes some suggestions on possible future + directions or developments. The implementation material + contains suggested approaches that an implementor may want to + consider. + + The summary sections are intended to be guides and indexes to + the text, but are necessarily cryptic and incomplete. The + summaries should never be used or referenced separately from + the complete RFC. + + 1.3.2 Requirements + + In this document, the words that are used to define the + significance of each particular requirement are capitalized. + These words are: + + + +Internet Engineering Task Force [Page 10] + + + + +RFC1123 INTRODUCTION October 1989 + + + * "MUST" + + This word or the adjective "REQUIRED" means that the item + is an absolute requirement of the specification. + + * "SHOULD" + + This word or the adjective "RECOMMENDED" means that there + may exist valid reasons in particular circumstances to + ignore this item, but the full implications should be + understood and the case carefully weighed before choosing + a different course. + + * "MAY" + + This word or the adjective "OPTIONAL" means that this item + is truly optional. One vendor may choose to include the + item because a particular marketplace requires it or + because it enhances the product, for example; another + vendor may omit the same item. + + + An implementation is not compliant if it fails to satisfy one + or more of the MUST requirements for the protocols it + implements. An implementation that satisfies all the MUST and + all the SHOULD requirements for its protocols is said to be + "unconditionally compliant"; one that satisfies all the MUST + requirements but not all the SHOULD requirements for its + protocols is said to be "conditionally compliant". + + 1.3.3 Terminology + + This document uses the following technical terms: + + Segment + A segment is the unit of end-to-end transmission in the + TCP protocol. A segment consists of a TCP header followed + by application data. A segment is transmitted by + encapsulation in an IP datagram. + + Message + This term is used by some application layer protocols + (particularly SMTP) for an application data unit. + + Datagram + A [UDP] datagram is the unit of end-to-end transmission in + the UDP protocol. + + + + +Internet Engineering Task Force [Page 11] + + + + +RFC1123 INTRODUCTION October 1989 + + + Multihomed + A host is said to be multihomed if it has multiple IP + addresses to connected networks. + + + + 1.4 Acknowledgments + + This document incorporates contributions and comments from a large + group of Internet protocol experts, including representatives of + university and research labs, vendors, and government agencies. + It was assembled primarily by the Host Requirements Working Group + of the Internet Engineering Task Force (IETF). + + The Editor would especially like to acknowledge the tireless + dedication of the following people, who attended many long + meetings and generated 3 million bytes of electronic mail over the + past 18 months in pursuit of this document: Philip Almquist, Dave + Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve + Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), + John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), + Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge + (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software). + + In addition, the following people made major contributions to the + effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia + (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), + Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), + John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill + Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul + (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue + Technology), and Mike StJohns (DCA). The following also made + significant contributions to particular areas: Eric Allman + (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic + (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn + (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann + (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun + Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen + (Toronto). + + We are grateful to all, including any contributors who may have + been inadvertently omitted from this list. + + + + + + + + + +Internet Engineering Task Force [Page 12] + + + + +RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 + + +2. GENERAL ISSUES + + This section contains general requirements that may be applicable to + all application-layer protocols. + + 2.1 Host Names and Numbers + + The syntax of a legal Internet host name was specified in RFC-952 + [DNS:4]. One aspect of host name syntax is hereby changed: the + restriction on the first character is relaxed to allow either a + letter or a digit. Host software MUST support this more liberal + syntax. + + Host software MUST handle host names of up to 63 characters and + SHOULD handle host names of up to 255 characters. + + Whenever a user inputs the identity of an Internet host, it SHOULD + be possible to enter either (1) a host domain name or (2) an IP + address in dotted-decimal ("#.#.#.#") form. The host SHOULD check + the string syntactically for a dotted-decimal number before + looking it up in the Domain Name System. + + DISCUSSION: + This last requirement is not intended to specify the complete + syntactic form for entering a dotted-decimal host number; + that is considered to be a user-interface issue. For + example, a dotted-decimal number must be enclosed within + "[ ]" brackets for SMTP mail (see Section 5.2.17). This + notation could be made universal within a host system, + simplifying the syntactic checking for a dotted-decimal + number. + + If a dotted-decimal number can be entered without such + identifying delimiters, then a full syntactic check must be + made, because a segment of a host domain name is now allowed + to begin with a digit and could legally be entirely numeric + (see Section 6.1.2.4). However, a valid host name can never + have the dotted-decimal form #.#.#.#, since at least the + highest-level component label will be alphabetic. + + 2.2 Using Domain Name Service + + Host domain names MUST be translated to IP addresses as described + in Section 6.1. + + Applications using domain name services MUST be able to cope with + soft error conditions. Applications MUST wait a reasonable + interval between successive retries due to a soft error, and MUST + + + +Internet Engineering Task Force [Page 13] + + + + +RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 + + + allow for the possibility that network problems may deny service + for hours or even days. + + An application SHOULD NOT rely on the ability to locate a WKS + record containing an accurate listing of all services at a + particular host address, since the WKS RR type is not often used + by Internet sites. To confirm that a service is present, simply + attempt to use it. + + 2.3 Applications on Multihomed hosts + + When the remote host is multihomed, the name-to-address + translation will return a list of alternative IP addresses. As + specified in Section 6.1.3.4, this list should be in order of + decreasing preference. Application protocol implementations + SHOULD be prepared to try multiple addresses from the list until + success is obtained. More specific requirements for SMTP are + given in Section 5.3.4. + + When the local host is multihomed, a UDP-based request/response + application SHOULD send the response with an IP source address + that is the same as the specific destination address of the UDP + request datagram. The "specific destination address" is defined + in the "IP Addressing" section of the companion RFC [INTRO:1]. + + Similarly, a server application that opens multiple TCP + connections to the same client SHOULD use the same local IP + address for all. + + 2.4 Type-of-Service + + Applications MUST select appropriate TOS values when they invoke + transport layer services, and these values MUST be configurable. + Note that a TOS value contains 5 bits, of which only the most- + significant 3 bits are currently defined; the other two bits MUST + be zero. + + DISCUSSION: + As gateway algorithms are developed to implement Type-of- + Service, the recommended values for various application + protocols may change. In addition, it is likely that + particular combinations of users and Internet paths will want + non-standard TOS values. For these reasons, the TOS values + must be configurable. + + See the latest version of the "Assigned Numbers" RFC + [INTRO:5] for the recommended TOS values for the major + application protocols. + + + +Internet Engineering Task Force [Page 14] + + + + +RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 + + + 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|----------|-|-|-|-|-|-- + | | | | | | | +User interfaces: | | | | | | | + Allow host name to begin with digit |2.1 |x| | | | | + Host names of up to 635 characters |2.1 |x| | | | | + Host names of up to 255 characters |2.1 | |x| | | | + Support dotted-decimal host numbers |2.1 | |x| | | | + Check syntactically for dotted-dec first |2.1 | |x| | | | + | | | | | | | +Map domain names per Section 6.1 |2.2 |x| | | | | +Cope with soft DNS errors |2.2 |x| | | | | + Reasonable interval between retries |2.2 |x| | | | | + Allow for long outages |2.2 |x| | | | | +Expect WKS records to be available |2.2 | | | |x| | + | | | | | | | +Try multiple addr's for remote multihomed host |2.3 | |x| | | | +UDP reply src addr is specific dest of request |2.3 | |x| | | | +Use same IP addr for related TCP connections |2.3 | |x| | | | +Specify appropriate TOS values |2.4 |x| | | | | + TOS values configurable |2.4 |x| | | | | + Unused TOS bits zero |2.4 |x| | | | | + | | | | | | | + | | | | | | | + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 15] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + +3. REMOTE LOGIN -- TELNET PROTOCOL + + 3.1 INTRODUCTION + + Telnet is the standard Internet application protocol for remote + login. It provides the encoding rules to link a user's + keyboard/display on a client ("user") system with a command + interpreter on a remote server system. A subset of the Telnet + protocol is also incorporated within other application protocols, + e.g., FTP and SMTP. + + Telnet uses a single TCP connection, and its normal data stream + ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with + escape sequences to embed control functions. Telnet also allows + the negotiation of many optional modes and functions. + + The primary Telnet specification is to be found in RFC-854 + [TELNET:1], while the options are defined in many other RFCs; see + Section 7 for references. + + 3.2 PROTOCOL WALK-THROUGH + + 3.2.1 Option Negotiation: RFC-854, pp. 2-3 + + Every Telnet implementation MUST include option negotiation and + subnegotiation machinery [TELNET:2]. + + A host MUST carefully follow the rules of RFC-854 to avoid + option-negotiation loops. A host MUST refuse (i.e, reply + WONT/DONT to a DO/WILL) an unsupported option. Option + negotiation SHOULD continue to function (even if all requests + are refused) throughout the lifetime of a Telnet connection. + + If all option negotiations fail, a Telnet implementation MUST + default to, and support, an NVT. + + DISCUSSION: + Even though more sophisticated "terminals" and supporting + option negotiations are becoming the norm, all + implementations must be prepared to support an NVT for any + user-server communication. + + 3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858 + + On a host that never sends the Telnet command Go Ahead (GA), + the Telnet Server MUST attempt to negotiate the Suppress Go + Ahead option (i.e., send "WILL Suppress Go Ahead"). A User or + Server Telnet MUST always accept negotiation of the Suppress Go + + + +Internet Engineering Task Force [Page 16] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + Ahead option. + + When it is driving a full-duplex terminal for which GA has no + meaning, a User Telnet implementation MAY ignore GA commands. + + DISCUSSION: + Half-duplex ("locked-keyboard") line-at-a-time terminals + for which the Go-Ahead mechanism was designed have largely + disappeared from the scene. It turned out to be difficult + to implement sending the Go-Ahead signal in many operating + systems, even some systems that support native half-duplex + terminals. The difficulty is typically that the Telnet + server code does not have access to information about + whether the user process is blocked awaiting input from + the Telnet connection, i.e., it cannot reliably determine + when to send a GA command. Therefore, most Telnet Server + hosts do not send GA commands. + + The effect of the rules in this section is to allow either + end of a Telnet connection to veto the use of GA commands. + + There is a class of half-duplex terminals that is still + commercially important: "data entry terminals," which + interact in a full-screen manner. However, supporting + data entry terminals using the Telnet protocol does not + require the Go Ahead signal; see Section 3.3.2. + + 3.2.3 Control Functions: RFC-854, pp. 7-8 + + The list of Telnet commands has been extended to include EOR + (End-of-Record), with code 239 [TELNET:9]. + + Both User and Server Telnets MAY support the control functions + EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP, + SB, and SE. + + A host MUST be able to receive and ignore any Telnet control + functions that it does not support. + + DISCUSSION: + Note that a Server Telnet is required to support the + Telnet IP (Interrupt Process) function, even if the server + host has an equivalent in-stream function (e.g., Control-C + in many systems). The Telnet IP function may be stronger + than an in-stream interrupt command, because of the out- + of-band effect of TCP urgent data. + + The EOR control function may be used to delimit the + + + +Internet Engineering Task Force [Page 17] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + stream. An important application is data entry terminal + support (see Section 3.3.2). There was concern that since + EOR had not been defined in RFC-854, a host that was not + prepared to correctly ignore unknown Telnet commands might + crash if it received an EOR. To protect such hosts, the + End-of-Record option [TELNET:9] was introduced; however, a + properly implemented Telnet program will not require this + protection. + + 3.2.4 Telnet "Synch" Signal: RFC-854, pp. 8-10 + + When it receives "urgent" TCP data, a User or Server Telnet + MUST discard all data except Telnet commands until the DM (and + end of urgent) is reached. + + When it sends Telnet IP (Interrupt Process), a User Telnet + SHOULD follow it by the Telnet "Synch" sequence, i.e., send as + TCP urgent data the sequence "IAC IP IAC DM". The TCP urgent + pointer points to the DM octet. + + When it receives a Telnet IP command, a Server Telnet MAY send + a Telnet "Synch" sequence back to the user, to flush the output + stream. The choice ought to be consistent with the way the + server operating system behaves when a local user interrupts a + process. + + When it receives a Telnet AO command, a Server Telnet MUST send + a Telnet "Synch" sequence back to the user, to flush the output + stream. + + A User Telnet SHOULD have the capability of flushing output + when it sends a Telnet IP; see also Section 3.4.5. + + DISCUSSION: + There are three possible ways for a User Telnet to flush + the stream of server output data: + + (1) Send AO after IP. + + This will cause the server host to send a "flush- + buffered-output" signal to its operating system. + However, the AO may not take effect locally, i.e., + stop terminal output at the User Telnet end, until + the Server Telnet has received and processed the AO + and has sent back a "Synch". + + (2) Send DO TIMING-MARK [TELNET:7] after IP, and discard + all output locally until a WILL/WONT TIMING-MARK is + + + +Internet Engineering Task Force [Page 18] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + received from the Server Telnet. + + Since the DO TIMING-MARK will be processed after the + IP at the server, the reply to it should be in the + right place in the output data stream. However, the + TIMING-MARK will not send a "flush buffered output" + signal to the server operating system. Whether or + not this is needed is dependent upon the server + system. + + (3) Do both. + + The best method is not entirely clear, since it must + accommodate a number of existing server hosts that do not + follow the Telnet standards in various ways. The safest + approach is probably to provide a user-controllable option + to select (1), (2), or (3). + + 3.2.5 NVT Printer and Keyboard: RFC-854, p. 11 + + In NVT mode, a Telnet SHOULD NOT send characters with the + high-order bit 1, and MUST NOT send it as a parity bit. + Implementations that pass the high-order bit to applications + SHOULD negotiate binary mode (see Section 3.2.6). + + + DISCUSSION: + Implementors should be aware that a strict reading of + RFC-854 allows a client or server expecting NVT ASCII to + ignore characters with the high-order bit set. In + general, binary mode is expected to be used for + transmission of an extended (beyond 7-bit) character set + with Telnet. + + However, there exist applications that really need an 8- + bit NVT mode, which is currently not defined, and these + existing applications do set the high-order bit during + part or all of the life of a Telnet connection. Note that + binary mode is not the same as 8-bit NVT mode, since + binary mode turns off end-of-line processing. For this + reason, the requirements on the high-order bit are stated + as SHOULD, not MUST. + + RFC-854 defines a minimal set of properties of a "network + virtual terminal" or NVT; this is not meant to preclude + additional features in a real terminal. A Telnet + connection is fully transparent to all 7-bit ASCII + characters, including arbitrary ASCII control characters. + + + +Internet Engineering Task Force [Page 19] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + For example, a terminal might support full-screen commands + coded as ASCII escape sequences; a Telnet implementation + would pass these sequences as uninterpreted data. Thus, + an NVT should not be conceived as a terminal type of a + highly-restricted device. + + 3.2.6 Telnet Command Structure: RFC-854, p. 13 + + Since options may appear at any point in the data stream, a + Telnet escape character (known as IAC, with the value 255) to + be sent as data MUST be doubled. + + 3.2.7 Telnet Binary Option: RFC-856 + + When the Binary option has been successfully negotiated, + arbitrary 8-bit characters are allowed. However, the data + stream MUST still be scanned for IAC characters, any embedded + Telnet commands MUST be obeyed, and data bytes equal to IAC + MUST be doubled. Other character processing (e.g., replacing + CR by CR NUL or by CR LF) MUST NOT be done. In particular, + there is no end-of-line convention (see Section 3.3.1) in + binary mode. + + DISCUSSION: + The Binary option is normally negotiated in both + directions, to change the Telnet connection from NVT mode + to "binary mode". + + The sequence IAC EOR can be used to delimit blocks of data + within a binary-mode Telnet stream. + + 3.2.8 Telnet Terminal-Type Option: RFC-1091 + + The Terminal-Type option MUST use the terminal type names + officially defined in the Assigned Numbers RFC [INTRO:5], when + they are available for the particular terminal. However, the + receiver of a Terminal-Type option MUST accept any name. + + DISCUSSION: + RFC-1091 [TELNET:10] updates an earlier version of the + Terminal-Type option defined in RFC-930. The earlier + version allowed a server host capable of supporting + multiple terminal types to learn the type of a particular + client's terminal, assuming that each physical terminal + had an intrinsic type. However, today a "terminal" is + often really a terminal emulator program running in a PC, + perhaps capable of emulating a range of terminal types. + Therefore, RFC-1091 extends the specification to allow a + + + +Internet Engineering Task Force [Page 20] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + more general terminal-type negotiation between User and + Server Telnets. + + 3.3 SPECIFIC ISSUES + + 3.3.1 Telnet End-of-Line Convention + + The Telnet protocol defines the sequence CR LF to mean "end- + of-line". For terminal input, this corresponds to a command- + completion or "end-of-line" key being pressed on a user + terminal; on an ASCII terminal, this is the CR key, but it may + also be labelled "Return" or "Enter". + + When a Server Telnet receives the Telnet end-of-line sequence + CR LF as input from a remote terminal, the effect MUST be the + same as if the user had pressed the "end-of-line" key on a + local terminal. On server hosts that use ASCII, in particular, + receipt of the Telnet sequence CR LF must cause the same effect + as a local user pressing the CR key on a local terminal. Thus, + CR LF and CR NUL MUST have the same effect on an ASCII server + host when received as input over a Telnet connection. + + A User Telnet MUST be able to send any of the forms: CR LF, CR + NUL, and LF. A User Telnet on an ASCII host SHOULD have a + user-controllable mode to send either CR LF or CR NUL when the + user presses the "end-of-line" key, and CR LF SHOULD be the + default. + + The Telnet end-of-line sequence CR LF MUST be used to send + Telnet data that is not terminal-to-computer (e.g., for Server + Telnet sending output, or the Telnet protocol incorporated + another application protocol). + + DISCUSSION: + To allow interoperability between arbitrary Telnet clients + and servers, the Telnet protocol defined a standard + representation for a line terminator. Since the ASCII + character set includes no explicit end-of-line character, + systems have chosen various representations, e.g., CR, LF, + and the sequence CR LF. The Telnet protocol chose the CR + LF sequence as the standard for network transmission. + + Unfortunately, the Telnet protocol specification in RFC- + 854 [TELNET:1] has turned out to be somewhat ambiguous on + what character(s) should be sent from client to server for + the "end-of-line" key. The result has been a massive and + continuing interoperability headache, made worse by + various faulty implementations of both User and Server + + + +Internet Engineering Task Force [Page 21] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + Telnets. + + Although the Telnet protocol is based on a perfectly + symmetric model, in a remote login session the role of the + user at a terminal differs from the role of the server + host. For example, RFC-854 defines the meaning of CR, LF, + and CR LF as output from the server, but does not specify + what the User Telnet should send when the user presses the + "end-of-line" key on the terminal; this turns out to be + the point at issue. + + When a user presses the "end-of-line" key, some User + Telnet implementations send CR LF, while others send CR + NUL (based on a different interpretation of the same + sentence in RFC-854). These will be equivalent for a + correctly-implemented ASCII server host, as discussed + above. For other servers, a mode in the User Telnet is + needed. + + The existence of User Telnets that send only CR NUL when + CR is pressed creates a dilemma for non-ASCII hosts: they + can either treat CR NUL as equivalent to CR LF in input, + thus precluding the possibility of entering a "bare" CR, + or else lose complete interworking. + + Suppose a user on host A uses Telnet to log into a server + host B, and then execute B's User Telnet program to log + into server host C. It is desirable for the Server/User + Telnet combination on B to be as transparent as possible, + i.e., to appear as if A were connected directly to C. In + particular, correct implementation will make B transparent + to Telnet end-of-line sequences, except that CR LF may be + translated to CR NUL or vice versa. + + IMPLEMENTATION: + To understand Telnet end-of-line issues, one must have at + least a general model of the relationship of Telnet to the + local operating system. The Server Telnet process is + typically coupled into the terminal driver software of the + operating system as a pseudo-terminal. A Telnet end-of- + line sequence received by the Server Telnet must have the + same effect as pressing the end-of-line key on a real + locally-connected terminal. + + Operating systems that support interactive character-at- + a-time applications (e.g., editors) typically have two + internal modes for their terminal I/O: a formatted mode, + in which local conventions for end-of-line and other + + + +Internet Engineering Task Force [Page 22] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + formatting rules have been applied to the data stream, and + a "raw" mode, in which the application has direct access + to every character as it was entered. A Server Telnet + must be implemented in such a way that these modes have + the same effect for remote as for local terminals. For + example, suppose a CR LF or CR NUL is received by the + Server Telnet on an ASCII host. In raw mode, a CR + character is passed to the application; in formatted mode, + the local system's end-of-line convention is used. + + 3.3.2 Data Entry Terminals + + DISCUSSION: + In addition to the line-oriented and character-oriented + ASCII terminals for which Telnet was designed, there are + several families of video display terminals that are + sometimes known as "data entry terminals" or DETs. The + IBM 3270 family is a well-known example. + + Two Internet protocols have been designed to support + generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET + option [TELNET:18, TELNET:19]. The DET option drives a + data entry terminal over a Telnet connection using (sub-) + negotiation. SUPDUP is a completely separate terminal + protocol, which can be entered from Telnet by negotiation. + Although both SUPDUP and the DET option have been used + successfully in particular environments, neither has + gained general acceptance or wide implementation. + + A different approach to DET interaction has been developed + for supporting the IBM 3270 family through Telnet, + although the same approach would be applicable to any DET. + The idea is to enter a "native DET" mode, in which the + native DET input/output stream is sent as binary data. + The Telnet EOR command is used to delimit logical records + (e.g., "screens") within this binary stream. + + IMPLEMENTATION: + The rules for entering and leaving native DET mode are as + follows: + + o The Server uses the Terminal-Type option [TELNET:10] + to learn that the client is a DET. + + o It is conventional, but not required, that both ends + negotiate the EOR option [TELNET:9]. + + o Both ends negotiate the Binary option [TELNET:3] to + + + +Internet Engineering Task Force [Page 23] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + enter native DET mode. + + o When either end negotiates out of binary mode, the + other end does too, and the mode then reverts to + normal NVT. + + + 3.3.3 Option Requirements + + Every Telnet implementation MUST support the Binary option + [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and + SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of- + Record [TELNET:9], and Extended Options List [TELNET:8] + options. + + A User or Server Telnet SHOULD support the Window Size Option + [TELNET:12] if the local operating system provides the + corresponding capability. + + DISCUSSION: + Note that the End-of-Record option only signifies that a + Telnet can receive a Telnet EOR without crashing; + therefore, every Telnet ought to be willing to accept + negotiation of the End-of-Record option. See also the + discussion in Section 3.2.3. + + 3.3.4 Option Initiation + + When the Telnet protocol is used in a client/server situation, + the server SHOULD initiate negotiation of the terminal + interaction mode it expects. + + DISCUSSION: + The Telnet protocol was defined to be perfectly + symmetrical, but its application is generally asymmetric. + Remote login has been known to fail because NEITHER side + initiated negotiation of the required non-default terminal + modes. It is generally the server that determines the + preferred mode, so the server needs to initiate the + negotiation; since the negotiation is symmetric, the user + can also initiate it. + + A client (User Telnet) SHOULD provide a means for users to + enable and disable the initiation of option negotiation. + + DISCUSSION: + A user sometimes needs to connect to an application + service (e.g., FTP or SMTP) that uses Telnet for its + + + +Internet Engineering Task Force [Page 24] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + control stream but does not support Telnet options. User + Telnet may be used for this purpose if initiation of + option negotiation is disabled. + + 3.3.5 Telnet Linemode Option + + DISCUSSION: + An important new Telnet option, LINEMODE [TELNET:12], has + been proposed. The LINEMODE option provides a standard + way for a User Telnet and a Server Telnet to agree that + the client rather than the server will perform terminal + character processing. When the client has prepared a + complete line of text, it will send it to the server in + (usually) one TCP packet. This option will greatly + decrease the packet cost of Telnet sessions and will also + give much better user response over congested or long- + delay networks. + + The LINEMODE option allows dynamic switching between local + and remote character processing. For example, the Telnet + connection will automatically negotiate into single- + character mode while a full screen editor is running, and + then return to linemode when the editor is finished. + + We expect that when this RFC is released, hosts should + implement the client side of this option, and may + implement the server side of this option. To properly + implement the server side, the server needs to be able to + tell the local system not to do any input character + processing, but to remember its current terminal state and + notify the Server Telnet process whenever the state + changes. This will allow password echoing and full screen + editors to be handled properly, for example. + + 3.4 TELNET/USER INTERFACE + + 3.4.1 Character Set Transparency + + User Telnet implementations SHOULD be able to send or receive + any 7-bit ASCII character. Where possible, any special + character interpretations by the user host's operating system + SHOULD be bypassed so that these characters can conveniently be + sent and received on the connection. + + Some character value MUST be reserved as "escape to command + mode"; conventionally, doubling this character allows it to be + entered as data. The specific character used SHOULD be user + selectable. + + + +Internet Engineering Task Force [Page 25] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + On binary-mode connections, a User Telnet program MAY provide + an escape mechanism for entering arbitrary 8-bit values, if the + host operating system doesn't allow them to be entered directly + from the keyboard. + + IMPLEMENTATION: + The transparency issues are less pressing on servers, but + implementors should take care in dealing with issues like: + masking off parity bits (sent by an older, non-conforming + client) before they reach programs that expect only NVT + ASCII, and properly handling programs that request 8-bit + data streams. + + 3.4.2 Telnet Commands + + A User Telnet program MUST provide a user the capability of + entering any of the Telnet control functions IP, AO, or AYT, + and SHOULD provide the capability of entering EC, EL, and + Break. + + 3.4.3 TCP Connection Errors + + A User Telnet program SHOULD report to the user any TCP errors + that are reported by the transport layer (see "TCP/Application + Layer Interface" section in [INTRO:1]). + + 3.4.4 Non-Default Telnet Contact Port + + A User Telnet program SHOULD allow the user to optionally + specify a non-standard contact port number at the Server Telnet + host. + + 3.4.5 Flushing Output + + A User Telnet program SHOULD provide the user the ability to + specify whether or not output should be flushed when an IP is + sent; see Section 3.2.4. + + For any output flushing scheme that causes the User Telnet to + flush output locally until a Telnet signal is received from the + Server, there SHOULD be a way for the user to manually restore + normal output, in case the Server fails to send the expected + signal. + + + + + + + + +Internet Engineering Task Force [Page 26] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + 3.5. TELNET REQUIREMENTS SUMMARY + + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-------------------------------------------------|--------|-|-|-|-|-|-- + | | | | | | | +Option Negotiation |3.2.1 |x| | | | | + Avoid negotiation loops |3.2.1 |x| | | | | + Refuse unsupported options |3.2.1 |x| | | | | + Negotiation OK anytime on connection |3.2.1 | |x| | | | + Default to NVT |3.2.1 |x| | | | | + Send official name in Term-Type option |3.2.8 |x| | | | | + Accept any name in Term-Type option |3.2.8 |x| | | | | + Implement Binary, Suppress-GA options |3.3.3 |x| | | | | + Echo, Status, EOL, Ext-Opt-List options |3.3.3 | |x| | | | + Implement Window-Size option if appropriate |3.3.3 | |x| | | | + Server initiate mode negotiations |3.3.4 | |x| | | | + User can enable/disable init negotiations |3.3.4 | |x| | | | + | | | | | | | +Go-Aheads | | | | | | | + Non-GA server negotiate SUPPRESS-GA option |3.2.2 |x| | | | | + User or Server accept SUPPRESS-GA option |3.2.2 |x| | | | | + User Telnet ignore GA's |3.2.2 | | |x| | | + | | | | | | | +Control Functions | | | | | | | + Support SE NOP DM IP AO AYT SB |3.2.3 |x| | | | | + Support EOR EC EL Break |3.2.3 | | |x| | | + Ignore unsupported control functions |3.2.3 |x| | | | | + User, Server discard urgent data up to DM |3.2.4 |x| | | | | + User Telnet send "Synch" after IP, AO, AYT |3.2.4 | |x| | | | + Server Telnet reply Synch to IP |3.2.4 | | |x| | | + Server Telnet reply Synch to AO |3.2.4 |x| | | | | + User Telnet can flush output when send IP |3.2.4 | |x| | | | + | | | | | | | +Encoding | | | | | | | + Send high-order bit in NVT mode |3.2.5 | | | |x| | + Send high-order bit as parity bit |3.2.5 | | | | |x| + Negot. BINARY if pass high-ord. bit to applic |3.2.5 | |x| | | | + Always double IAC data byte |3.2.6 |x| | | | | + + + +Internet Engineering Task Force [Page 27] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + Double IAC data byte in binary mode |3.2.7 |x| | | | | + Obey Telnet cmds in binary mode |3.2.7 |x| | | | | + End-of-line, CR NUL in binary mode |3.2.7 | | | | |x| + | | | | | | | +End-of-Line | | | | | | | + EOL at Server same as local end-of-line |3.3.1 |x| | | | | + ASCII Server accept CR LF or CR NUL for EOL |3.3.1 |x| | | | | + User Telnet able to send CR LF, CR NUL, or LF |3.3.1 |x| | | | | + ASCII user able to select CR LF/CR NUL |3.3.1 | |x| | | | + User Telnet default mode is CR LF |3.3.1 | |x| | | | + Non-interactive uses CR LF for EOL |3.3.1 |x| | | | | + | | | | | | | +User Telnet interface | | | | | | | + Input & output all 7-bit characters |3.4.1 | |x| | | | + Bypass local op sys interpretation |3.4.1 | |x| | | | + Escape character |3.4.1 |x| | | | | + User-settable escape character |3.4.1 | |x| | | | + Escape to enter 8-bit values |3.4.1 | | |x| | | + Can input IP, AO, AYT |3.4.2 |x| | | | | + Can input EC, EL, Break |3.4.2 | |x| | | | + Report TCP connection errors to user |3.4.3 | |x| | | | + Optional non-default contact port |3.4.4 | |x| | | | + Can spec: output flushed when IP sent |3.4.5 | |x| | | | + Can manually restore output mode |3.4.5 | |x| | | | + | | | | | | | + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 28] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + +4. FILE TRANSFER + + 4.1 FILE TRANSFER PROTOCOL -- FTP + + 4.1.1 INTRODUCTION + + The File Transfer Protocol FTP is the primary Internet standard + for file transfer. The current specification is contained in + RFC-959 [FTP:1]. + + FTP uses separate simultaneous TCP connections for control and + for data transfer. The FTP protocol includes many features, + some of which are not commonly implemented. However, for every + feature in FTP, there exists at least one implementation. The + minimum implementation defined in RFC-959 was too small, so a + somewhat larger minimum implementation is defined here. + + Internet users have been unnecessarily burdened for years by + deficient FTP implementations. Protocol implementors have + suffered from the erroneous opinion that implementing FTP ought + to be a small and trivial task. This is wrong, because FTP has + a user interface, because it has to deal (correctly) with the + whole variety of communication and operating system errors that + may occur, and because it has to handle the great diversity of + real file systems in the world. + + 4.1.2. PROTOCOL WALK-THROUGH + + 4.1.2.1 LOCAL Type: RFC-959 Section 3.1.1.4 + + An FTP program MUST support TYPE I ("IMAGE" or binary type) + as well as TYPE L 8 ("LOCAL" type with logical byte size 8). + A machine whose memory is organized into m-bit words, where + m is not a multiple of 8, MAY also support TYPE L m. + + DISCUSSION: + The command "TYPE L 8" is often required to transfer + binary data between a machine whose memory is organized + into (e.g.) 36-bit words and a machine with an 8-bit + byte organization. For an 8-bit byte machine, TYPE L 8 + is equivalent to IMAGE. + + "TYPE L m" is sometimes specified to the FTP programs + on two m-bit word machines to ensure the correct + transfer of a native-mode binary file from one machine + to the other. However, this command should have the + same effect on these machines as "TYPE I". + + + + +Internet Engineering Task Force [Page 29] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.2.2 Telnet Format Control: RFC-959 Section 3.1.1.5.2 + + A host that makes no distinction between TYPE N and TYPE T + SHOULD implement TYPE T to be identical to TYPE N. + + DISCUSSION: + This provision should ease interoperation with hosts + that do make this distinction. + + Many hosts represent text files internally as strings + of ASCII characters, using the embedded ASCII format + effector characters (LF, BS, FF, ...) to control the + format when a file is printed. For such hosts, there + is no distinction between "print" files and other + files. However, systems that use record structured + files typically need a special format for printable + files (e.g., ASA carriage control). For the latter + hosts, FTP allows a choice of TYPE N or TYPE T. + + 4.1.2.3 Page Structure: RFC-959 Section 3.1.2.3 and Appendix I + + Implementation of page structure is NOT RECOMMENDED in + general. However, if a host system does need to implement + FTP for "random access" or "holey" files, it MUST use the + defined page structure format rather than define a new + private FTP format. + + 4.1.2.4 Data Structure Transformations: RFC-959 Section 3.1.2 + + An FTP transformation between record-structure and file- + structure SHOULD be invertible, to the extent possible while + making the result useful on the target host. + + DISCUSSION: + RFC-959 required strict invertibility between record- + structure and file-structure, but in practice, + efficiency and convenience often preclude it. + Therefore, the requirement is being relaxed. There are + two different objectives for transferring a file: + processing it on the target host, or just storage. For + storage, strict invertibility is important. For + processing, the file created on the target host needs + to be in the format expected by application programs on + that host. + + As an example of the conflict, imagine a record- + oriented operating system that requires some data files + to have exactly 80 bytes in each record. While STORing + + + +Internet Engineering Task Force [Page 30] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + a file on such a host, an FTP Server must be able to + pad each line or record to 80 bytes; a later retrieval + of such a file cannot be strictly invertible. + + 4.1.2.5 Data Connection Management: RFC-959 Section 3.3 + + A User-FTP that uses STREAM mode SHOULD send a PORT command + to assign a non-default data port before each transfer + command is issued. + + DISCUSSION: + This is required because of the long delay after a TCP + connection is closed until its socket pair can be + reused, to allow multiple transfers during a single FTP + session. Sending a port command can avoided if a + transfer mode other than stream is used, by leaving the + data transfer connection open between transfers. + + 4.1.2.6 PASV Command: RFC-959 Section 4.1.2 + + A server-FTP MUST implement the PASV command. + + If multiple third-party transfers are to be executed during + the same session, a new PASV command MUST be issued before + each transfer command, to obtain a unique port pair. + + IMPLEMENTATION: + The format of the 227 reply to a PASV command is not + well standardized. In particular, an FTP client cannot + assume that the parentheses shown on page 40 of RFC-959 + will be present (and in fact, Figure 3 on page 43 omits + them). Therefore, a User-FTP program that interprets + the PASV reply must scan the reply for the first digit + of the host and port numbers. + + Note that the host number h1,h2,h3,h4 is the IP address + of the server host that is sending the reply, and that + p1,p2 is a non-default data transfer port that PASV has + assigned. + + 4.1.2.7 LIST and NLST Commands: RFC-959 Section 4.1.3 + + The data returned by an NLST command MUST contain only a + simple list of legal pathnames, such that the server can use + them directly as the arguments of subsequent data transfer + commands for the individual files. + + The data returned by a LIST or NLST command SHOULD use an + + + +Internet Engineering Task Force [Page 31] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + implied TYPE AN, unless the current type is EBCDIC, in which + case an implied TYPE EN SHOULD be used. + + DISCUSSION: + Many FTP clients support macro-commands that will get + or put files matching a wildcard specification, using + NLST to obtain a list of pathnames. The expansion of + "multiple-put" is local to the client, but "multiple- + get" requires cooperation by the server. + + The implied type for LIST and NLST is designed to + provide compatibility with existing User-FTPs, and in + particular with multiple-get commands. + + 4.1.2.8 SITE Command: RFC-959 Section 4.1.3 + + A Server-FTP SHOULD use the SITE command for non-standard + features, rather than invent new private commands or + unstandardized extensions to existing commands. + + 4.1.2.9 STOU Command: RFC-959 Section 4.1.3 + + The STOU command stores into a uniquely named file. When it + receives an STOU command, a Server-FTP MUST return the + actual file name in the "125 Transfer Starting" or the "150 + Opening Data Connection" message that precedes the transfer + (the 250 reply code mentioned in RFC-959 is incorrect). The + exact format of these messages is hereby defined to be as + follows: + + 125 FILE: pppp + 150 FILE: pppp + + where pppp represents the unique pathname of the file that + will be written. + + 4.1.2.10 Telnet End-of-line Code: RFC-959, Page 34 + + Implementors MUST NOT assume any correspondence between READ + boundaries on the control connection and the Telnet EOL + sequences (CR LF). + + DISCUSSION: + Thus, a server-FTP (or User-FTP) must continue reading + characters from the control connection until a complete + Telnet EOL sequence is encountered, before processing + the command (or response, respectively). Conversely, a + single READ from the control connection may include + + + +Internet Engineering Task Force [Page 32] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + more than one FTP command. + + 4.1.2.11 FTP Replies: RFC-959 Section 4.2, Page 35 + + A Server-FTP MUST send only correctly formatted replies on + the control connection. Note that RFC-959 (unlike earlier + versions of the FTP spec) contains no provision for a + "spontaneous" reply message. + + A Server-FTP SHOULD use the reply codes defined in RFC-959 + whenever they apply. However, a server-FTP MAY use a + different reply code when needed, as long as the general + rules of Section 4.2 are followed. When the implementor has + a choice between a 4xx and 5xx reply code, a Server-FTP + SHOULD send a 4xx (temporary failure) code when there is any + reasonable possibility that a failed FTP will succeed a few + hours later. + + A User-FTP SHOULD generally use only the highest-order digit + of a 3-digit reply code for making a procedural decision, to + prevent difficulties when a Server-FTP uses non-standard + reply codes. + + A User-FTP MUST be able to handle multi-line replies. If + the implementation imposes a limit on the number of lines + and if this limit is exceeded, the User-FTP MUST recover, + e.g., by ignoring the excess lines until the end of the + multi-line reply is reached. + + A User-FTP SHOULD NOT interpret a 421 reply code ("Service + not available, closing control connection") specially, but + SHOULD detect closing of the control connection by the + server. + + DISCUSSION: + Server implementations that fail to strictly follow the + reply rules often cause FTP user programs to hang. + Note that RFC-959 resolved ambiguities in the reply + rules found in earlier FTP specifications and must be + followed. + + It is important to choose FTP reply codes that properly + distinguish between temporary and permanent failures, + to allow the successful use of file transfer client + daemons. These programs depend on the reply codes to + decide whether or not to retry a failed transfer; using + a permanent failure code (5xx) for a temporary error + will cause these programs to give up unnecessarily. + + + +Internet Engineering Task Force [Page 33] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + When the meaning of a reply matches exactly the text + shown in RFC-959, uniformity will be enhanced by using + the RFC-959 text verbatim. However, a Server-FTP + implementor is encouraged to choose reply text that + conveys specific system-dependent information, when + appropriate. + + 4.1.2.12 Connections: RFC-959 Section 5.2 + + The words "and the port used" in the second paragraph of + this section of RFC-959 are erroneous (historical), and they + should be ignored. + + On a multihomed server host, the default data transfer port + (L-1) MUST be associated with the same local IP address as + the corresponding control connection to port L. + + A user-FTP MUST NOT send any Telnet controls other than + SYNCH and IP on an FTP control connection. In particular, it + MUST NOT attempt to negotiate Telnet options on the control + connection. However, a server-FTP MUST be capable of + accepting and refusing Telnet negotiations (i.e., sending + DONT/WONT). + + DISCUSSION: + Although the RFC says: "Server- and User- processes + should follow the conventions for the Telnet + protocol...[on the control connection]", it is not the + intent that Telnet option negotiation is to be + employed. + + 4.1.2.13 Minimum Implementation; RFC-959 Section 5.1 + + The following commands and options MUST be supported by + every server-FTP and user-FTP, except in cases where the + underlying file system or operating system does not allow or + support a particular command. + + Type: ASCII Non-print, IMAGE, LOCAL 8 + Mode: Stream + Structure: File, Record* + Commands: + USER, PASS, ACCT, + PORT, PASV, + TYPE, MODE, STRU, + RETR, STOR, APPE, + RNFR, RNTO, DELE, + CWD, CDUP, RMD, MKD, PWD, + + + +Internet Engineering Task Force [Page 34] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + LIST, NLST, + SYST, STAT, + HELP, NOOP, QUIT. + + *Record structure is REQUIRED only for hosts whose file + systems support record structure. + + DISCUSSION: + Vendors are encouraged to implement a larger subset of + the protocol. For example, there are important + robustness features in the protocol (e.g., Restart, + ABOR, block mode) that would be an aid to some Internet + users but are not widely implemented. + + A host that does not have record structures in its file + system may still accept files with STRU R, recording + the byte stream literally. + + 4.1.3 SPECIFIC ISSUES + + 4.1.3.1 Non-standard Command Verbs + + FTP allows "experimental" commands, whose names begin with + "X". If these commands are subsequently adopted as + standards, there may still be existing implementations using + the "X" form. At present, this is true for the directory + commands: + + RFC-959 "Experimental" + + MKD XMKD + RMD XRMD + PWD XPWD + CDUP XCUP + CWD XCWD + + All FTP implementations SHOULD recognize both forms of these + commands, by simply equating them with extra entries in the + command lookup table. + + IMPLEMENTATION: + A User-FTP can access a server that supports only the + "X" forms by implementing a mode switch, or + automatically using the following procedure: if the + RFC-959 form of one of the above commands is rejected + with a 500 or 502 response code, then try the + experimental form; any other response would be passed + to the user. + + + +Internet Engineering Task Force [Page 35] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.3.2 Idle Timeout + + A Server-FTP process SHOULD have an idle timeout, which will + terminate the process and close the control connection if + the server is inactive (i.e., no command or data transfer in + progress) for a long period of time. The idle timeout time + SHOULD be configurable, and the default should be at least 5 + minutes. + + A client FTP process ("User-PI" in RFC-959) will need + timeouts on responses only if it is invoked from a program. + + DISCUSSION: + Without a timeout, a Server-FTP process may be left + pending indefinitely if the corresponding client + crashes without closing the control connection. + + 4.1.3.3 Concurrency of Data and Control + + DISCUSSION: + The intent of the designers of FTP was that a user + should be able to send a STAT command at any time while + data transfer was in progress and that the server-FTP + would reply immediately with status -- e.g., the number + of bytes transferred so far. Similarly, an ABOR + command should be possible at any time during a data + transfer. + + Unfortunately, some small-machine operating systems + make such concurrent programming difficult, and some + other implementers seek minimal solutions, so some FTP + implementations do not allow concurrent use of the data + and control connections. Even such a minimal server + must be prepared to accept and defer a STAT or ABOR + command that arrives during data transfer. + + 4.1.3.4 FTP Restart Mechanism + + The description of the 110 reply on pp. 40-41 of RFC-959 is + incorrect; the correct description is as follows. A restart + reply message, sent over the control connection from the + receiving FTP to the User-FTP, has the format: + + 110 MARK ssss = rrrr + + Here: + + * ssss is a text string that appeared in a Restart Marker + + + +Internet Engineering Task Force [Page 36] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + in the data stream and encodes a position in the + sender's file system; + + * rrrr encodes the corresponding position in the + receiver's file system. + + The encoding, which is specific to a particular file system + and network implementation, is always generated and + interpreted by the same system, either sender or receiver. + + When an FTP that implements restart receives a Restart + Marker in the data stream, it SHOULD force the data to that + point to be written to stable storage before encoding the + corresponding position rrrr. An FTP sending Restart Markers + MUST NOT assume that 110 replies will be returned + synchronously with the data, i.e., it must not await a 110 + reply before sending more data. + + Two new reply codes are hereby defined for errors + encountered in restarting a transfer: + + 554 Requested action not taken: invalid REST parameter. + + A 554 reply may result from a FTP service command that + follows a REST command. The reply indicates that the + existing file at the Server-FTP cannot be repositioned + as specified in the REST. + + 555 Requested action not taken: type or stru mismatch. + + A 555 reply may result from an APPE command or from any + FTP service command following a REST command. The + reply indicates that there is some mismatch between the + current transfer parameters (type and stru) and the + attributes of the existing file. + + DISCUSSION: + Note that the FTP Restart mechanism requires that Block + or Compressed mode be used for data transfer, to allow + the Restart Markers to be included within the data + stream. The frequency of Restart Markers can be low. + + Restart Markers mark a place in the data stream, but + the receiver may be performing some transformation on + the data as it is stored into stable storage. In + general, the receiver's encoding must include any state + information necessary to restart this transformation at + any point of the FTP data stream. For example, in TYPE + + + +Internet Engineering Task Force [Page 37] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + A transfers, some receiver hosts transform CR LF + sequences into a single LF character on disk. If a + Restart Marker happens to fall between CR and LF, the + receiver must encode in rrrr that the transfer must be + restarted in a "CR has been seen and discarded" state. + + Note that the Restart Marker is required to be encoded + as a string of printable ASCII characters, regardless + of the type of the data. + + RFC-959 says that restart information is to be returned + "to the user". This should not be taken literally. In + general, the User-FTP should save the restart + information (ssss,rrrr) in stable storage, e.g., append + it to a restart control file. An empty restart control + file should be created when the transfer first starts + and deleted automatically when the transfer completes + successfully. It is suggested that this file have a + name derived in an easily-identifiable manner from the + name of the file being transferred and the remote host + name; this is analogous to the means used by many text + editors for naming "backup" files. + + There are three cases for FTP restart. + + (1) User-to-Server Transfer + + The User-FTP puts Restart Markers at + convenient places in the data stream. When the + Server-FTP receives a Marker, it writes all prior + data to disk, encodes its file system position and + transformation state as rrrr, and returns a "110 + MARK ssss = rrrr" reply over the control + connection. The User-FTP appends the pair + (ssss,rrrr) to its restart control file. + + To restart the transfer, the User-FTP fetches the + last (ssss,rrrr) pair from the restart control + file, repositions its local file system and + transformation state using ssss, and sends the + command "REST rrrr" to the Server-FTP. + + (2) Server-to-User Transfer + + The Server-FTP puts Restart Markers at + convenient places in the data stream. When the + User-FTP receives a Marker, it writes all prior + data to disk, encodes its file system position and + + + +Internet Engineering Task Force [Page 38] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + transformation state as rrrr, and appends the pair + (rrrr,ssss) to its restart control file. + + To restart the transfer, the User-FTP fetches the + last (rrrr,ssss) pair from the restart control + file, repositions its local file system and + transformation state using rrrr, and sends the + command "REST ssss" to the Server-FTP. + + (3) Server-to-Server ("Third-Party") Transfer + + The sending Server-FTP puts Restart Markers + at convenient places in the data stream. When it + receives a Marker, the receiving Server-FTP writes + all prior data to disk, encodes its file system + position and transformation state as rrrr, and + sends a "110 MARK ssss = rrrr" reply over the + control connection to the User. The User-FTP + appends the pair (ssss,rrrr) to its restart + control file. + + To restart the transfer, the User-FTP fetches the + last (ssss,rrrr) pair from the restart control + file, sends "REST ssss" to the sending Server-FTP, + and sends "REST rrrr" to the receiving Server-FTP. + + + 4.1.4 FTP/USER INTERFACE + + This section discusses the user interface for a User-FTP + program. + + 4.1.4.1 Pathname Specification + + Since FTP is intended for use in a heterogeneous + environment, User-FTP implementations MUST support remote + pathnames as arbitrary character strings, so that their form + and content are not limited by the conventions of the local + operating system. + + DISCUSSION: + In particular, remote pathnames can be of arbitrary + length, and all the printing ASCII characters as well + as space (0x20) must be allowed. RFC-959 allows a + pathname to contain any 7-bit ASCII character except CR + or LF. + + + + + +Internet Engineering Task Force [Page 39] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.4.2 "QUOTE" Command + + A User-FTP program MUST implement a "QUOTE" command that + will pass an arbitrary character string to the server and + display all resulting response messages to the user. + + To make the "QUOTE" command useful, a User-FTP SHOULD send + transfer control commands to the server as the user enters + them, rather than saving all the commands and sending them + to the server only when a data transfer is started. + + DISCUSSION: + The "QUOTE" command is essential to allow the user to + access servers that require system-specific commands + (e.g., SITE or ALLO), or to invoke new or optional + features that are not implemented by the User-FTP. For + example, "QUOTE" may be used to specify "TYPE A T" to + send a print file to hosts that require the + distinction, even if the User-FTP does not recognize + that TYPE. + + 4.1.4.3 Displaying Replies to User + + A User-FTP SHOULD display to the user the full text of all + error reply messages it receives. It SHOULD have a + "verbose" mode in which all commands it sends and the full + text and reply codes it receives are displayed, for + diagnosis of problems. + + 4.1.4.4 Maintaining Synchronization + + The state machine in a User-FTP SHOULD be forgiving of + missing and unexpected reply messages, in order to maintain + command synchronization with the server. + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 40] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.5 FTP REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-------------------------------------------|---------------|-|-|-|-|-|-- +Implement TYPE T if same as TYPE N |4.1.2.2 | |x| | | | +File/Record transform invertible if poss. |4.1.2.4 | |x| | | | +User-FTP send PORT cmd for stream mode |4.1.2.5 | |x| | | | +Server-FTP implement PASV |4.1.2.6 |x| | | | | + PASV is per-transfer |4.1.2.6 |x| | | | | +NLST reply usable in RETR cmds |4.1.2.7 |x| | | | | +Implied type for LIST and NLST |4.1.2.7 | |x| | | | +SITE cmd for non-standard features |4.1.2.8 | |x| | | | +STOU cmd return pathname as specified |4.1.2.9 |x| | | | | +Use TCP READ boundaries on control conn. |4.1.2.10 | | | | |x| + | | | | | | | +Server-FTP send only correct reply format |4.1.2.11 |x| | | | | +Server-FTP use defined reply code if poss. |4.1.2.11 | |x| | | | + New reply code following Section 4.2 |4.1.2.11 | | |x| | | +User-FTP use only high digit of reply |4.1.2.11 | |x| | | | +User-FTP handle multi-line reply lines |4.1.2.11 |x| | | | | +User-FTP handle 421 reply specially |4.1.2.11 | | | |x| | + | | | | | | | +Default data port same IP addr as ctl conn |4.1.2.12 |x| | | | | +User-FTP send Telnet cmds exc. SYNCH, IP |4.1.2.12 | | | | |x| +User-FTP negotiate Telnet options |4.1.2.12 | | | | |x| +Server-FTP handle Telnet options |4.1.2.12 |x| | | | | +Handle "Experimental" directory cmds |4.1.3.1 | |x| | | | +Idle timeout in server-FTP |4.1.3.2 | |x| | | | + Configurable idle timeout |4.1.3.2 | |x| | | | +Receiver checkpoint data at Restart Marker |4.1.3.4 | |x| | | | +Sender assume 110 replies are synchronous |4.1.3.4 | | | | |x| + | | | | | | | +Support TYPE: | | | | | | | + ASCII - Non-Print (AN) |4.1.2.13 |x| | | | | + ASCII - Telnet (AT) -- if same as AN |4.1.2.2 | |x| | | | + ASCII - Carriage Control (AC) |959 3.1.1.5.2 | | |x| | | + EBCDIC - (any form) |959 3.1.1.2 | | |x| | | + IMAGE |4.1.2.1 |x| | | | | + LOCAL 8 |4.1.2.1 |x| | | | | + + + +Internet Engineering Task Force [Page 41] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + LOCAL m |4.1.2.1 | | |x| | |2 + | | | | | | | +Support MODE: | | | | | | | + Stream |4.1.2.13 |x| | | | | + Block |959 3.4.2 | | |x| | | + | | | | | | | +Support STRUCTURE: | | | | | | | + File |4.1.2.13 |x| | | | | + Record |4.1.2.13 |x| | | | |3 + Page |4.1.2.3 | | | |x| | + | | | | | | | +Support commands: | | | | | | | + USER |4.1.2.13 |x| | | | | + PASS |4.1.2.13 |x| | | | | + ACCT |4.1.2.13 |x| | | | | + CWD |4.1.2.13 |x| | | | | + CDUP |4.1.2.13 |x| | | | | + SMNT |959 5.3.1 | | |x| | | + REIN |959 5.3.1 | | |x| | | + QUIT |4.1.2.13 |x| | | | | + | | | | | | | + PORT |4.1.2.13 |x| | | | | + PASV |4.1.2.6 |x| | | | | + TYPE |4.1.2.13 |x| | | | |1 + STRU |4.1.2.13 |x| | | | |1 + MODE |4.1.2.13 |x| | | | |1 + | | | | | | | + RETR |4.1.2.13 |x| | | | | + STOR |4.1.2.13 |x| | | | | + STOU |959 5.3.1 | | |x| | | + APPE |4.1.2.13 |x| | | | | + ALLO |959 5.3.1 | | |x| | | + REST |959 5.3.1 | | |x| | | + RNFR |4.1.2.13 |x| | | | | + RNTO |4.1.2.13 |x| | | | | + ABOR |959 5.3.1 | | |x| | | + DELE |4.1.2.13 |x| | | | | + RMD |4.1.2.13 |x| | | | | + MKD |4.1.2.13 |x| | | | | + PWD |4.1.2.13 |x| | | | | + LIST |4.1.2.13 |x| | | | | + NLST |4.1.2.13 |x| | | | | + SITE |4.1.2.8 | | |x| | | + STAT |4.1.2.13 |x| | | | | + SYST |4.1.2.13 |x| | | | | + HELP |4.1.2.13 |x| | | | | + NOOP |4.1.2.13 |x| | | | | + | | | | | | | + + + +Internet Engineering Task Force [Page 42] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + +User Interface: | | | | | | | + Arbitrary pathnames |4.1.4.1 |x| | | | | + Implement "QUOTE" command |4.1.4.2 |x| | | | | + Transfer control commands immediately |4.1.4.2 | |x| | | | + Display error messages to user |4.1.4.3 | |x| | | | + Verbose mode |4.1.4.3 | |x| | | | + Maintain synchronization with server |4.1.4.4 | |x| | | | + +Footnotes: + +(1) For the values shown earlier. + +(2) Here m is number of bits in a memory word. + +(3) Required for host with record-structured file system, optional + otherwise. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 43] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP + + 4.2.1 INTRODUCTION + + The Trivial File Transfer Protocol TFTP is defined in RFC-783 + [TFTP:1]. + + TFTP provides its own reliable delivery with UDP as its + transport protocol, using a simple stop-and-wait acknowledgment + system. Since TFTP has an effective window of only one 512 + octet segment, it can provide good performance only over paths + that have a small delay*bandwidth product. The TFTP file + interface is very simple, providing no access control or + security. + + TFTP's most important application is bootstrapping a host over + a local network, since it is simple and small enough to be + easily implemented in EPROM [BOOT:1, BOOT:2]. Vendors are + urged to support TFTP for booting. + + 4.2.2 PROTOCOL WALK-THROUGH + + The TFTP specification [TFTP:1] is written in an open style, + and does not fully specify many parts of the protocol. + + 4.2.2.1 Transfer Modes: RFC-783, Page 3 + + The transfer mode "mail" SHOULD NOT be supported. + + 4.2.2.2 UDP Header: RFC-783, Page 17 + + The Length field of a UDP header is incorrectly defined; it + includes the UDP header length (8). + + 4.2.3 SPECIFIC ISSUES + + 4.2.3.1 Sorcerer's Apprentice Syndrome + + There is a serious bug, known as the "Sorcerer's Apprentice + Syndrome," in the protocol specification. While it does not + cause incorrect operation of the transfer (the file will + always be transferred correctly if the transfer completes), + this bug may cause excessive retransmission, which may cause + the transfer to time out. + + Implementations MUST contain the fix for this problem: the + sender (i.e., the side originating the DATA packets) must + never resend the current DATA packet on receipt of a + + + +Internet Engineering Task Force [Page 44] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + duplicate ACK. + + DISCUSSION: + The bug is caused by the protocol rule that either + side, on receiving an old duplicate datagram, may + resend the current datagram. If a packet is delayed in + the network but later successfully delivered after + either side has timed out and retransmitted a packet, a + duplicate copy of the response may be generated. If + the other side responds to this duplicate with a + duplicate of its own, then every datagram will be sent + in duplicate for the remainder of the transfer (unless + a datagram is lost, breaking the repetition). Worse + yet, since the delay is often caused by congestion, + this duplicate transmission will usually causes more + congestion, leading to more delayed packets, etc. + + The following example may help to clarify this problem. + + TFTP A TFTP B + + (1) Receive ACK X-1 + Send DATA X + (2) Receive DATA X + Send ACK X + (ACK X is delayed in network, + and A times out): + (3) Retransmit DATA X + + (4) Receive DATA X again + Send ACK X again + (5) Receive (delayed) ACK X + Send DATA X+1 + (6) Receive DATA X+1 + Send ACK X+1 + (7) Receive ACK X again + Send DATA X+1 again + (8) Receive DATA X+1 again + Send ACK X+1 again + (9) Receive ACK X+1 + Send DATA X+2 + (10) Receive DATA X+2 + Send ACK X+3 + (11) Receive ACK X+1 again + Send DATA X+2 again + (12) Receive DATA X+2 again + Send ACK X+3 again + + + + +Internet Engineering Task Force [Page 45] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + Notice that once the delayed ACK arrives, the protocol + settles down to duplicate all further packets + (sequences 5-8 and 9-12). The problem is caused not by + either side timing out, but by both sides + retransmitting the current packet when they receive a + duplicate. + + The fix is to break the retransmission loop, as + indicated above. This is analogous to the behavior of + TCP. It is then possible to remove the retransmission + timer on the receiver, since the resent ACK will never + cause any action; this is a useful simplification where + TFTP is used in a bootstrap program. It is OK to allow + the timer to remain, and it may be helpful if the + retransmitted ACK replaces one that was genuinely lost + in the network. The sender still requires a retransmit + timer, of course. + + 4.2.3.2 Timeout Algorithms + + A TFTP implementation MUST use an adaptive timeout. + + IMPLEMENTATION: + TCP retransmission algorithms provide a useful base to + work from. At least an exponential backoff of + retransmission timeout is necessary. + + 4.2.3.3 Extensions + + A variety of non-standard extensions have been made to TFTP, + including additional transfer modes and a secure operation + mode (with passwords). None of these have been + standardized. + + 4.2.3.4 Access Control + + A server TFTP implementation SHOULD include some + configurable access control over what pathnames are allowed + in TFTP operations. + + 4.2.3.5 Broadcast Request + + A TFTP request directed to a broadcast address SHOULD be + silently ignored. + + DISCUSSION: + Due to the weak access control capability of TFTP, + directed broadcasts of TFTP requests to random networks + + + +Internet Engineering Task Force [Page 46] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + could create a significant security hole. + + 4.2.4 TFTP REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-------------------------------------------------|--------|-|-|-|-|-|-- +Fix Sorcerer's Apprentice Syndrome |4.2.3.1 |x| | | | | +Transfer modes: | | | | | | | + netascii |RFC-783 |x| | | | | + octet |RFC-783 |x| | | | | + mail |4.2.2.1 | | | |x| | + extensions |4.2.3.3 | | |x| | | +Use adaptive timeout |4.2.3.2 |x| | | | | +Configurable access control |4.2.3.4 | |x| | | | +Silently ignore broadcast request |4.2.3.5 | |x| | | | +-------------------------------------------------|--------|-|-|-|-|-|-- +-------------------------------------------------|--------|-|-|-|-|-|-- + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 47] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + +5. ELECTRONIC MAIL -- SMTP and RFC-822 + + 5.1 INTRODUCTION + + In the TCP/IP protocol suite, electronic mail in a format + specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail + Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1]. + + While SMTP has remained unchanged over the years, the Internet + community has made several changes in the way SMTP is used. In + particular, the conversion to the Domain Name System (DNS) has + caused changes in address formats and in mail routing. In this + section, we assume familiarity with the concepts and terminology + of the DNS, whose requirements are given in Section 6.1. + + RFC-822 specifies the Internet standard format for electronic mail + messages. RFC-822 supercedes an older standard, RFC-733, that may + still be in use in a few places, although it is obsolete. The two + formats are sometimes referred to simply by number ("822" and + "733"). + + RFC-822 is used in some non-Internet mail environments with + different mail transfer protocols than SMTP, and SMTP has also + been adapted for use in some non-Internet environments. Note that + this document presents the rules for the use of SMTP and RFC-822 + for the Internet environment only; other mail environments that + use these protocols may be expected to have their own rules. + + 5.2 PROTOCOL WALK-THROUGH + + This section covers both RFC-821 and RFC-822. + + The SMTP specification in RFC-821 is clear and contains numerous + examples, so implementors should not find it difficult to + understand. This section simply updates or annotates portions of + RFC-821 to conform with current usage. + + RFC-822 is a long and dense document, defining a rich syntax. + Unfortunately, incomplete or defective implementations of RFC-822 + are common. In fact, nearly all of the many formats of RFC-822 + are actually used, so an implementation generally needs to + recognize and correctly interpret all of the RFC-822 syntax. + + 5.2.1 The SMTP Model: RFC-821 Section 2 + + DISCUSSION: + Mail is sent by a series of request/response transactions + between a client, the "sender-SMTP," and a server, the + + + +Internet Engineering Task Force [Page 48] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + "receiver-SMTP". These transactions pass (1) the message + proper, which is composed of header and body, and (2) SMTP + source and destination addresses, referred to as the + "envelope". + + The SMTP programs are analogous to Message Transfer Agents + (MTAs) of X.400. There will be another level of protocol + software, closer to the end user, that is responsible for + composing and analyzing RFC-822 message headers; this + component is known as the "User Agent" in X.400, and we + use that term in this document. There is a clear logical + distinction between the User Agent and the SMTP + implementation, since they operate on different levels of + protocol. Note, however, that this distinction is may not + be exactly reflected the structure of typical + implementations of Internet mail. Often there is a + program known as the "mailer" that implements SMTP and + also some of the User Agent functions; the rest of the + User Agent functions are included in a user interface used + for entering and reading mail. + + The SMTP envelope is constructed at the originating site, + typically by the User Agent when the message is first + queued for the Sender-SMTP program. The envelope + addresses may be derived from information in the message + header, supplied by the user interface (e.g., to implement + a bcc: request), or derived from local configuration + information (e.g., expansion of a mailing list). The SMTP + envelope cannot in general be re-derived from the header + at a later stage in message delivery, so the envelope is + transmitted separately from the message itself using the + MAIL and RCPT commands of SMTP. + + The text of RFC-821 suggests that mail is to be delivered + to an individual user at a host. With the advent of the + domain system and of mail routing using mail-exchange (MX) + resource records, implementors should now think of + delivering mail to a user at a domain, which may or may + not be a particular host. This DOES NOT change the fact + that SMTP is a host-to-host mail exchange protocol. + + 5.2.2 Canonicalization: RFC-821 Section 3.1 + + The domain names that a Sender-SMTP sends in MAIL and RCPT + commands MUST have been "canonicalized," i.e., they must be + fully-qualified principal names or domain literals, not + nicknames or domain abbreviations. A canonicalized name either + identifies a host directly or is an MX name; it cannot be a + + + +Internet Engineering Task Force [Page 49] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + CNAME. + + 5.2.3 VRFY and EXPN Commands: RFC-821 Section 3.3 + + A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN + (this requirement overrides RFC-821). However, there MAY be + configuration information to disable VRFY and EXPN in a + particular installation; this might even allow EXPN to be + disabled for selected lists. + + A new reply code is defined for the VRFY command: + + 252 Cannot VRFY user (e.g., info is not local), but will + take message for this user and attempt delivery. + + DISCUSSION: + SMTP users and administrators make regular use of these + commands for diagnosing mail delivery problems. With the + increasing use of multi-level mailing list expansion + (sometimes more than two levels), EXPN has been + increasingly important for diagnosing inadvertent mail + loops. On the other hand, some feel that EXPN represents + a significant privacy, and perhaps even a security, + exposure. + + 5.2.4 SEND, SOML, and SAML Commands: RFC-821 Section 3.4 + + An SMTP MAY implement the commands to send a message to a + user's terminal: SEND, SOML, and SAML. + + DISCUSSION: + It has been suggested that the use of mail relaying + through an MX record is inconsistent with the intent of + SEND to deliver a message immediately and directly to a + user's terminal. However, an SMTP receiver that is unable + to write directly to the user terminal can return a "251 + User Not Local" reply to the RCPT following a SEND, to + inform the originator of possibly deferred delivery. + + 5.2.5 HELO Command: RFC-821 Section 3.5 + + The sender-SMTP MUST ensure that the parameter in a + HELO command is a valid principal host domain name for the + client host. As a result, the receiver-SMTP will not have to + perform MX resolution on this name in order to validate the + HELO parameter. + + The HELO receiver MAY verify that the HELO parameter really + + + +Internet Engineering Task Force [Page 50] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + corresponds to the IP address of the sender. However, the + receiver MUST NOT refuse to accept a message, even if the + sender's HELO command fails verification. + + DISCUSSION: + Verifying the HELO parameter requires a domain name lookup + and may therefore take considerable time. An alternative + tool for tracking bogus mail sources is suggested below + (see "DATA Command"). + + Note also that the HELO argument is still required to have + valid syntax, since it will appear in a Received: + line; otherwise, a 501 error is to be sent. + + IMPLEMENTATION: + When HELO parameter validation fails, a suggested + procedure is to insert a note about the unknown + authenticity of the sender into the message header (e.g., + in the "Received:" line). + + 5.2.6 Mail Relay: RFC-821 Section 3.6 + + We distinguish three types of mail (store-and-) forwarding: + + (1) A simple forwarder or "mail exchanger" forwards a message + using private knowledge about the recipient; see section + 3.2 of RFC-821. + + (2) An SMTP mail "relay" forwards a message within an SMTP + mail environment as the result of an explicit source route + (as defined in section 3.6 of RFC-821). The SMTP relay + function uses the "@...:" form of source route from RFC- + 822 (see Section 5.2.19 below). + + (3) A mail "gateway" passes a message between different + environments. The rules for mail gateways are discussed + below in Section 5.3.7. + + An Internet host that is forwarding a message but is not a + gateway to a different mail environment (i.e., it falls under + (1) or (2)) SHOULD NOT alter any existing header fields, + although the host will add an appropriate Received: line as + required in Section 5.2.8. + + A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an + explicit source route using the "@...:" address form. Thus, + the relay function defined in section 3.6 of RFC-821 should + not be used. + + + +Internet Engineering Task Force [Page 51] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + DISCUSSION: + The intent is to discourage all source routing and to + abolish explicit source routing for mail delivery within + the Internet environment. Source-routing is unnecessary; + the simple target address "user@domain" should always + suffice. This is the result of an explicit architectural + decision to use universal naming rather than source + routing for mail. Thus, SMTP provides end-to-end + connectivity, and the DNS provides globally-unique, + location-independent names. MX records handle the major + case where source routing might otherwise be needed. + + A receiver-SMTP MUST accept the explicit source route syntax in + the envelope, but it MAY implement the relay function as + defined in section 3.6 of RFC-821. If it does not implement + the relay function, it SHOULD attempt to deliver the message + directly to the host to the right of the right-most "@" sign. + + DISCUSSION: + For example, suppose a host that does not implement the + relay function receives a message with the SMTP command: + "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and + GAMMA represent domain names. Rather than immediately + refusing the message with a 550 error reply as suggested + on page 20 of RFC-821, the host should try to forward the + message to GAMMA directly, using: "RCPT TO:". + Since this host does not support relaying, it is not + required to update the reverse path. + + Some have suggested that source routing may be needed + occasionally for manually routing mail around failures; + however, the reality and importance of this need is + controversial. The use of explicit SMTP mail relaying for + this purpose is discouraged, and in fact it may not be + successful, as many host systems do not support it. Some + have used the "%-hack" (see Section 5.2.16) for this + purpose. + + 5.2.7 RCPT Command: RFC-821 Section 4.1.1 + + A host that supports a receiver-SMTP MUST support the reserved + mailbox "Postmaster". + + The receiver-SMTP MAY verify RCPT parameters as they arrive; + however, RCPT responses MUST NOT be delayed beyond a reasonable + time (see Section 5.3.2). + + Therefore, a "250 OK" response to a RCPT does not necessarily + + + +Internet Engineering Task Force [Page 52] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + imply that the delivery address(es) are valid. Errors found + after message acceptance will be reported by mailing a + notification message to an appropriate address (see Section + 5.3.3). + + DISCUSSION: + The set of conditions under which a RCPT parameter can be + validated immediately is an engineering design choice. + Reporting destination mailbox errors to the Sender-SMTP + before mail is transferred is generally desirable to save + time and network bandwidth, but this advantage is lost if + RCPT verification is lengthy. + + For example, the receiver can verify immediately any + simple local reference, such as a single locally- + registered mailbox. On the other hand, the "reasonable + time" limitation generally implies deferring verification + of a mailing list until after the message has been + transferred and accepted, since verifying a large mailing + list can take a very long time. An implementation might + or might not choose to defer validation of addresses that + are non-local and therefore require a DNS lookup. If a + DNS lookup is performed but a soft domain system error + (e.g., timeout) occurs, validity must be assumed. + + 5.2.8 DATA Command: RFC-821 Section 4.1.1 + + Every receiver-SMTP (not just one that "accepts a message for + relaying or for final delivery" [SMTP:1]) MUST insert a + "Received:" line at the beginning of a message. In this line, + called a "time stamp line" in RFC-821: + + * The FROM field SHOULD contain both (1) the name of the + source host as presented in the HELO command and (2) a + domain literal containing the IP address of the source, + determined from the TCP connection. + + * The ID field MAY contain an "@" as suggested in RFC-822, + but this is not required. + + * The FOR field MAY contain a list of entries when + multiple RCPT commands have been given. + + + An Internet mail program MUST NOT change a Received: line that + was previously added to the message header. + + + + + +Internet Engineering Task Force [Page 53] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + DISCUSSION: + Including both the source host and the IP source address + in the Received: line may provide enough information for + tracking illicit mail sources and eliminate a need to + explicitly verify the HELO parameter. + + Received: lines are primarily intended for humans tracing + mail routes, primarily of diagnosis of faults. See also + the discussion under 5.3.7. + + When the receiver-SMTP makes "final delivery" of a message, + then it MUST pass the MAIL FROM: address from the SMTP envelope + with the message, for use if an error notification message must + be sent later (see Section 5.3.3). There is an analogous + requirement when gatewaying from the Internet into a different + mail environment; see Section 5.3.7. + + DISCUSSION: + Note that the final reply to the DATA command depends only + upon the successful transfer and storage of the message. + Any problem with the destination address(es) must either + (1) have been reported in an SMTP error reply to the RCPT + command(s), or (2) be reported in a later error message + mailed to the originator. + + IMPLEMENTATION: + The MAIL FROM: information may be passed as a parameter or + in a Return-Path: line inserted at the beginning of the + message. + + 5.2.9 Command Syntax: RFC-821 Section 4.1.2 + + The syntax shown in RFC-821 for the MAIL FROM: command omits + the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page + 15). An empty reverse path MUST be supported. + + 5.2.10 SMTP Replies: RFC-821 Section 4.2 + + A receiver-SMTP SHOULD send only the reply codes listed in + section 4.2.2 of RFC-821 or in this document. A receiver-SMTP + SHOULD use the text shown in examples in RFC-821 whenever + appropriate. + + A sender-SMTP MUST determine its actions only by the reply + code, not by the text (except for 251 and 551 replies); any + text, including no text at all, must be acceptable. The space + (blank) following the reply code is considered part of the + text. Whenever possible, a sender-SMTP SHOULD test only the + + + +Internet Engineering Task Force [Page 54] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + first digit of the reply code, as specified in Appendix E of + RFC-821. + + DISCUSSION: + Interoperability problems have arisen with SMTP systems + using reply codes that are not listed explicitly in RFC- + 821 Section 4.3 but are legal according to the theory of + reply codes explained in Appendix E. + + 5.2.11 Transparency: RFC-821 Section 4.5.2 + + Implementors MUST be sure that their mail systems always add + and delete periods to ensure message transparency. + + 5.2.12 WKS Use in MX Processing: RFC-974, p. 5 + + RFC-974 [SMTP:3] recommended that the domain system be queried + for WKS ("Well-Known Service") records, to verify that each + proposed mail target does support SMTP. Later experience has + shown that WKS is not widely supported, so the WKS step in MX + processing SHOULD NOT be used. + + The following are notes on RFC-822, organized by section of that + document. + + 5.2.13 RFC-822 Message Specification: RFC-822 Section 4 + + The syntax shown for the Return-path line omits the possibility + of a null return path, which is used to prevent looping of + error notifications (see Section 5.3.3). The complete syntax + is: + + return = "Return-path" ":" route-addr + / "Return-path" ":" "<" ">" + + The set of optional header fields is hereby expanded to include + the Content-Type field defined in RFC-1049 [SMTP:7]. This + field "allows mail reading systems to automatically identify + the type of a structured message body and to process it for + display accordingly". [SMTP:7] A User Agent MAY support this + field. + + 5.2.14 RFC-822 Date and Time Specification: RFC-822 Section 5 + + The syntax for the date is hereby changed to: + + date = 1*2DIGIT month 2*4DIGIT + + + + +Internet Engineering Task Force [Page 55] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + All mail software SHOULD use 4-digit years in dates, to ease + the transition to the next century. + + There is a strong trend towards the use of numeric timezone + indicators, and implementations SHOULD use numeric timezones + instead of timezone names. However, all implementations MUST + accept either notation. If timezone names are used, they MUST + be exactly as defined in RFC-822. + + The military time zones are specified incorrectly in RFC-822: + they count the wrong way from UT (the signs are reversed). As + a result, military time zones in RFC-822 headers carry no + information. + + Finally, note that there is a typo in the definition of "zone" + in the syntax summary of appendix D; the correct definition + occurs in Section 3 of RFC-822. + + 5.2.15 RFC-822 Syntax Change: RFC-822 Section 6.1 + + The syntactic definition of "mailbox" in RFC-822 is hereby + changed to: + + mailbox = addr-spec ; simple address + / [phrase] route-addr ; name & addr-spec + + That is, the phrase preceding a route address is now OPTIONAL. + This change makes the following header field legal, for + example: + + From: + + 5.2.16 RFC-822 Local-part: RFC-822 Section 6.2 + + The basic mailbox address specification has the form: "local- + part@domain". Here "local-part", sometimes called the "left- + hand side" of the address, is domain-dependent. + + A host that is forwarding the message but is not the + destination host implied by the right-hand side "domain" MUST + NOT interpret or modify the "local-part" of the address. + + When mail is to be gatewayed from the Internet mail environment + into a foreign mail environment (see Section 5.3.7), routing + information for that foreign environment MAY be embedded within + the "local-part" of the address. The gateway will then + interpret this local part appropriately for the foreign mail + environment. + + + +Internet Engineering Task Force [Page 56] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + DISCUSSION: + Although source routes are discouraged within the Internet + (see Section 5.2.6), there are non-Internet mail + environments whose delivery mechanisms do depend upon + source routes. Source routes for extra-Internet + environments can generally be buried in the "local-part" + of the address (see Section 5.2.16) while mail traverses + the Internet. When the mail reaches the appropriate + Internet mail gateway, the gateway will interpret the + local-part and build the necessary address or route for + the target mail environment. + + For example, an Internet host might send mail to: + "a!b!c!user@gateway-domain". The complex local part + "a!b!c!user" would be uninterpreted within the Internet + domain, but could be parsed and understood by the + specified mail gateway. + + An embedded source route is sometimes encoded in the + "local-part" using "%" as a right-binding routing + operator. For example, in: + + user%domain%relay3%relay2@relay1 + + the "%" convention implies that the mail is to be routed + from "relay1" through "relay2", "relay3", and finally to + "user" at "domain". This is commonly known as the "%- + hack". It is suggested that "%" have lower precedence + than any other routing operator (e.g., "!") hidden in the + local-part; for example, "a!b%c" would be interpreted as + "(a!b)%c". + + Only the target host (in this case, "relay1") is permitted + to analyze the local-part "user%domain%relay3%relay2". + + 5.2.17 Domain Literals: RFC-822 Section 6.2.3 + + A mailer MUST be able to accept and parse an Internet domain + literal whose content ("dtext"; see RFC-822) is a dotted- + decimal host address. This satisfies the requirement of + Section 2.1 for the case of mail. + + An SMTP MUST accept and recognize a domain literal for any of + its own IP addresses. + + + + + + + +Internet Engineering Task Force [Page 57] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + 5.2.18 Common Address Formatting Errors: RFC-822 Section 6.1 + + Errors in formatting or parsing 822 addresses are unfortunately + common. This section mentions only the most common errors. A + User Agent MUST accept all valid RFC-822 address formats, and + MUST NOT generate illegal address syntax. + + o A common error is to leave out the semicolon after a group + identifier. + + o Some systems fail to fully-qualify domain names in + messages they generate. The right-hand side of an "@" + sign in a header address field MUST be a fully-qualified + domain name. + + For example, some systems fail to fully-qualify the From: + address; this prevents a "reply" command in the user + interface from automatically constructing a return + address. + + DISCUSSION: + Although RFC-822 allows the local use of abbreviated + domain names within a domain, the application of + RFC-822 in Internet mail does not allow this. The + intent is that an Internet host must not send an SMTP + message header containing an abbreviated domain name + in an address field. This allows the address fields + of the header to be passed without alteration across + the Internet, as required in Section 5.2.6. + + o Some systems mis-parse multiple-hop explicit source routes + such as: + + @relay1,@relay2,@relay3:user@domain. + + + o Some systems over-qualify domain names by adding a + trailing dot to some or all domain names in addresses or + message-ids. This violates RFC-822 syntax. + + + 5.2.19 Explicit Source Routes: RFC-822 Section 6.2.7 + + Internet host software SHOULD NOT create an RFC-822 header + containing an address with an explicit source route, but MUST + accept such headers for compatibility with earlier systems. + + DISCUSSION: + + + +Internet Engineering Task Force [Page 58] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + In an understatement, RFC-822 says "The use of explicit + source routing is discouraged". Many hosts implemented + RFC-822 source routes incorrectly, so the syntax cannot be + used unambiguously in practice. Many users feel the + syntax is ugly. Explicit source routes are not needed in + the mail envelope for delivery; see Section 5.2.6. For + all these reasons, explicit source routes using the RFC- + 822 notations are not to be used in Internet mail headers. + + As stated in Section 5.2.16, it is necessary to allow an + explicit source route to be buried in the local-part of an + address, e.g., using the "%-hack", in order to allow mail + to be gatewayed into another environment in which explicit + source routing is necessary. The vigilant will observe + that there is no way for a User Agent to detect and + prevent the use of such implicit source routing when the + destination is within the Internet. We can only + discourage source routing of any kind within the Internet, + as unnecessary and undesirable. + + 5.3 SPECIFIC ISSUES + + 5.3.1 SMTP Queueing Strategies + + The common structure of a host SMTP implementation includes + user mailboxes, one or more areas for queueing messages in + transit, and one or more daemon processes for sending and + receiving mail. The exact structure will vary depending on the + needs of the users on the host and the number and size of + mailing lists supported by the host. We describe several + optimizations that have proved helpful, particularly for + mailers supporting high traffic levels. + + Any queueing strategy MUST include: + + o Timeouts on all activities. See Section 5.3.2. + + o Never sending error messages in response to error + messages. + + + 5.3.1.1 Sending Strategy + + The general model of a sender-SMTP is one or more processes + that periodically attempt to transmit outgoing mail. In a + typical system, the program that composes a message has some + method for requesting immediate attention for a new piece of + outgoing mail, while mail that cannot be transmitted + + + +Internet Engineering Task Force [Page 59] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + immediately MUST be queued and periodically retried by the + sender. A mail queue entry will include not only the + message itself but also the envelope information. + + The sender MUST delay retrying a particular destination + after one attempt has failed. In general, the retry + interval SHOULD be at least 30 minutes; however, more + sophisticated and variable strategies will be beneficial + when the sender-SMTP can determine the reason for non- + delivery. + + Retries continue until the message is transmitted or the + sender gives up; the give-up time generally needs to be at + least 4-5 days. The parameters to the retry algorithm MUST + be configurable. + + A sender SHOULD keep a list of hosts it cannot reach and + corresponding timeouts, rather than just retrying queued + mail items. + + DISCUSSION: + Experience suggests that failures are typically + transient (the target system has crashed), favoring a + policy of two connection attempts in the first hour the + message is in the queue, and then backing off to once + every two or three hours. + + The sender-SMTP can shorten the queueing delay by + cooperation with the receiver-SMTP. In particular, if + mail is received from a particular address, it is good + evidence that any mail queued for that host can now be + sent. + + The strategy may be further modified as a result of + multiple addresses per host (see Section 5.3.4), to + optimize delivery time vs. resource usage. + + A sender-SMTP may have a large queue of messages for + each unavailable destination host, and if it retried + all these messages in every retry cycle, there would be + excessive Internet overhead and the daemon would be + blocked for a long period. Note that an SMTP can + generally determine that a delivery attempt has failed + only after a timeout of a minute or more; a one minute + timeout per connection will result in a very large + delay if it is repeated for dozens or even hundreds of + queued messages. + + + + +Internet Engineering Task Force [Page 60] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + When the same message is to be delivered to several users on + the same host, only one copy of the message SHOULD be + transmitted. That is, the sender-SMTP should use the + command sequence: RCPT, RCPT,... RCPT, DATA instead of the + sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA. + Implementation of this efficiency feature is strongly urged. + + Similarly, the sender-SMTP MAY support multiple concurrent + outgoing mail transactions to achieve timely delivery. + However, some limit SHOULD be imposed to protect the host + from devoting all its resources to mail. + + The use of the different addresses of a multihomed host is + discussed below. + + 5.3.1.2 Receiving strategy + + The receiver-SMTP SHOULD attempt to keep a pending listen on + the SMTP port at all times. This will require the support + of multiple incoming TCP connections for SMTP. Some limit + MAY be imposed. + + IMPLEMENTATION: + When the receiver-SMTP receives mail from a particular + host address, it could notify the sender-SMTP to retry + any mail pending for that host address. + + 5.3.2 Timeouts in SMTP + + There are two approaches to timeouts in the sender-SMTP: (a) + limit the time for each SMTP command separately, or (b) limit + the time for the entire SMTP dialogue for a single mail + message. A sender-SMTP SHOULD use option (a), per-command + timeouts. Timeouts SHOULD be easily reconfigurable, preferably + without recompiling the SMTP code. + + DISCUSSION: + Timeouts are an essential feature of an SMTP + implementation. If the timeouts are too long (or worse, + there are no timeouts), Internet communication failures or + software bugs in receiver-SMTP programs can tie up SMTP + processes indefinitely. If the timeouts are too short, + resources will be wasted with attempts that time out part + way through message delivery. + + If option (b) is used, the timeout has to be very large, + e.g., an hour, to allow time to expand very large mailing + lists. The timeout may also need to increase linearly + + + +Internet Engineering Task Force [Page 61] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + with the size of the message, to account for the time to + transmit a very large message. A large fixed timeout + leads to two problems: a failure can still tie up the + sender for a very long time, and very large messages may + still spuriously time out (which is a wasteful failure!). + + Using the recommended option (a), a timer is set for each + SMTP command and for each buffer of the data transfer. + The latter means that the overall timeout is inherently + proportional to the size of the message. + + Based on extensive experience with busy mail-relay hosts, the + minimum per-command timeout values SHOULD be as follows: + + o Initial 220 Message: 5 minutes + + A Sender-SMTP process needs to distinguish between a + failed TCP connection and a delay in receiving the initial + 220 greeting message. Many receiver-SMTPs will accept a + TCP connection but delay delivery of the 220 message until + their system load will permit more mail to be processed. + + o MAIL Command: 5 minutes + + + o RCPT Command: 5 minutes + + A longer timeout would be required if processing of + mailing lists and aliases were not deferred until after + the message was accepted. + + o DATA Initiation: 2 minutes + + This is while awaiting the "354 Start Input" reply to a + DATA command. + + o Data Block: 3 minutes + + This is while awaiting the completion of each TCP SEND + call transmitting a chunk of data. + + o DATA Termination: 10 minutes. + + This is while awaiting the "250 OK" reply. When the + receiver gets the final period terminating the message + data, it typically performs processing to deliver the + message to a user mailbox. A spurious timeout at this + point would be very wasteful, since the message has been + + + +Internet Engineering Task Force [Page 62] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + successfully sent. + + A receiver-SMTP SHOULD have a timeout of at least 5 minutes + while it is awaiting the next command from the sender. + + 5.3.3 Reliable Mail Receipt + + When the receiver-SMTP accepts a piece of mail (by sending a + "250 OK" message in response to DATA), it is accepting + responsibility for delivering or relaying the message. It must + take this responsibility seriously, i.e., it MUST NOT lose the + message for frivolous reasons, e.g., because the host later + crashes or because of a predictable resource shortage. + + If there is a delivery failure after acceptance of a message, + the receiver-SMTP MUST formulate and mail a notification + message. This notification MUST be sent using a null ("<>") + reverse path in the envelope; see Section 3.6 of RFC-821. The + recipient of this notification SHOULD be the address from the + envelope return path (or the Return-Path: line). However, if + this address is null ("<>"), the receiver-SMTP MUST NOT send a + notification. If the address is an explicit source route, it + SHOULD be stripped down to its final hop. + + DISCUSSION: + For example, suppose that an error notification must be + sent for a message that arrived with: + "MAIL FROM:<@a,@b:user@d>". The notification message + should be sent to: "RCPT TO:". + + Some delivery failures after the message is accepted by + SMTP will be unavoidable. For example, it may be + impossible for the receiver-SMTP to validate all the + delivery addresses in RCPT command(s) due to a "soft" + domain system error or because the target is a mailing + list (see earlier discussion of RCPT). + + To avoid receiving duplicate messages as the result of + timeouts, a receiver-SMTP MUST seek to minimize the time + required to respond to the final "." that ends a message + transfer. See RFC-1047 [SMTP:4] for a discussion of this + problem. + + 5.3.4 Reliable Mail Transmission + + To transmit a message, a sender-SMTP determines the IP address + of the target host from the destination address in the + envelope. Specifically, it maps the string to the right of the + + + +Internet Engineering Task Force [Page 63] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + "@" sign into an IP address. This mapping or the transfer + itself may fail with a soft error, in which case the sender- + SMTP will requeue the outgoing mail for a later retry, as + required in Section 5.3.1.1. + + When it succeeds, the mapping can result in a list of + alternative delivery addresses rather than a single address, + because of (a) multiple MX records, (b) multihoming, or both. + To provide reliable mail transmission, the sender-SMTP MUST be + able to try (and retry) each of the addresses in this list in + order, until a delivery attempt succeeds. However, there MAY + also be a configurable limit on the number of alternate + addresses that can be tried. In any case, a host SHOULD try at + least two addresses. + + The following information is to be used to rank the host + addresses: + + (1) Multiple MX Records -- these contain a preference + indication that should be used in sorting. If there are + multiple destinations with the same preference and there + is no clear reason to favor one (e.g., by address + preference), then the sender-SMTP SHOULD pick one at + random to spread the load across multiple mail exchanges + for a specific organization; note that this is a + refinement of the procedure in [DNS:3]. + + (2) Multihomed host -- The destination host (perhaps taken + from the preferred MX record) may be multihomed, in which + case the domain name resolver will return a list of + alternative IP addresses. It is the responsibility of the + domain name resolver interface (see Section 6.1.3.4 below) + to have ordered this list by decreasing preference, and + SMTP MUST try them in the order presented. + + DISCUSSION: + Although the capability to try multiple alternative + addresses is required, there may be circumstances where + specific installations want to limit or disable the use of + alternative addresses. The question of whether a sender + should attempt retries using the different addresses of a + multihomed host has been controversial. The main argument + for using the multiple addresses is that it maximizes the + probability of timely delivery, and indeed sometimes the + probability of any delivery; the counter argument is that + it may result in unnecessary resource use. + + Note that resource use is also strongly determined by the + + + +Internet Engineering Task Force [Page 64] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + sending strategy discussed in Section 5.3.1. + + 5.3.5 Domain Name Support + + SMTP implementations MUST use the mechanism defined in Section + 6.1 for mapping between domain names and IP addresses. This + means that every Internet SMTP MUST include support for the + Internet DNS. + + In particular, a sender-SMTP MUST support the MX record scheme + [SMTP:3]. See also Section 7.4 of [DNS:2] for information on + domain name support for SMTP. + + 5.3.6 Mailing Lists and Aliases + + An SMTP-capable host SHOULD support both the alias and the list + form of address expansion for multiple delivery. When a + message is delivered or forwarded to each address of an + expanded list form, the return address in the envelope + ("MAIL FROM:") MUST be changed to be the address of a person + who administers the list, but the message header MUST be left + unchanged; in particular, the "From" field of the message is + unaffected. + + DISCUSSION: + An important mail facility is a mechanism for multi- + destination delivery of a single message, by transforming + or "expanding" a pseudo-mailbox address into a list of + destination mailbox addresses. When a message is sent to + such a pseudo-mailbox (sometimes called an "exploder"), + copies are forwarded or redistributed to each mailbox in + the expanded list. We classify such a pseudo-mailbox as + an "alias" or a "list", depending upon the expansion + rules: + + (a) Alias + + To expand an alias, the recipient mailer simply + replaces the pseudo-mailbox address in the envelope + with each of the expanded addresses in turn; the rest + of the envelope and the message body are left + unchanged. The message is then delivered or + forwarded to each expanded address. + + (b) List + + A mailing list may be said to operate by + "redistribution" rather than by "forwarding". To + + + +Internet Engineering Task Force [Page 65] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + expand a list, the recipient mailer replaces the + pseudo-mailbox address in the envelope with each of + the expanded addresses in turn. The return address in + the envelope is changed so that all error messages + generated by the final deliveries will be returned to + a list administrator, not to the message originator, + who generally has no control over the contents of the + list and will typically find error messages annoying. + + + 5.3.7 Mail Gatewaying + + Gatewaying mail between different mail environments, i.e., + different mail formats and protocols, is complex and does not + easily yield to standardization. See for example [SMTP:5a], + [SMTP:5b]. However, some general requirements may be given for + a gateway between the Internet and another mail environment. + + (A) Header fields MAY be rewritten when necessary as messages + are gatewayed across mail environment boundaries. + + DISCUSSION: + This may involve interpreting the local-part of the + destination address, as suggested in Section 5.2.16. + + The other mail systems gatewayed to the Internet + generally use a subset of RFC-822 headers, but some + of them do not have an equivalent to the SMTP + envelope. Therefore, when a message leaves the + Internet environment, it may be necessary to fold the + SMTP envelope information into the message header. A + possible solution would be to create new header + fields to carry the envelope information (e.g., "X- + SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would + require changes in mail programs in the foreign + environment. + + (B) When forwarding a message into or out of the Internet + environment, a gateway MUST prepend a Received: line, but + it MUST NOT alter in any way a Received: line that is + already in the header. + + DISCUSSION: + This requirement is a subset of the general + "Received:" line requirement of Section 5.2.8; it is + restated here for emphasis. + + Received: fields of messages originating from other + + + +Internet Engineering Task Force [Page 66] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + environments may not conform exactly to RFC822. + However, the most important use of Received: lines is + for debugging mail faults, and this debugging can be + severely hampered by well-meaning gateways that try + to "fix" a Received: line. + + The gateway is strongly encouraged to indicate the + environment and protocol in the "via" clauses of + Received field(s) that it supplies. + + (C) From the Internet side, the gateway SHOULD accept all + valid address formats in SMTP commands and in RFC-822 + headers, and all valid RFC-822 messages. Although a + gateway must accept an RFC-822 explicit source route + ("@...:" format) in either the RFC-822 header or in the + envelope, it MAY or may not act on the source route; see + Sections 5.2.6 and 5.2.19. + + DISCUSSION: + It is often tempting to restrict the range of + addresses accepted at the mail gateway to simplify + the translation into addresses for the remote + environment. This practice is based on the + assumption that mail users have control over the + addresses their mailers send to the mail gateway. In + practice, however, users have little control over the + addresses that are finally sent; their mailers are + free to change addresses into any legal RFC-822 + format. + + (D) The gateway MUST ensure that all header fields of a + message that it forwards into the Internet meet the + requirements for Internet mail. In particular, all + addresses in "From:", "To:", "Cc:", etc., fields must be + transformed (if necessary) to satisfy RFC-822 syntax, and + they must be effective and useful for sending replies. + + + (E) The translation algorithm used to convert mail from the + Internet protocols to another environment's protocol + SHOULD try to ensure that error messages from the foreign + mail environment are delivered to the return path from the + SMTP envelope, not to the sender listed in the "From:" + field of the RFC-822 message. + + DISCUSSION: + Internet mail lists usually place the address of the + mail list maintainer in the envelope but leave the + + + +Internet Engineering Task Force [Page 67] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + original message header intact (with the "From:" + field containing the original sender). This yields + the behavior the average recipient expects: a reply + to the header gets sent to the original sender, not + to a mail list maintainer; however, errors get sent + to the maintainer (who can fix the problem) and not + the sender (who probably cannot). + + (F) Similarly, when forwarding a message from another + environment into the Internet, the gateway SHOULD set the + envelope return path in accordance with an error message + return address, if any, supplied by the foreign + environment. + + + 5.3.8 Maximum Message Size + + Mailer software MUST be able to send and receive messages of at + least 64K bytes in length (including header), and a much larger + maximum size is highly desirable. + + DISCUSSION: + Although SMTP does not define the maximum size of a + message, many systems impose implementation limits. + + The current de facto minimum limit in the Internet is 64K + bytes. However, electronic mail is used for a variety of + purposes that create much larger messages. For example, + mail is often used instead of FTP for transmitting ASCII + files, and in particular to transmit entire documents. As + a result, messages can be 1 megabyte or even larger. We + note that the present document together with its lower- + layer companion contains 0.5 megabytes. + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 68] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + 5.4 SMTP REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|----------|-|-|-|-|-|-- + | | | | | | | +RECEIVER-SMTP: | | | | | | | + Implement VRFY |5.2.3 |x| | | | | + Implement EXPN |5.2.3 | |x| | | | + EXPN, VRFY configurable |5.2.3 | | |x| | | + Implement SEND, SOML, SAML |5.2.4 | | |x| | | + Verify HELO parameter |5.2.5 | | |x| | | + Refuse message with bad HELO |5.2.5 | | | | |x| + Accept explicit src-route syntax in env. |5.2.6 |x| | | | | + Support "postmaster" |5.2.7 |x| | | | | + Process RCPT when received (except lists) |5.2.7 | | |x| | | + Long delay of RCPT responses |5.2.7 | | | | |x| + | | | | | | | + Add Received: line |5.2.8 |x| | | | | + Received: line include domain literal |5.2.8 | |x| | | | + Change previous Received: line |5.2.8 | | | | |x| + Pass Return-Path info (final deliv/gwy) |5.2.8 |x| | | | | + Support empty reverse path |5.2.9 |x| | | | | + Send only official reply codes |5.2.10 | |x| | | | + Send text from RFC-821 when appropriate |5.2.10 | |x| | | | + Delete "." for transparency |5.2.11 |x| | | | | + Accept and recognize self domain literal(s) |5.2.17 |x| | | | | + | | | | | | | + Error message about error message |5.3.1 | | | | |x| + Keep pending listen on SMTP port |5.3.1.2 | |x| | | | + Provide limit on recv concurrency |5.3.1.2 | | |x| | | + Wait at least 5 mins for next sender cmd |5.3.2 | |x| | | | + Avoidable delivery failure after "250 OK" |5.3.3 | | | | |x| + Send error notification msg after accept |5.3.3 |x| | | | | + Send using null return path |5.3.3 |x| | | | | + Send to envelope return path |5.3.3 | |x| | | | + Send to null address |5.3.3 | | | | |x| + Strip off explicit src route |5.3.3 | |x| | | | + Minimize acceptance delay (RFC-1047) |5.3.3 |x| | | | | +-----------------------------------------------|----------|-|-|-|-|-|-- + + + +Internet Engineering Task Force [Page 69] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + | | | | | | | +SENDER-SMTP: | | | | | | | + Canonicalized domain names in MAIL, RCPT |5.2.2 |x| | | | | + Implement SEND, SOML, SAML |5.2.4 | | |x| | | + Send valid principal host name in HELO |5.2.5 |x| | | | | + Send explicit source route in RCPT TO: |5.2.6 | | | |x| | + Use only reply code to determine action |5.2.10 |x| | | | | + Use only high digit of reply code when poss. |5.2.10 | |x| | | | + Add "." for transparency |5.2.11 |x| | | | | + | | | | | | | + Retry messages after soft failure |5.3.1.1 |x| | | | | + Delay before retry |5.3.1.1 |x| | | | | + Configurable retry parameters |5.3.1.1 |x| | | | | + Retry once per each queued dest host |5.3.1.1 | |x| | | | + Multiple RCPT's for same DATA |5.3.1.1 | |x| | | | + Support multiple concurrent transactions |5.3.1.1 | | |x| | | + Provide limit on concurrency |5.3.1.1 | |x| | | | + | | | | | | | + Timeouts on all activities |5.3.1 |x| | | | | + Per-command timeouts |5.3.2 | |x| | | | + Timeouts easily reconfigurable |5.3.2 | |x| | | | + Recommended times |5.3.2 | |x| | | | + Try alternate addr's in order |5.3.4 |x| | | | | + Configurable limit on alternate tries |5.3.4 | | |x| | | + Try at least two alternates |5.3.4 | |x| | | | + Load-split across equal MX alternates |5.3.4 | |x| | | | + Use the Domain Name System |5.3.5 |x| | | | | + Support MX records |5.3.5 |x| | | | | + Use WKS records in MX processing |5.2.12 | | | |x| | +-----------------------------------------------|----------|-|-|-|-|-|-- + | | | | | | | +MAIL FORWARDING: | | | | | | | + Alter existing header field(s) |5.2.6 | | | |x| | + Implement relay function: 821/section 3.6 |5.2.6 | | |x| | | + If not, deliver to RHS domain |5.2.6 | |x| | | | + Interpret 'local-part' of addr |5.2.16 | | | | |x| + | | | | | | | +MAILING LISTS AND ALIASES | | | | | | | + Support both |5.3.6 | |x| | | | + Report mail list error to local admin. |5.3.6 |x| | | | | + | | | | | | | +MAIL GATEWAYS: | | | | | | | + Embed foreign mail route in local-part |5.2.16 | | |x| | | + Rewrite header fields when necessary |5.3.7 | | |x| | | + Prepend Received: line |5.3.7 |x| | | | | + Change existing Received: line |5.3.7 | | | | |x| + Accept full RFC-822 on Internet side |5.3.7 | |x| | | | + Act on RFC-822 explicit source route |5.3.7 | | |x| | | + + + +Internet Engineering Task Force [Page 70] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + Send only valid RFC-822 on Internet side |5.3.7 |x| | | | | + Deliver error msgs to envelope addr |5.3.7 | |x| | | | + Set env return path from err return addr |5.3.7 | |x| | | | + | | | | | | | +USER AGENT -- RFC-822 | | | | | | | + Allow user to enter address |5.2.6 | | | |x| | + Support RFC-1049 Content Type field |5.2.13 | | |x| | | + Use 4-digit years |5.2.14 | |x| | | | + Generate numeric timezones |5.2.14 | |x| | | | + Accept all timezones |5.2.14 |x| | | | | + Use non-num timezones from RFC-822 |5.2.14 |x| | | | | + Omit phrase before route-addr |5.2.15 | | |x| | | + Accept and parse dot.dec. domain literals |5.2.17 |x| | | | | + Accept all RFC-822 address formats |5.2.18 |x| | | | | + Generate invalid RFC-822 address format |5.2.18 | | | | |x| + Fully-qualified domain names in header |5.2.18 |x| | | | | + Create explicit src route in header |5.2.19 | | | |x| | + Accept explicit src route in header |5.2.19 |x| | | | | + | | | | | | | +Send/recv at least 64KB messages |5.3.8 |x| | | | | + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 71] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + +6. SUPPORT SERVICES + + 6.1 DOMAIN NAME TRANSLATION + + 6.1.1 INTRODUCTION + + Every host MUST implement a resolver for the Domain Name System + (DNS), and it MUST implement a mechanism using this DNS + resolver to convert host names to IP addresses and vice-versa + [DNS:1, DNS:2]. + + In addition to the DNS, a host MAY also implement a host name + translation mechanism that searches a local Internet host + table. See Section 6.1.3.8 for more information on this + option. + + DISCUSSION: + Internet host name translation was originally performed by + searching local copies of a table of all hosts. This + table became too large to update and distribute in a + timely manner and too large to fit into many hosts, so the + DNS was invented. + + The DNS creates a distributed database used primarily for + the translation between host names and host addresses. + Implementation of DNS software is required. The DNS + consists of two logically distinct parts: name servers and + resolvers (although implementations often combine these + two logical parts in the interest of efficiency) [DNS:2]. + + Domain name servers store authoritative data about certain + sections of the database and answer queries about the + data. Domain resolvers query domain name servers for data + on behalf of user processes. Every host therefore needs a + DNS resolver; some host machines will also need to run + domain name servers. Since no name server has complete + information, in general it is necessary to obtain + information from more than one name server to resolve a + query. + + 6.1.2 PROTOCOL WALK-THROUGH + + An implementor must study references [DNS:1] and [DNS:2] + carefully. They provide a thorough description of the theory, + protocol, and implementation of the domain name system, and + reflect several years of experience. + + + + + +Internet Engineering Task Force [Page 72] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.2.1 Resource Records with Zero TTL: RFC-1035 Section 3.2.1 + + All DNS name servers and resolvers MUST properly handle RRs + with a zero TTL: return the RR to the client but do not + cache it. + + DISCUSSION: + Zero TTL values are interpreted to mean that the RR can + only be used for the transaction in progress, and + should not be cached; they are useful for extremely + volatile data. + + 6.1.2.2 QCLASS Values: RFC-1035 Section 3.2.5 + + A query with "QCLASS=*" SHOULD NOT be used unless the + requestor is seeking data from more than one class. In + particular, if the requestor is only interested in Internet + data types, QCLASS=IN MUST be used. + + 6.1.2.3 Unused Fields: RFC-1035 Section 4.1.1 + + Unused fields in a query or response message MUST be zero. + + 6.1.2.4 Compression: RFC-1035 Section 4.1.4 + + Name servers MUST use compression in responses. + + DISCUSSION: + Compression is essential to avoid overflowing UDP + datagrams; see Section 6.1.3.2. + + 6.1.2.5 Misusing Configuration Info: RFC-1035 Section 6.1.2 + + Recursive name servers and full-service resolvers generally + have some configuration information containing hints about + the location of root or local name servers. An + implementation MUST NOT include any of these hints in a + response. + + DISCUSSION: + Many implementors have found it convenient to store + these hints as if they were cached data, but some + neglected to ensure that this "cached data" was not + included in responses. This has caused serious + problems in the Internet when the hints were obsolete + or incorrect. + + + + + +Internet Engineering Task Force [Page 73] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.3 SPECIFIC ISSUES + + 6.1.3.1 Resolver Implementation + + A name resolver SHOULD be able to multiplex concurrent + requests if the host supports concurrent processes. + + In implementing a DNS resolver, one of two different models + MAY optionally be chosen: a full-service resolver, or a stub + resolver. + + + (A) Full-Service Resolver + + A full-service resolver is a complete implementation of + the resolver service, and is capable of dealing with + communication failures, failure of individual name + servers, location of the proper name server for a given + name, etc. It must satisfy the following requirements: + + o The resolver MUST implement a local caching + function to avoid repeated remote access for + identical requests, and MUST time out information + in the cache. + + o The resolver SHOULD be configurable with start-up + information pointing to multiple root name servers + and multiple name servers for the local domain. + This insures that the resolver will be able to + access the whole name space in normal cases, and + will be able to access local domain information + should the local network become disconnected from + the rest of the Internet. + + + (B) Stub Resolver + + A "stub resolver" relies on the services of a recursive + name server on the connected network or a "nearby" + network. This scheme allows the host to pass on the + burden of the resolver function to a name server on + another host. This model is often essential for less + capable hosts, such as PCs, and is also recommended + when the host is one of several workstations on a local + network, because it allows all of the workstations to + share the cache of the recursive name server and hence + reduce the number of domain requests exported by the + local network. + + + +Internet Engineering Task Force [Page 74] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + At a minimum, the stub resolver MUST be capable of + directing its requests to redundant recursive name + servers. Note that recursive name servers are allowed + to restrict the sources of requests that they will + honor, so the host administrator must verify that the + service will be provided. Stub resolvers MAY implement + caching if they choose, but if so, MUST timeout cached + information. + + + 6.1.3.2 Transport Protocols + + DNS resolvers and recursive servers MUST support UDP, and + SHOULD support TCP, for sending (non-zone-transfer) queries. + Specifically, a DNS resolver or server that is sending a + non-zone-transfer query MUST send a UDP query first. If the + Answer section of the response is truncated and if the + requester supports TCP, it SHOULD try the query again using + TCP. + + DNS servers MUST be able to service UDP queries and SHOULD + be able to service TCP queries. A name server MAY limit the + resources it devotes to TCP queries, but it SHOULD NOT + refuse to service a TCP query just because it would have + succeeded with UDP. + + Truncated responses MUST NOT be saved (cached) and later + used in such a way that the fact that they are truncated is + lost. + + DISCUSSION: + UDP is preferred over TCP for queries because UDP + queries have much lower overhead, both in packet count + and in connection state. The use of UDP is essential + for heavily-loaded servers, especially the root + servers. UDP also offers additional robustness, since + a resolver can attempt several UDP queries to different + servers for the cost of a single TCP query. + + It is possible for a DNS response to be truncated, + although this is a very rare occurrence in the present + Internet DNS. Practically speaking, truncation cannot + be predicted, since it is data-dependent. The + dependencies include the number of RRs in the answer, + the size of each RR, and the savings in space realized + by the name compression algorithm. As a rule of thumb, + truncation in NS and MX lists should not occur for + answers containing 15 or fewer RRs. + + + +Internet Engineering Task Force [Page 75] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + Whether it is possible to use a truncated answer + depends on the application. A mailer must not use a + truncated MX response, since this could lead to mail + loops. + + Responsible practices can make UDP suffice in the vast + majority of cases. Name servers must use compression + in responses. Resolvers must differentiate truncation + of the Additional section of a response (which only + loses extra information) from truncation of the Answer + section (which for MX records renders the response + unusable by mailers). Database administrators should + list only a reasonable number of primary names in lists + of name servers, MX alternatives, etc. + + However, it is also clear that some new DNS record + types defined in the future will contain information + exceeding the 512 byte limit that applies to UDP, and + hence will require TCP. Thus, resolvers and name + servers should implement TCP services as a backup to + UDP today, with the knowledge that they will require + the TCP service in the future. + + By private agreement, name servers and resolvers MAY arrange + to use TCP for all traffic between themselves. TCP MUST be + used for zone transfers. + + A DNS server MUST have sufficient internal concurrency that + it can continue to process UDP queries while awaiting a + response or performing a zone transfer on an open TCP + connection [DNS:2]. + + A server MAY support a UDP query that is delivered using an + IP broadcast or multicast address. However, the Recursion + Desired bit MUST NOT be set in a query that is multicast, + and MUST be ignored by name servers receiving queries via a + broadcast or multicast address. A host that sends broadcast + or multicast DNS queries SHOULD send them only as occasional + probes, caching the IP address(es) it obtains from the + response(s) so it can normally send unicast queries. + + DISCUSSION: + Broadcast or (especially) IP multicast can provide a + way to locate nearby name servers without knowing their + IP addresses in advance. However, general broadcasting + of recursive queries can result in excessive and + unnecessary load on both network and servers. + + + + +Internet Engineering Task Force [Page 76] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.3.3 Efficient Resource Usage + + The following requirements on servers and resolvers are very + important to the health of the Internet as a whole, + particularly when DNS services are invoked repeatedly by + higher level automatic servers, such as mailers. + + (1) The resolver MUST implement retransmission controls to + insure that it does not waste communication bandwidth, + and MUST impose finite bounds on the resources consumed + to respond to a single request. See [DNS:2] pages 43- + 44 for specific recommendations. + + (2) After a query has been retransmitted several times + without a response, an implementation MUST give up and + return a soft error to the application. + + (3) All DNS name servers and resolvers SHOULD cache + temporary failures, with a timeout period of the order + of minutes. + + DISCUSSION: + This will prevent applications that immediately + retry soft failures (in violation of Section 2.2 + of this document) from generating excessive DNS + traffic. + + (4) All DNS name servers and resolvers SHOULD cache + negative responses that indicate the specified name, or + data of the specified type, does not exist, as + described in [DNS:2]. + + (5) When a DNS server or resolver retries a UDP query, the + retry interval SHOULD be constrained by an exponential + backoff algorithm, and SHOULD also have upper and lower + bounds. + + IMPLEMENTATION: + A measured RTT and variance (if available) should + be used to calculate an initial retransmission + interval. If this information is not available, a + default of no less than 5 seconds should be used. + Implementations may limit the retransmission + interval, but this limit must exceed twice the + Internet maximum segment lifetime plus service + delay at the name server. + + (6) When a resolver or server receives a Source Quench for + + + +Internet Engineering Task Force [Page 77] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + a query it has issued, it SHOULD take steps to reduce + the rate of querying that server in the near future. A + server MAY ignore a Source Quench that it receives as + the result of sending a response datagram. + + IMPLEMENTATION: + One recommended action to reduce the rate is to + send the next query attempt to an alternate + server, if there is one available. Another is to + backoff the retry interval for the same server. + + + 6.1.3.4 Multihomed Hosts + + When the host name-to-address function encounters a host + with multiple addresses, it SHOULD rank or sort the + addresses using knowledge of the immediately connected + network number(s) and any other applicable performance or + history information. + + DISCUSSION: + The different addresses of a multihomed host generally + imply different Internet paths, and some paths may be + preferable to others in performance, reliability, or + administrative restrictions. There is no general way + for the domain system to determine the best path. A + recommended approach is to base this decision on local + configuration information set by the system + administrator. + + IMPLEMENTATION: + The following scheme has been used successfully: + + (a) Incorporate into the host configuration data a + Network-Preference List, that is simply a list of + networks in preferred order. This list may be + empty if there is no preference. + + (b) When a host name is mapped into a list of IP + addresses, these addresses should be sorted by + network number, into the same order as the + corresponding networks in the Network-Preference + List. IP addresses whose networks do not appear + in the Network-Preference List should be placed at + the end of the list. + + + + + + +Internet Engineering Task Force [Page 78] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.3.5 Extensibility + + DNS software MUST support all well-known, class-independent + formats [DNS:2], and SHOULD be written to minimize the + trauma associated with the introduction of new well-known + types and local experimentation with non-standard types. + + DISCUSSION: + The data types and classes used by the DNS are + extensible, and thus new types will be added and old + types deleted or redefined. Introduction of new data + types ought to be dependent only upon the rules for + compression of domain names inside DNS messages, and + the translation between printable (i.e., master file) + and internal formats for Resource Records (RRs). + + Compression relies on knowledge of the format of data + inside a particular RR. Hence compression must only be + used for the contents of well-known, class-independent + RRs, and must never be used for class-specific RRs or + RR types that are not well-known. The owner name of an + RR is always eligible for compression. + + A name server may acquire, via zone transfer, RRs that + the server doesn't know how to convert to printable + format. A resolver can receive similar information as + the result of queries. For proper operation, this data + must be preserved, and hence the implication is that + DNS software cannot use textual formats for internal + storage. + + The DNS defines domain name syntax very generally -- a + string of labels each containing up to 63 8-bit octets, + separated by dots, and with a maximum total of 255 + octets. Particular applications of the DNS are + permitted to further constrain the syntax of the domain + names they use, although the DNS deployment has led to + some applications allowing more general names. In + particular, Section 2.1 of this document liberalizes + slightly the syntax of a legal Internet host name that + was defined in RFC-952 [DNS:4]. + + 6.1.3.6 Status of RR Types + + Name servers MUST be able to load all RR types except MD and + MF from configuration files. The MD and MF types are + obsolete and MUST NOT be implemented; in particular, name + servers MUST NOT load these types from configuration files. + + + +Internet Engineering Task Force [Page 79] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + DISCUSSION: + The RR types MB, MG, MR, NULL, MINFO and RP are + considered experimental, and applications that use the + DNS cannot expect these RR types to be supported by + most domains. Furthermore these types are subject to + redefinition. + + The TXT and WKS RR types have not been widely used by + Internet sites; as a result, an application cannot rely + on the the existence of a TXT or WKS RR in most + domains. + + 6.1.3.7 Robustness + + DNS software may need to operate in environments where the + root servers or other servers are unavailable due to network + connectivity or other problems. In this situation, DNS name + servers and resolvers MUST continue to provide service for + the reachable part of the name space, while giving temporary + failures for the rest. + + DISCUSSION: + Although the DNS is meant to be used primarily in the + connected Internet, it should be possible to use the + system in networks which are unconnected to the + Internet. Hence implementations must not depend on + access to root servers before providing service for + local names. + + 6.1.3.8 Local Host Table + + DISCUSSION: + A host may use a local host table as a backup or + supplement to the DNS. This raises the question of + which takes precedence, the DNS or the host table; the + most flexible approach would make this a configuration + option. + + Typically, the contents of such a supplementary host + table will be determined locally by the site. However, + a publically-available table of Internet hosts is + maintained by the DDN Network Information Center (DDN + NIC), with a format documented in [DNS:4]. This table + can be retrieved from the DDN NIC using a protocol + described in [DNS:5]. It must be noted that this table + contains only a small fraction of all Internet hosts. + Hosts using this protocol to retrieve the DDN NIC host + table should use the VERSION command to check if the + + + +Internet Engineering Task Force [Page 80] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + table has changed before requesting the entire table + with the ALL command. The VERSION identifier should be + treated as an arbitrary string and tested only for + equality; no numerical sequence may be assumed. + + The DDN NIC host table includes administrative + information that is not needed for host operation and + is therefore not currently included in the DNS + database; examples include network and gateway entries. + However, much of this additional information will be + added to the DNS in the future. Conversely, the DNS + provides essential services (in particular, MX records) + that are not available from the DDN NIC host table. + + 6.1.4 DNS USER INTERFACE + + 6.1.4.1 DNS Administration + + This document is concerned with design and implementation + issues in host software, not with administrative or + operational issues. However, administrative issues are of + particular importance in the DNS, since errors in particular + segments of this large distributed database can cause poor + or erroneous performance for many sites. These issues are + discussed in [DNS:6] and [DNS:7]. + + 6.1.4.2 DNS User Interface + + Hosts MUST provide an interface to the DNS for all + application programs running on the host. This interface + will typically direct requests to a system process to + perform the resolver function [DNS:1, 6.1:2]. + + At a minimum, the basic interface MUST support a request for + all information of a specific type and class associated with + a specific name, and it MUST return either all of the + requested information, a hard error code, or a soft error + indication. When there is no error, the basic interface + returns the complete response information without + modification, deletion, or ordering, so that the basic + interface will not need to be changed to accommodate new + data types. + + DISCUSSION: + The soft error indication is an essential part of the + interface, since it may not always be possible to + access particular information from the DNS; see Section + 6.1.3.3. + + + +Internet Engineering Task Force [Page 81] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + A host MAY provide other DNS interfaces tailored to + particular functions, transforming the raw domain data into + formats more suited to these functions. In particular, a + host MUST provide a DNS interface to facilitate translation + between host addresses and host names. + + 6.1.4.3 Interface Abbreviation Facilities + + User interfaces MAY provide a method for users to enter + abbreviations for commonly-used names. Although the + definition of such methods is outside of the scope of the + DNS specification, certain rules are necessary to insure + that these methods allow access to the entire DNS name space + and to prevent excessive use of Internet resources. + + If an abbreviation method is provided, then: + + (a) There MUST be some convention for denoting that a name + is already complete, so that the abbreviation method(s) + are suppressed. A trailing dot is the usual method. + + (b) Abbreviation expansion MUST be done exactly once, and + MUST be done in the context in which the name was + entered. + + + DISCUSSION: + For example, if an abbreviation is used in a mail + program for a destination, the abbreviation should be + expanded into a full domain name and stored in the + queued message with an indication that it is already + complete. Otherwise, the abbreviation might be + expanded with a mail system search list, not the + user's, or a name could grow due to repeated + canonicalizations attempts interacting with wildcards. + + The two most common abbreviation methods are: + + (1) Interface-level aliases + + Interface-level aliases are conceptually implemented as + a list of alias/domain name pairs. The list can be + per-user or per-host, and separate lists can be + associated with different functions, e.g. one list for + host name-to-address translation, and a different list + for mail domains. When the user enters a name, the + interface attempts to match the name to the alias + component of a list entry, and if a matching entry can + + + +Internet Engineering Task Force [Page 82] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + be found, the name is replaced by the domain name found + in the pair. + + Note that interface-level aliases and CNAMEs are + completely separate mechanisms; interface-level aliases + are a local matter while CNAMEs are an Internet-wide + aliasing mechanism which is a required part of any DNS + implementation. + + (2) Search Lists + + A search list is conceptually implemented as an ordered + list of domain names. When the user enters a name, the + domain names in the search list are used as suffixes to + the user-supplied name, one by one, until a domain name + with the desired associated data is found, or the + search list is exhausted. Search lists often contain + the name of the local host's parent domain or other + ancestor domains. Search lists are often per-user or + per-process. + + It SHOULD be possible for an administrator to disable a + DNS search-list facility. Administrative denial may be + warranted in some cases, to prevent abuse of the DNS. + + There is danger that a search-list mechanism will + generate excessive queries to the root servers while + testing whether user input is a complete domain name, + lacking a final period to mark it as complete. A + search-list mechanism MUST have one of, and SHOULD have + both of, the following two provisions to prevent this: + + (a) The local resolver/name server can implement + caching of negative responses (see Section + 6.1.3.3). + + (b) The search list expander can require two or more + interior dots in a generated domain name before it + tries using the name in a query to non-local + domain servers, such as the root. + + DISCUSSION: + The intent of this requirement is to avoid + excessive delay for the user as the search list is + tested, and more importantly to prevent excessive + traffic to the root and other high-level servers. + For example, if the user supplied a name "X" and + the search list contained the root as a component, + + + +Internet Engineering Task Force [Page 83] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + a query would have to consult a root server before + the next search list alternative could be tried. + The resulting load seen by the root servers and + gateways near the root would be multiplied by the + number of hosts in the Internet. + + The negative caching alternative limits the effect + to the first time a name is used. The interior + dot rule is simpler to implement but can prevent + easy use of some top-level names. + + + 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|-----------|-|-|-|-|-|-- +GENERAL ISSUES | | | | | | | + | | | | | | | +Implement DNS name-to-address conversion |6.1.1 |x| | | | | +Implement DNS address-to-name conversion |6.1.1 |x| | | | | +Support conversions using host table |6.1.1 | | |x| | | +Properly handle RR with zero TTL |6.1.2.1 |x| | | | | +Use QCLASS=* unnecessarily |6.1.2.2 | |x| | | | + Use QCLASS=IN for Internet class |6.1.2.2 |x| | | | | +Unused fields zero |6.1.2.3 |x| | | | | +Use compression in responses |6.1.2.4 |x| | | | | + | | | | | | | +Include config info in responses |6.1.2.5 | | | | |x| +Support all well-known, class-indep. types |6.1.3.5 |x| | | | | +Easily expand type list |6.1.3.5 | |x| | | | +Load all RR types (except MD and MF) |6.1.3.6 |x| | | | | +Load MD or MF type |6.1.3.6 | | | | |x| +Operate when root servers, etc. unavailable |6.1.3.7 |x| | | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +RESOLVER ISSUES: | | | | | | | + | | | | | | | +Resolver support multiple concurrent requests |6.1.3.1 | |x| | | | +Full-service resolver: |6.1.3.1 | | |x| | | + Local caching |6.1.3.1 |x| | | | | + + + +Internet Engineering Task Force [Page 84] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + Information in local cache times out |6.1.3.1 |x| | | | | + Configurable with starting info |6.1.3.1 | |x| | | | +Stub resolver: |6.1.3.1 | | |x| | | + Use redundant recursive name servers |6.1.3.1 |x| | | | | + Local caching |6.1.3.1 | | |x| | | + Information in local cache times out |6.1.3.1 |x| | | | | +Support for remote multi-homed hosts: | | | | | | | + Sort multiple addresses by preference list |6.1.3.4 | |x| | | | + | | | | | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +TRANSPORT PROTOCOLS: | | | | | | | + | | | | | | | +Support UDP queries |6.1.3.2 |x| | | | | +Support TCP queries |6.1.3.2 | |x| | | | + Send query using UDP first |6.1.3.2 |x| | | | |1 + Try TCP if UDP answers are truncated |6.1.3.2 | |x| | | | +Name server limit TCP query resources |6.1.3.2 | | |x| | | + Punish unnecessary TCP query |6.1.3.2 | | | |x| | +Use truncated data as if it were not |6.1.3.2 | | | | |x| +Private agreement to use only TCP |6.1.3.2 | | |x| | | +Use TCP for zone transfers |6.1.3.2 |x| | | | | +TCP usage not block UDP queries |6.1.3.2 |x| | | | | +Support broadcast or multicast queries |6.1.3.2 | | |x| | | + RD bit set in query |6.1.3.2 | | | | |x| + RD bit ignored by server is b'cast/m'cast |6.1.3.2 |x| | | | | + Send only as occasional probe for addr's |6.1.3.2 | |x| | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +RESOURCE USAGE: | | | | | | | + | | | | | | | +Transmission controls, per [DNS:2] |6.1.3.3 |x| | | | | + Finite bounds per request |6.1.3.3 |x| | | | | +Failure after retries => soft error |6.1.3.3 |x| | | | | +Cache temporary failures |6.1.3.3 | |x| | | | +Cache negative responses |6.1.3.3 | |x| | | | +Retries use exponential backoff |6.1.3.3 | |x| | | | + Upper, lower bounds |6.1.3.3 | |x| | | | +Client handle Source Quench |6.1.3.3 | |x| | | | +Server ignore Source Quench |6.1.3.3 | | |x| | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +USER INTERFACE: | | | | | | | + | | | | | | | +All programs have access to DNS interface |6.1.4.2 |x| | | | | +Able to request all info for given name |6.1.4.2 |x| | | | | +Returns complete info or error |6.1.4.2 |x| | | | | +Special interfaces |6.1.4.2 | | |x| | | + Name<->Address translation |6.1.4.2 |x| | | | | + | | | | | | | +Abbreviation Facilities: |6.1.4.3 | | |x| | | + + + +Internet Engineering Task Force [Page 85] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + Convention for complete names |6.1.4.3 |x| | | | | + Conversion exactly once |6.1.4.3 |x| | | | | + Conversion in proper context |6.1.4.3 |x| | | | | + Search list: |6.1.4.3 | | |x| | | + Administrator can disable |6.1.4.3 | |x| | | | + Prevention of excessive root queries |6.1.4.3 |x| | | | | + Both methods |6.1.4.3 | |x| | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +-----------------------------------------------|-----------|-|-|-|-|-|-- + +1. Unless there is private agreement between particular resolver and + particular server. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 86] + + + + +RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 + + + 6.2 HOST INITIALIZATION + + 6.2.1 INTRODUCTION + + This section discusses the initialization of host software + across a connected network, or more generally across an + Internet path. This is necessary for a diskless host, and may + optionally be used for a host with disk drives. For a diskless + host, the initialization process is called "network booting" + and is controlled by a bootstrap program located in a boot ROM. + + To initialize a diskless host across the network, there are two + distinct phases: + + (1) Configure the IP layer. + + Diskless machines often have no permanent storage in which + to store network configuration information, so that + sufficient configuration information must be obtained + dynamically to support the loading phase that follows. + This information must include at least the IP addresses of + the host and of the boot server. To support booting + across a gateway, the address mask and a list of default + gateways are also required. + + (2) Load the host system code. + + During the loading phase, an appropriate file transfer + protocol is used to copy the system code across the + network from the boot server. + + A host with a disk may perform the first step, dynamic + configuration. This is important for microcomputers, whose + floppy disks allow network configuration information to be + mistakenly duplicated on more than one host. Also, + installation of new hosts is much simpler if they automatically + obtain their configuration information from a central server, + saving administrator time and decreasing the probability of + mistakes. + + 6.2.2 REQUIREMENTS + + 6.2.2.1 Dynamic Configuration + + A number of protocol provisions have been made for dynamic + configuration. + + o ICMP Information Request/Reply messages + + + +Internet Engineering Task Force [Page 87] + + + + +RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 + + + This obsolete message pair was designed to allow a host + to find the number of the network it is on. + Unfortunately, it was useful only if the host already + knew the host number part of its IP address, + information that hosts requiring dynamic configuration + seldom had. + + o Reverse Address Resolution Protocol (RARP) [BOOT:4] + + RARP is a link-layer protocol for a broadcast medium + that allows a host to find its IP address given its + link layer address. Unfortunately, RARP does not work + across IP gateways and therefore requires a RARP server + on every network. In addition, RARP does not provide + any other configuration information. + + o ICMP Address Mask Request/Reply messages + + These ICMP messages allow a host to learn the address + mask for a particular network interface. + + o BOOTP Protocol [BOOT:2] + + This protocol allows a host to determine the IP + addresses of the local host and the boot server, the + name of an appropriate boot file, and optionally the + address mask and list of default gateways. To locate a + BOOTP server, the host broadcasts a BOOTP request using + UDP. Ad hoc gateway extensions have been used to + transmit the BOOTP broadcast through gateways, and in + the future the IP Multicasting facility will provide a + standard mechanism for this purpose. + + + The suggested approach to dynamic configuration is to use + the BOOTP protocol with the extensions defined in "BOOTP + Vendor Information Extensions" RFC-1084 [BOOT:3]. RFC-1084 + defines some important general (not vendor-specific) + extensions. In particular, these extensions allow the + address mask to be supplied in BOOTP; we RECOMMEND that the + address mask be supplied in this manner. + + DISCUSSION: + Historically, subnetting was defined long after IP, and + so a separate mechanism (ICMP Address Mask messages) + was designed to supply the address mask to a host. + However, the IP address mask and the corresponding IP + address conceptually form a pair, and for operational + + + +Internet Engineering Task Force [Page 88] + + + + +RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 + + + simplicity they ought to be defined at the same time + and by the same mechanism, whether a configuration file + or a dynamic mechanism like BOOTP. + + Note that BOOTP is not sufficiently general to specify + the configurations of all interfaces of a multihomed + host. A multihomed host must either use BOOTP + separately for each interface, or configure one + interface using BOOTP to perform the loading, and + perform the complete initialization from a file later. + + Application layer configuration information is expected + to be obtained from files after loading of the system + code. + + 6.2.2.2 Loading Phase + + A suggested approach for the loading phase is to use TFTP + [BOOT:1] between the IP addresses established by BOOTP. + + TFTP to a broadcast address SHOULD NOT be used, for reasons + explained in Section 4.2.3.4. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 89] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + 6.3 REMOTE MANAGEMENT + + 6.3.1 INTRODUCTION + + The Internet community has recently put considerable effort + into the development of network management protocols. The + result has been a two-pronged approach [MGT:1, MGT:6]: the + Simple Network Management Protocol (SNMP) [MGT:4] and the + Common Management Information Protocol over TCP (CMOT) [MGT:5]. + + In order to be managed using SNMP or CMOT, a host will need to + implement an appropriate management agent. An Internet host + SHOULD include an agent for either SNMP or CMOT. + + Both SNMP and CMOT operate on a Management Information Base + (MIB) that defines a collection of management values. By + reading and setting these values, a remote application may + query and change the state of the managed system. + + A standard MIB [MGT:3] has been defined for use by both + management protocols, using data types defined by the Structure + of Management Information (SMI) defined in [MGT:2]. Additional + MIB variables can be introduced under the "enterprises" and + "experimental" subtrees of the MIB naming space [MGT:2]. + + Every protocol module in the host SHOULD implement the relevant + MIB variables. A host SHOULD implement the MIB variables as + defined in the most recent standard MIB, and MAY implement + other MIB variables when appropriate and useful. + + 6.3.2 PROTOCOL WALK-THROUGH + + The MIB is intended to cover both hosts and gateways, although + there may be detailed differences in MIB application to the two + cases. This section contains the appropriate interpretation of + the MIB for hosts. It is likely that later versions of the MIB + will include more entries for host management. + + A managed host must implement the following groups of MIB + object definitions: System, Interfaces, Address Translation, + IP, ICMP, TCP, and UDP. + + The following specific interpretations apply to hosts: + + o ipInHdrErrors + + Note that the error "time-to-live exceeded" can occur in a + host only when it is forwarding a source-routed datagram. + + + +Internet Engineering Task Force [Page 90] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + o ipOutNoRoutes + + This object counts datagrams discarded because no route + can be found. This may happen in a host if all the + default gateways in the host's configuration are down. + + o ipFragOKs, ipFragFails, ipFragCreates + + A host that does not implement intentional fragmentation + (see "Fragmentation" section of [INTRO:1]) MUST return the + value zero for these three objects. + + o icmpOutRedirects + + For a host, this object MUST always be zero, since hosts + do not send Redirects. + + o icmpOutAddrMaskReps + + For a host, this object MUST always be zero, unless the + host is an authoritative source of address mask + information. + + o ipAddrTable + + For a host, the "IP Address Table" object is effectively a + table of logical interfaces. + + o ipRoutingTable + + For a host, the "IP Routing Table" object is effectively a + combination of the host's Routing Cache and the static + route table described in "Routing Outbound Datagrams" + section of [INTRO:1]. + + Within each ipRouteEntry, ipRouteMetric1...4 normally will + have no meaning for a host and SHOULD always be -1, while + ipRouteType will normally have the value "remote". + + If destinations on the connected network do not appear in + the Route Cache (see "Routing Outbound Datagrams section + of [INTRO:1]), there will be no entries with ipRouteType + of "direct". + + + DISCUSSION: + The current MIB does not include Type-of-Service in an + ipRouteEntry, but a future revision is expected to make + + + +Internet Engineering Task Force [Page 91] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + this addition. + + We also expect the MIB to be expanded to allow the remote + management of applications (e.g., the ability to partially + reconfigure mail systems). Network service applications + such as mail systems should therefore be written with the + "hooks" for remote management. + + 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|-----------|-|-|-|-|-|-- +Support SNMP or CMOT agent |6.3.1 | |x| | | | +Implement specified objects in standard MIB |6.3.1 | |x| | | | + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 92] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + +7. REFERENCES + + This section lists the primary references with which every + implementer must be thoroughly familiar. It also lists some + secondary references that are suggested additional reading. + + INTRODUCTORY REFERENCES: + + + [INTRO:1] "Requirements for Internet Hosts -- Communication Layers," + IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122, + October 1989. + + [INTRO:2] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006, + (three volumes), SRI International, December 1985. + + [INTRO:3] "Official Internet Protocols," J. Reynolds and J. Postel, + RFC-1011, May 1987. + + This document is republished periodically with new RFC numbers; + the latest version must be used. + + [INTRO:4] "Protocol Document Order Information," O. Jacobsen and J. + Postel, RFC-980, March 1986. + + [INTRO:5] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, + May 1987. + + This document is republished periodically with new RFC numbers; + the latest version must be used. + + + TELNET REFERENCES: + + + [TELNET:1] "Telnet Protocol Specification," J. Postel and J. + Reynolds, RFC-854, May 1983. + + [TELNET:2] "Telnet Option Specification," J. Postel and J. Reynolds, + RFC-855, May 1983. + + [TELNET:3] "Telnet Binary Transmission," J. Postel and J. Reynolds, + RFC-856, May 1983. + + [TELNET:4] "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857, + May 1983. + + [TELNET:5] "Telnet Suppress Go Ahead Option," J. Postel and J. + + + +Internet Engineering Task Force [Page 93] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + Reynolds, RFC-858, May 1983. + + [TELNET:6] "Telnet Status Option," J. Postel and J. Reynolds, RFC- + 859, May 1983. + + [TELNET:7] "Telnet Timing Mark Option," J. Postel and J. Reynolds, + RFC-860, May 1983. + + [TELNET:8] "Telnet Extended Options List," J. Postel and J. + Reynolds, RFC-861, May 1983. + + [TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855, + December 1983. + + [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091, + February 1989. + + This document supercedes RFC-930. + + [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073, + October 1988. + + [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August + 1989. + + [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079, + December 1988. + + [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC- + 1080, November 1988. + + + SECONDARY TELNET REFERENCES: + + + [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of + Defense, May 1984. + + This document is intended to describe the same protocol as RFC- + 854. In case of conflict, RFC-854 takes precedence, and the + present document takes precedence over both. + + [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977. + + [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October + 1977. + + [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977. + + + +Internet Engineering Task Force [Page 94] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS + Implementation," A. Yasuda and T. Thompson, RFC-1043, February + 1988. + + + FTP REFERENCES: + + + [FTP:1] "File Transfer Protocol," J. Postel and J. Reynolds, RFC- + 959, October 1985. + + [FTP:2] "Document File Format Standards," J. Postel, RFC-678, + December 1974. + + [FTP:3] "File Transfer Protocol," MIL-STD-1780, U.S. Department of + Defense, May 1984. + + This document is based on an earlier version of the FTP + specification (RFC-765) and is obsolete. + + + TFTP REFERENCES: + + + [TFTP:1] "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June + 1981. + + + MAIL REFERENCES: + + + [SMTP:1] "Simple Mail Transfer Protocol," J. Postel, RFC-821, August + 1982. + + [SMTP:2] "Standard For The Format of ARPA Internet Text Messages," + D. Crocker, RFC-822, August 1982. + + This document obsoleted an earlier specification, RFC-733. + + [SMTP:3] "Mail Routing and the Domain System," C. Partridge, RFC- + 974, January 1986. + + This RFC describes the use of MX records, a mandatory extension + to the mail delivery process. + + [SMTP:4] "Duplicate Messages and SMTP," C. Partridge, RFC-1047, + February 1988. + + + + +Internet Engineering Task Force [Page 95] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + [SMTP:5a] "Mapping between X.400 and RFC 822," S. Kille, RFC-987, + June 1986. + + [SMTP:5b] "Addendum to RFC-987," S. Kille, RFC-???, September 1987. + + The two preceding RFC's define a proposed standard for + gatewaying mail between the Internet and the X.400 environments. + + [SMTP:6] "Simple Mail Transfer Protocol," MIL-STD-1781, U.S. + Department of Defense, May 1984. + + This specification is intended to describe the same protocol as + does RFC-821. However, MIL-STD-1781 is incomplete; in + particular, it does not include MX records [SMTP:3]. + + [SMTP:7] "A Content-Type Field for Internet Messages," M. Sirbu, + RFC-1049, March 1988. + + + DOMAIN NAME SYSTEM REFERENCES: + + + [DNS:1] "Domain Names - Concepts and Facilities," P. Mockapetris, + RFC-1034, November 1987. + + This document and the following one obsolete RFC-882, RFC-883, + and RFC-973. + + [DNS:2] "Domain Names - Implementation and Specification," RFC-1035, + P. Mockapetris, November 1987. + + + [DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974, + January 1986. + + + [DNS:4] "DoD Internet Host Table Specification," K. Harrenstein, + RFC-952, M. Stahl, E. Feinler, October 1985. + + SECONDARY DNS REFERENCES: + + + [DNS:5] "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler, + RFC-953, October 1985. + + [DNS:6] "Domain Administrators Guide," M. Stahl, RFC-1032, November + 1987. + + + + +Internet Engineering Task Force [Page 96] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + [DNS:7] "Domain Administrators Operations Guide," M. Lottor, RFC- + 1033, November 1987. + + [DNS:8] "The Domain Name System Handbook," Vol. 4 of Internet + Protocol Handbook, NIC 50007, SRI Network Information Center, + August 1989. + + + SYSTEM INITIALIZATION REFERENCES: + + + [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June + 1984. + + [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC- + 951, September 1985. + + [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC- + 1084, December 1988. + + Note: this RFC revised and obsoleted RFC-1048. + + [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T. + Mann, J. Mogul, and M. Theimer, RFC-903, June 1984. + + + MANAGEMENT REFERENCES: + + + [MGT:1] "IAB Recommendations for the Development of Internet Network + Management Standards," V. Cerf, RFC-1052, April 1988. + + [MGT:2] "Structure and Identification of Management Information for + TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065, + August 1988. + + [MGT:3] "Management Information Base for Network Management of + TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066, + August 1988. + + [MGT:4] "A Simple Network Management Protocol," J. Case, M. Fedor, + M. Schoffstall, and C. Davin, RFC-1098, April 1989. + + [MGT:5] "The Common Management Information Services and Protocol + over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989. + + [MGT:6] "Report of the Second Ad Hoc Network Management Review + Group," V. Cerf, RFC-1109, August 1989. + + + +Internet Engineering Task Force [Page 97] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + +Security Considerations + + There are many security issues in the application and support + programs of host software, but a full discussion is beyond the scope + of this RFC. Security-related issues are mentioned in sections + concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and + EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the + SMTP DATA command (Section 5.2.8). + +Author's Address + + Robert Braden + USC/Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA 90292-6695 + + Phone: (213) 822 1511 + + EMail: Braden@ISI.EDU + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 98] + diff --git a/RFC/rfc1176.txt b/RFC/rfc1176.txt new file mode 100644 index 00000000..1ea72a11 --- /dev/null +++ b/RFC/rfc1176.txt @@ -0,0 +1,1683 @@ + + + + + + +Network Working Group M. Crispin +Request for Comments: 1176 Washington +Obsoletes: RFC 1064 August 1990 + + + INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2 + + +Status of this Memo + + This RFC suggests a method for personal computers and workstations to + dynamically access mail from a mailbox server ("repository"). It + obosoletes RFC 1064. This RFC specifies an Experimental Protocol for + the Internet community. Discussion and suggestions for improvement + are requested. Please refer to the current edition of the "IAB + Official Protocol Standards" for the standardization state and status + of this protocol. Distribution of this memo is unlimited. + +Introduction + + The intent of the Interactive Mail Access Protocol, Version 2 (IMAP2) + is to allow a workstation, personal computer, or similar small + machine to access electronic mail from a mailbox server. Since the + distinction between personal computers and workstations is blurring + over time, it is desirable to have a single solution that addresses + the need in a general fashion. IMAP2 is the "glue" of a distributed + electronic mail system consisting of a family of client and server + implementations on a wide variety of platforms, from small single- + tasking personal computing engines to complex multi-user timesharing + systems. + + Although different in many ways from the Post Office Protocols (POP2 + and POP3, hereafter referred to collectively as "POP") described in + RFC 937 and RFC 1081, IMAP2 may be thought of as a functional + superset of these. RFC 937 was used as a model for this RFC. There + was a cognizant reason for this; POP deals with a similar problem, + albeit with a less comprehensive solution, and it was desirable to + offer a basis for comparison. + + Like POP, IMAP2 specifies a means of accessing stored mail and not of + posting mail; this function is handled by a mail transfer protocol + such as SMTP (RFC 821). + + This protocol assumes a reliable data stream such as provided by TCP + or any similar protocol. When TCP is used, the IMAP2 server listens + on port 143. + + + + + +Crispin [Page 1] + +RFC 1176 IMAP2 August 1990 + + +System Model and Philosophy + + Electronic mail is a primary means of communication for the widely + spread Internet community. The advent of distributed personal + computers and workstations has forced a significant rethinking of the + mechanisms employed to manage electronic mail. With mainframes, each + user tends to receive and process mail at the computer he uses most + of the time, his "primary host". The first inclination of many users + when an independent workstation is placed in front of them is to + begin receiving mail at the workstation, and many vendors have + implemented facilities to do this. However, this approach has + several disadvantages: + + (1) Personal computers and many workstations have a software + design that gives full control of all aspects of the system to the + user at the console. As a result, background tasks such as + receiving mail may not run for long periods of time; either + because the user is asking to use all the machine's resources, or + because the user has (perhaps accidentally) manipulated the + environment in such a way that it prevents mail reception. In + many personal computers, the operating system is single-tasking + and this is the only mode of operation. Any of these conditions + could lead to repeated failed delivery attempts by outside agents. + + (2) The hardware failure of a single machine can keep its user + "off the air" for a considerable time, since repair of individual + units may be delayed. Given the growing number of personal + computers and workstations spread throughout office environments, + quick repair of such systems is not assured. On the other hand, a + central mainframe is generally repaired soon after failure. + + (3) Personal computers and workstations are often not backed up + with as much diligence as a central mainframe, if at all. + + (4) It is more difficult to keep track of mailing addresses when + each person is associated with a distinct machine. Consider the + difficulty in keeping track of many postal addresses or phone + numbers, particularly if there was no single address or phone + number for an organization through which you could reach any + person in that organization. Traditionally, electronic mail on + the ARPANET involved remembering a name and one of several "hosts" + (machines) whose name reflected the organization in which the + individual worked. This was suitable at a time when most + organizations had only one central host. It is less satisfactory + today unless the concept of a host is changed to refer to an + organizational entity and not a particular machine. + + (5) It is difficult to keep a multitude of heterogeneous machines + + + +Crispin [Page 2] + +RFC 1176 IMAP2 August 1990 + + + working properly with complex mailing protocols, making it + difficult to move forward as progress is made in electronic + communication and as new standards emerge. Each system has to + worry about receiving incoming mail, routing and delivering + outgoing mail, formatting, storing, and providing for the + stability of mailboxes over a variety of possible filing and + mailing protocols. + + Consequently, while a personal computer or workstation may be viewed + as an Internet host in the sense that it implements TCP/IP, it should + not be viewed as the entity that contains the user's mailbox. + Instead, a mail server machine ("server", sometimes called a + "repository") should hold the mailbox, and the personal computer or + workstation (hereafter referred to as a "client") should access the + mailbox via mail transactions. + + Because the mail server machine is isolated from direct user + manipulation, it should achieve high software reliability easily, + and, as a shared resource, it should also achieve high hardware + reliability, perhaps through redundancy. The mail server may be + accessed from arbitrary locations, allowing users to read mail across + campus, town, or country using commonly available clients. + Furthermore, the same user may access his mailbox from different + clients at different times, and multiple users may access the same + mailbox simultaneously. + + The mail server acts an an interface among users, data storage, and + other mailers. A mail access protocol retrieves messages, accesss + and changes properties of messages, and otherwise manages mailboxes. + This differs from some approaches (e.g., Unix mail via NFS) in that + the mail access protocol is used for all message manipulations, + isolating the user and the client from all knowledge of how the data + storage is used. This means that the mail server can use the data + storage in whatever way is most efficient to organize the mail in + that particular environment, without having to worry about storage + representation compatibility across different machines. + + A mail access protocol further differs in that it transmits + information only on demand. A well-designed mail access protocol + requires considerably less network traffic than Unix mail via NFS, + particularly when the mail file is large. The result is that a mail + access protocol can scale well to situations of large mailboxes or + networks with high latency or low speed. + + In defining a mail access protocol, it is important to keep in mind + that the client and server form a macrosystem, in which it should be + possible to exploit the strong points of both while compensating for + each other's weaknesses. Furthermore, it is desirable to allow for a + + + +Crispin [Page 3] + +RFC 1176 IMAP2 August 1990 + + + growth path beyond the hoary text-only RFC 822 protocol, specifically + in the area of attachments and multi-media mail, to ease the eventual + transition to ISO solutions. + + Unlike POP, IMAP2 has extensive features for remote searching and + parsing of messages on the server. A free text search (optionally + with other searching) can be made in the entire mailbox by the server + and the results made available to the client without the client + having to transfer the entire mailbox and searching itself. Since + remote parsing of a message into a structured (and standard format) + "envelope" is available, a client can display envelope information + and implement commands such as REPLY without having any understanding + of how to parse RFC 822, etc. headers. The effect of this is + twofold: it further improves the ability to scale well in instances + where network traffic must be reduced, and it reduces the complexity + of the client program. + + Additionally, IMAP2 offers several facilities for managing individual + message state and the mailbox as a whole beyond the simple "delete + message" functionality of POP. Another benefit of IMAP2 is the use + of tagged responses to reduce the possibility of synchronization + errors and the concept of state on the client (a "local cache") that + the server may update without explicit request by the client. These + concepts and how they are used are explained under "Implementation + Discussion" below. + + In spite of this functional richness, IMAP2 is a small protocol. + Although servers should implement the full set of IMAP2 functions, a + simple client can be written that uses IMAP2 in much the way as a POP + client. + + A related protocol to POP and IMAP2 is the DMSP protocol of PCMAIL + (RFC 1056). IMAP2 differs from DMSP more fundamentally, reflecting a + differing architecture from PCMAIL. PCMAIL is either an online + ("interactive mode"), or offline ("batch mode") system with long-term + shared state. Some POP based systems are also offline; in such + systems, since there is no long-term shared state POP is little more + than a download mechanism of the "mail file" to the client. IMAP2- + based software is primarily an online system in which real-time and + simultaneous mail access were considered important. + + In PCMAIL, there is a long-term client/server relationship in which + some mailbox state is preserved on the client. There is a + registration of clients used by a particular user, and the client + keeps a set of "descriptors" for each message that summarize the + message. The server and client synchronize their states when the + DMSP connection starts up, and, if a client has not accessed the + server for a while, the client does a complete reset (reload) of its + + + +Crispin [Page 4] + +RFC 1176 IMAP2 August 1990 + + + state from the server. + + In IMAP2-based software, the client/server relationship lasts only + for the duration of the TCP connection. All mailbox state is + maintained on the server. There is no registration of clients. The + function of a descriptor is handled by a structured representation of + the message "envelope" as noted above. There is no client/server + synchronization since the client does not remember state between + IMAP2 connections. This is not a problem since in general the client + never needs the entire state of the mailbox in a single session, + therefore there isn't much overhead in fetching the state information + that is needed as it is needed. + + There are also some functional differences between IMAP2 and DMSP. + DMSP has functions for sending messages, printing messages, listing + mailboxes, and changing passwords; these are done outside IMAP2. + DMSP has 16 binary flags of which 8 are defined by the system. IMAP2 + has flag names; there are currently 5 defined system flag names and a + facility for some number (30 in the current implementations) of user + flag names. IMAP2 has a sophisticated message search facility in the + server to identify interesting messages based on dates, addresses, + flag status, or textual contents without compelling the client to + fetch this data for every message. + + It was felt that maintaining state on the client is advantageous only + in those cases where the client is only used by a single user, or if + there is some means on the client to restrict access to another + user's data. It can be a serious disadvantage in an environment in + which multiple users routinely use the same client, the same user + routinely uses different clients, and where there are no access + restrictions on the client. It was also observed that most user mail + access is to a small set of "interesting" messages, which were either + new mail or mail based on some user-selected criteria. Consequently, + IMAP2 was designed to easily identify those "interesting" messages so + that the client could fetch the state of those messages and not those + that were not "interesting". + +The Protocol + + The IMAP2 protocol consists of a sequence of client commands and + server responses, with server data interspersed between the + responses. Unlike most Internet protocols, commands and responses + are tagged. That is, a command begins with a unique identifier + (typically a short alphanumeric sequence such as a Lisp "gensym" + function would generate e.g., A0001, A0002, etc.), called a tag. The + response to this command is given the same tag from the server. + Additionally, the server may send an arbitrary amount of "unsolicited + data", which is identified by the special reserved tag of "*". There + + + +Crispin [Page 5] + +RFC 1176 IMAP2 August 1990 + + + is another special reserved tag, "+", discussed below. + + The server must be listening for a connection. When a connection is + opened the server sends an unsolicited OK response as a greeting + message and then waits for commands. + + The client opens a connection and waits for the greeting. The client + must not send any commands until it has received the greeting from + the server. + + Once the greeting has been received, the client may begin sending + commands and is not under any obligation to wait for a server + response to this command before sending another command, within the + constraints of TCP flow control. When commands are received the + server acts on them and responds with command responses, often + interspersed with data. The effect of a command can not be + considered complete until a command response with a tag matching the + command is received from the server. + + Although all known IMAP2 servers at the time of this writing process + commands to completion before processing the next command, it is not + required that a server do so. However, many commands can affect the + results of other commands, creating processing-order dependencies + (or, for SEARCH and FIND, ambiguities about which data is associated + with which command). All implementations that operate in a non- + lockstep fashion must recognize such dependencies and defer or + synchronize execution as necessary. In general, such multi- + processing is limited to consecutive FETCH commands. + + Generally, the first command from the client is a LOGIN command with + user name and password arguments to establish identity and access + authorization, unless this has already been accomplished through + other means, e.g. Kerberos. Until identity and access authorization + have been established, no operations other than LOGIN or LOGOUT are + permitted. + + Once identity and authorization have been established, the client + must send a SELECT command to access the desired mailbox; no mailbox + is selected by default. SELECT's argument is implementation- + dependent; however the word "INBOX" must be implemented to mean the + primary or default mailbox for this user, independent of any other + server semantics. On a successful SELECT, the server will send a + list of valid flags, number of messages, and number of messages + arrived since last access for this mailbox as unsolicited data, + followed by an OK response. The client may terminate access to this + mailbox and access a different one with another SELECT command. + + The client reads mailbox information with FETCH commands. The actual + + + +Crispin [Page 6] + +RFC 1176 IMAP2 August 1990 + + + data is transmitted via the unsolicited data mechanism (that is, + FETCH should be viewed as instructing the server to include the + desired data along with any other data it wishes to transmit to the + client). There are three major categories of data that may be + fetched. + + The first category is data that is associated with a message as an + entity in the mailbox. There are now three such items of data: the + "internal date", the "RFC 822 size", and the "flags". The internal + date is the date and time that the message was placed in the mailbox. + The RFC 822 size is subject to deletion in the future; it is the size + in bytes of the message, expressed as an RFC 822 text string. + Current clients only use it as part of a status display line. The + flags are a list of status flags associated with the message (see + below). All the first category data can be fetched by using the + macro-fetch word "FAST"; that is, "FAST" expands to "(FLAGS + INTERNALDATE RFC822.SIZE)". + + The second category is that data that describes the composition and + delivery information of a message; that is, information such as the + message sender, recipient lists, message-ID, subject, etc. This is + the information that is stored in the message header in RFC 822 + format message and is traditionally called the "envelope". [Note: + this should not be confused with the SMTP (RFC 821) envelope, which + is strictly limited to delivery information.] IMAP2 defines a + structured and unambiguous representation for the envelope that is + particularly suited for Lisp-based parsers. A client can use the + envelope for operations such as replying and not worry about RFC 822 + at all. Envelopes are discussed in more detail below. The first two + categories of data can be fetched together by using the macro-fetch + word "ALL"; that is, "ALL" expands to "(FLAGS INTERNALDATE + RFC822.SIZE ENVELOPE)". + + The third category is that data that is intended for direct human + viewing. The present RFC 822 based IMAP2 defines three such items: + RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the two + former appended together in a single text string). RFC822.HEADER is + the "raw", unprocessed RFC 822 format header of the message. + Fetching "RFC822" is equivalent to fetching the RFC 822 + representation of the message as stored on the mailbox without any + filtering or processing. + + An intelligent client will "FETCH ALL" for some (or all) of the + messages in the mailbox for use as a presentation menu, and when the + user wishes to read a particular message will "FETCH RFC822.TEXT" to + get the message body. A more primitive client could, of course, + simply "FETCH RFC822" a`la POP-type functionality. + + + + +Crispin [Page 7] + +RFC 1176 IMAP2 August 1990 + + + The client can alter certain data (currently only the flags) by a + STORE command. As an example, a message is deleted from a mailbox by + a STORE command that includes the \DELETED flag as a flag being set. + + Other client operations include copying a message to another mailbox + (COPY command), permanently removing deleted messages (EXPUNGE + command), checking for new messages (CHECK command), and searching + for messages that match certain criteria (SEARCH command). + + The client terminates the session with the LOGOUT command. The + server returns a "BYE" followed by an "OK". + + A Typical Scenario + + Client Server + ------ ------ + {Wait for Connection} + {Open Connection} --> + <-- * OK IMAP2 Server Ready + {Wait for command} + A001 LOGIN Fred Secret --> + <-- A001 OK User Fred logged in + {Wait for command} + A002 SELECT INBOX --> + <-- * FLAGS (Meeting Notice \Answered + \Flagged \Deleted \Seen) + <-- * 19 EXISTS + <-- * 2 RECENT + <-- A0002 OK Select complete + {Wait for command} + A003 FETCH 1:19 ALL --> + <-- * 1 Fetch (......) + ... + <-- * 18 Fetch (......) + <-- * 19 Fetch (......) + <-- A003 OK Fetch complete + {Wait for command} + A004 FETCH 8 RFC822.TEXT --> + <-- * 8 Fetch (RFC822.TEXT {893} + ...893 characters of text... + <-- ) + <-- A004 OK Fetch complete + {Wait for command} + + + + + + + + +Crispin [Page 8] + +RFC 1176 IMAP2 August 1990 + + + A005 STORE 8 +Flags \Deleted --> + <-- * 8 Store (Flags (\Deleted + \Seen)) + <-- A005 OK Store complete + {Wait for command} + A006 EXPUNGE --> + <-- * 19 EXISTS + <-- * 8 EXPUNGE + <-- * 18 EXISTS + <-- A006 Expunge complete + {Wait for command} + A007 LOGOUT --> + <-- * BYE IMAP2 server quitting + <-- A007 OK Logout complete + {Close Connection} --><-- {Close connection} + {Go back to start} +Conventions + + The following terms are used in a meta-sense in the syntax + specification below: + + An ASCII-STRING is a sequence of arbitrary ASCII characters. + + An ATOM is a sequence of ASCII characters delimited by SP or CRLF. + + A CHARACTER is any ASCII character except """", "{", CR, LF, "%", + or "\". + + A CRLF is an ASCII carriage-return character followed immediately + by an ASCII linefeed character. + + A NUMBER is a sequence of the ASCII characters that represent + decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or + ":". + + A SP is the ASCII space character. + + A TEXT_LINE is a human-readable sequence of ASCII characters up to + but not including a terminating CRLF. + + A common field in the IMAP2 protocol is a STRING, which may be an + ATOM, QUOTED-STRING (a sequence of CHARACTERs inside double-quotes), + or a LITERAL. A literal consists of an open brace ("{"), a number, a + close brace ("}"), a CRLF, and then an ASCII-STRING of n characters, + where n is the value of the number inside the brace. In general, a + string should be represented as an ATOM or QUOTED-STRING if at all + possible. The semantics for QUOTED-STRING or LITERAL are checked + before those for ATOM; therefore an ATOM used in a STRING may only + + + +Crispin [Page 9] + +RFC 1176 IMAP2 August 1990 + + + contain CHARACTERs. Literals are most often sent from the server to + the client; in the rare case of a client to server literal there is a + special consideration (see the "+ text" response below). + + Another important field is the SEQUENCE, which identifies a set of + messages by consecutive numbers from 1 to n where n is the number of + messages in the mailbox. A sequence may consist of a single number, + a pair of numbers delimited by colon (equivalent to all numbers + between those two numbers), or a list of single numbers or number + pairs. For example, the sequence 2,4:7,9,12:15 is equivalent to + 2,4,5,6,7,9,12,13,14,15 and identifies all those messages. + +Definitions of Commands and Responses + + Summary of Commands and Responses + + Commands || Responses + -------- || ------- + tag NOOP || tag OK text + tag LOGIN user password || tag NO text + tag LOGOUT || tag BAD text + tag SELECT mailbox || * number message_data + tag BBOARD bulletin_board || * FLAGS flag_list + tag FIND MAILBOXES pattern || * SEARCH sequence + tag FIND BBOARDS pattern || * BBOARD string + tag CHECK || * MAILBOX string + tag EXPUNGE || * BYE text + tag COPY sequence mailbox || * OK text + tag FETCH sequence data || * NO text + tag STORE sequence data value || * BAD text + tag SEARCH search_program || + text + +Commands + + tag NOOP + + The NOOP command returns an OK to the client. By itself, it does + nothing, but certain things may happen as side effects. For + example, server implementations that implicitly check the mailbox + for new mail may do so as a result of this command. The primary + use of this command is to for the client to see if the server is + still alive (and notify the server that the client is still alive, + for those servers that have inactivity autologout timers). + + tag LOGIN user password + + The LOGIN command identifies the user to the server and carries + the password authenticating this user. This information is used + + + +Crispin [Page 10] + +RFC 1176 IMAP2 August 1990 + + + by the server to control access to the mailboxes. + + EXAMPLE: A001 LOGIN SMITH SESAME + logs in as user SMITH with password SESAME. + + tag LOGOUT + + The LOGOUT command informs the server that the client is done with + the session. The server should send an unsolicited BYE response + before the (tagged) OK response, and then close the network + connection. + + tag SELECT mailbox + + The SELECT command selects a particular mailbox. The server must + check that the user is permitted read access to this mailbox. + Before returning an OK to the client, the server must send the + following unsolicited data to the client: + FLAGS mailbox's defined flags + EXISTS the number of messages in the mailbox + RECENT the number of new messages in the mailbox + in order to define the initial state of the mailbox at the client. + + Multiple SELECT commands are permitted in a session, in which case + the previous mailbox is automatically deselected when a new SELECT + is made. + + The default mailbox for the SELECT command is INBOX, which is a + special name reserved to mean "the primary mailbox for this user + on this server". The format of other mailbox names is operating + system dependent (as of this writing, it reflects the filename + path of the mailbox file on the current servers). + + It is customary, although not required, for the text of an OK + response to the SELECT command to begin with either "[READ-ONLY]" + or "[READ-WRITE]" to show the mailbox's access status. + + EXAMPLE: A002 SELECT INBOX + selects the default mailbox. + + tag BBOARD bulletin_board + + The BBOARD command is equivalent to SELECT, and returns the same + output. However, it differs from SELECT in that its argument is a + shared mailbox (bulletin board) name instead of an ordinary + mailbox. The format of a bulletin name is implementation + specific, although it is strongly encouraged to use something that + resembles a name in a generic sense and not a file or mailbox name + + + +Crispin [Page 11] + +RFC 1176 IMAP2 August 1990 + + + on the particular system. There is no requirement that a bulletin + board name be a mailbox name or a file name (in particular, Unix + netnews has a completely different namespace from mailbox or file + names). + + Support for BBOARD is optional. + + tag FIND MAILBOXES pattern + + The FIND MAILBOXES command accepts as an argument a pattern + (including wildcards) that specifies some set of mailbox names + that are usable by the SELECT command. The format of mailboxes is + implementation dependent. The special mailbox name INBOX is not + included in the output. + + Two wildcard characters are defined; "*" specifies any number + (including zero) characters may match at this position and "%" + specifies a single character may match at this position. For + example, FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR, + whereas FOO%BAR will match only FOO.BAR. "*" will match all + mailboxes. + + The FIND MAILBOXES command will return some set of unsolicited + MAILBOX replies that have as their value a single mailbox name. + + EXAMPLE: A002 FIND MAILBOXES * + * MAILBOX FOOBAR + * MAILBOX GENERAL + A002 FIND completed + + Although the use of explicit file or path names for mailboxes is + discouraged by this standard, it may be unavoidable. It is + important that the value returned in the MAILBOX unsolicited reply + be usable in the SELECT command without remembering any path + specification that may have been used in the FIND MAILBOXES + pattern. + + Support for FIND MAILBOXES is optional. If a client's attempt + returns BAD as a response then the client can make no assumptions + about what mailboxes exist on the server other than INBOX. + + tag FIND BBOARDS pattern + + The FIND BBOARDS command accepts as an argument a pattern that + specifies some set of bulletin board names that are usable by the + BBOARD command. Wildcards are permitted as in FIND MAILBOXES. + + The FIND BBOARDS command will return some set of unsolicited + + + +Crispin [Page 12] + +RFC 1176 IMAP2 August 1990 + + + BBOARD replies that have as their value a single bulletin board + name. + + EXAMPLE: A002 FIND BBOARDS * + * BBOARD FOOBAR + * BBOARD GENERAL + A002 FIND completed + + Support for FIND BBOARDS is optional. If a client's attempt + returns BAD as a response then the client can make no assumptions + about what bulletin boards exist on the server, or that they exist + at all. + + tag CHECK + + The CHECK command forces a check for new messages and a rescan of + the mailbox for internal change for those implementations that + allow multiple simultaneous read/write access to the same mailbox. + It is recommend that periodic implicit checks for new mail be done + by servers as well. The server should send unsolicited EXISTS and + RECENT responses with the current status before returning an OK to + the client. + + tag EXPUNGE + + The EXPUNGE command permanently removes all messages with the + \DELETED flag set in its flags from the mailbox. Before returning + an OK to the client, for each message that is removed, an + unsolicited EXPUNGE response is sent. The message number for each + successive message in the mailbox is immediately decremented by 1; + this means that if the last 5 messages in a 9-message mail file + are expunged you will receive 5 unsolicited EXPUNGE responses for + message 5. To ensure mailbox integrity and server/client + synchronization, it is recommended that the server do an implicit + check before commencing the expunge and again when the expunge is + completed. Furthermore, if the server allows multiple + simultaneous access to the same mail file the server must lock the + mail file for exclusive access while an expunge is taking place. + + EXPUNGE is not allowed if the user does not have write access to + this mailbox. + + tag COPY sequence mailbox + + The COPY command copies the specified message(s) to the specified + destination mailbox. If the destination mailbox does not exist, + the server should create it. Before returning an OK to the + client, the server should return an unsolicited COPY response + + + +Crispin [Page 13] + +RFC 1176 IMAP2 August 1990 + + + for each message copied. A copy should set the \SEEN flag for all + messages that were successfully copied (provided, of course, that + the user has write access to this mailbox). + + EXAMPLE: A003 COPY 2:4 MEETING + copies messages 2, 3, and 4 to mailbox "MEETING". + + COPY is not allowed if the user does not have write access to the + destination mailbox. + + tag FETCH sequence data + + The FETCH command retrieves data associated with a message in the + mailbox. The data items to be fetched may be either a single atom + or an S-expression list. The currently defined data items that + can be fetched are: + + ALL Macro equivalent to: + (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE) + + ENVELOPE The envelope of the message. The envelope is + computed by the server by parsing the RFC 822 + header into the component parts, defaulting + various fields as necessary. + + FAST Macro equivalent to: + (FLAGS INTERNALDATE RFC822.SIZE) + + FLAGS The flags that are set for this message. + This may include the following system flags: + + \RECENT Message arrived since the + previous time this mailbox + was read + \SEEN Message has been read + \ANSWERED Message has been answered + \FLAGGED Message is "flagged" for + urgent/special attention + \DELETED Message is "deleted" for + removal by later EXPUNGE + + INTERNALDATE The date and time the message was written to + the mailbox. + + + + + + + + +Crispin [Page 14] + +RFC 1176 IMAP2 August 1990 + + + RFC822 The message in RFC 822 format. The \SEEN + flag is implicitly set; if this causes the + flags to change they should be included as + part of the fetch results. This is the + concatenation of RFC822.HEADER and RFC822.TEXT. + + RFC822.HEADER The "raw" RFC 822 format header of the message + as stored on the server. + + RFC822.SIZE The number of characters in the message as + expressed in RFC 822 format. + + RFC822.TEXT The text body of the message, omitting the + RFC 822 header. The \SEEN flag is implicitly + set as with RFC822 above. + + EXAMPLES: + + A003 FETCH 2:4 ALL + fetches the flags, internal date, RFC 822 size, and envelope + for messages 2, 3, and 4. + + A004 FETCH 3 RFC822 + fetches the RFC 822 representation for message 3. + + A005 FETCH 4 (FLAGS RFC822.HEADER) + fetches the flags and RFC 822 format header for message 4. + + Note: An attempt to FETCH already-transmitted data may have no + result. See the Implementation Discussion below. + + tag STORE sequence data value + + The STORE command alters data associated with a message in the + mailbox. The currently defined data items that can be stored are: + + FLAGS Replace the flags for the message with the + argument (in flag list format). + + +FLAGS Add the flags in the argument to the + message's flag list. + + -FLAGS Remove the flags in the argument from the + message's flag list. + + STORE is not allowed if the user does not have write access to + this mailbox. + + + + +Crispin [Page 15] + +RFC 1176 IMAP2 August 1990 + + + EXAMPLE: A003 STORE 2:4 +FLAGS (\DELETED) + marks messages 2, 3, and 4 for deletion. + + tag SEARCH search_criteria + + The SEARCH command searches the mailbox for messages that match + the given set of criteria. The unsolicited SEARCH <1#number> + response from the server is a list of messages that express the + intersection (AND function) of all the messages which match that + criteria. For example, + A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87 + returns the message numbers for all deleted messages from Smith + that were placed in the mail file since October 1, 1987. + + In all search criteria which use strings, a message matches the + criteria if the string is a case-independent substring of that + field. The currently defined criteria are: + + ALL All messages in the mailbox; the default + initial criterion for ANDing. + + ANSWERED Messages with the \ANSWERED flag set. + + BCC string Messages which contain the specified string + in the envelope's BCC field. + + BEFORE date Messages whose internal date is earlier than + the specified date. + + BODY string Messages which contain the specified string + in the body of the message. + + CC string Messages which contain the specified string + in the envelope's CC field. + + DELETED Messages with the \DELETED flag set. + + FLAGGED Messages with the \FLAGGED flag set. + + FROM string Messages which contain the specified string + in the envelope's FROM field. + + KEYWORD flag Messages with the specified flag set. + + NEW Messages which have the \RECENT flag set but + not the \SEEN flag. This is functionally + equivalent to "RECENT UNSEEN". + + + + +Crispin [Page 16] + +RFC 1176 IMAP2 August 1990 + + + OLD Messages which do not have the \RECENT flag + set. + + ON date Messages whose internal date is the same as + the specified date. + + RECENT Messages which have the \RECENT flag set. + + SEEN Messages which have the \SEEN flag set. + + SINCE date Messages whose internal date is later than + the specified date. + + SUBJECT string Messages which contain the specified string + in the envelope's SUBJECT field. + + TEXT string Messages which contain the specified string. + + TO string Messages which contain the specified string in + the envelope's TO field. + + UNANSWERED Messages which do not have the \ANSWERED flag + set. + + UNDELETED Messages which do not have the \DELETED flag + set. + + UNFLAGGED Messages which do not have the \FLAGGED flag + set. + + UNKEYWORD flag Messages which do not have the specified flag + set. + + UNSEEN Messages which do not have the \SEEN flag set. + + + + + + + + + + + + + + + + + +Crispin [Page 17] + +RFC 1176 IMAP2 August 1990 + + +Responses + + tag OK text + + This response identifies successful completion of the command with + that tag. The text is a line of human-readable text that may be + useful in a protocol telemetry log for debugging purposes. + + tag NO text + + This response identifies unsuccessful completion of the command + with that tag. The text is a line of human-readable text that + probably should be displayed to the user in an error report by the + client. + + tag BAD text + + This response identifies faulty protocol received from the client; + The text is a line of human-readable text that should be recorded + in any telemetry as part of a bug report to the maintainer of the + client. + + * number message_data + + This response occurs as a result of several different commands. + The message_data is one of the following: + + EXISTS The specified number of messages exists in the mailbox. + + RECENT The specified number of messages have arrived since the + previous time this mailbox was read. + + EXPUNGE The specified message number has been permanently + removed from the mailbox, and the next message in the + mailbox (if any) becomes that message number. + + STORE data + Obsolete and functionally equivalent to FETCH. + + FETCH data + This is the principle means by which data about a + message is returned to the client. The data is in a + Lisp-like S-expression property list form. The current + properties are: + + ENVELOPE An S-expression format list that describes the + envelope of a message. The envelope is computed + by the server by parsing the RFC 822 header into + + + +Crispin [Page 18] + +RFC 1176 IMAP2 August 1990 + + + the component parts, defaulting various fields + as necessary. + + The fields of the envelope are in the following + order: date, subject, from, sender, reply-to, to, + cc, bcc, in-reply-to, and message-id. The date, + subject, in-reply-to, and message-id fields are + strings. The from, sender, reply-to, to, cc, + and bcc fields are lists of addresses. + + An address is an S-expression format list that + describes an electronic mail address. The fields + of an address are in the following order: + personal name, source-route (a.k.a. the + at-domain-list in SMTP), mailbox name, and + host name. + + Any field of an envelope or address that is + not applicable is presented as the atom NIL. + Note that the server must default the reply-to + and sender fields from the from field; a client is + not expected to know to do this. + + FLAGS An S-expression format list of flags that are set + for this message. This may include the following + system flags: + + \RECENT Message arrived since the + previous time this mailbox + was read + \SEEN Message has been read + \ANSWERED Message has been answered + \FLAGGED Message is "flagged" for + urgent/special attention + \DELETED Message is "deleted" for + removal by later EXPUNGE + + INTERNALDATE A string containing the date and time the + message was written to the mailbox. + + RFC822 A string expressing the message in RFC 822 + format. + + RFC822.HEADER A string expressing the RFC 822 format + header of the message + + RFC822.SIZE A number indicating the number of + characters in the message as expressed + + + +Crispin [Page 19] + +RFC 1176 IMAP2 August 1990 + + + in RFC 822 format. + + RFC822.TEXT A string expressing the text body of the + message, omitting the RFC 822 header. + + * FLAGS flag_list + + This response occurs as a result of a SELECT command. The flag + list are the list of flags (at a minimum, the system-defined + flags) that are applicable for this mailbox. Flags other than the + system flags are a function of the server implementation. + + * SEARCH number(s) + + This response occurs as a result of a SEARCH command. The + number(s) refer to those messages that match the search criteria. + Each number is delimited by a space, e.g., "SEARCH 2 3 6". + + * BBOARD string + + This response occurs as a result of a FIND BBOARDS command. The + string is a bulletin board name that matches the pattern in the + command. + + * MAILBOX string + + This response occurs as a result of a FIND MAILBOXES command. The + string is a mailbox name that matches the pattern in the command. + + * BYE text + + This response identifies that the server is about to close the + connection. The text is a line of human-readable text that should + be displayed to the user in a status report by the client. This + may be sent as part of a normal logout sequence, or as a panic + shutdown announcement by the server. It is also used by some + servers as an announcement of an inactivity autologout. + + * OK text + + This response identifies normal operation on the server. No + special action by the client is called for, however, the text + should be displayed to the user in some fashion. This is + currently only used by servers at startup as a greeting message to + show they are ready to accept the first command. + + + + + + +Crispin [Page 20] + +RFC 1176 IMAP2 August 1990 + + + * NO text + + This response identifies a warning from the server that does not + affect the overall results of any particular request. The text is + a line of human-readable text that should be presented to the user + as a warning of improper operation. + + * BAD text + + This response identifies a serious error at the server; it may + also indicate faulty protocol from the client in which a tag could + not be parsed. The text is a line of human-readable text that + should be presented to the user as a serious or possibly fatal + error. It should also be recorded in any telemetry as part of a + bug report to the maintainer of the client and server. + + + text + + This response identifies that the server is ready to accept the + text of a literal from the client. Normally, a command from the + client is a single text line. If the server detects an error in + the command, it can simply discard the remainder of the line. It + cannot do this for commands that contain literals, since a literal + can be an arbitrarily long amount of text, and the server may not + even be expecting a literal. This mechanism is provided so the + client knows not to send a literal until the server expects it, + preserving client/server synchronization. + + In practice, this condition is rarely encountered. In the current + protocol, the only client command likely to contain a literal is + the LOGIN command. Consider a server that validates the user + before checking the password. If the password contains "funny" + characters and hence is sent as a literal, then if the user is + invalid an error would occur before the password is parsed. + + No such synchronization protection is provided for literals sent + from the server to the client, for performance reasons. Any + synchronization problems in this direction would be caused by a + bug in the client or server. + + + + + + + + + + + + +Crispin [Page 21] + +RFC 1176 IMAP2 August 1990 + + +Sample IMAP2 session + + The following is a transcript of an IMAP2 session. Server output is + identified by "S:" and client output by "U:". In cases where lines + are too long to fit within the boundaries of this document, the line + is continued on the next line. + + S: * OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol II Service + 6.1(349) at Thu, 9 Jun 88 14:58:30 PDT + U: a001 login crispin secret + S: a002 OK User CRISPIN logged in at Thu, 9 Jun 88 14:58:42 PDT, job 76 + U: a002 select inbox + S: * FLAGS (Bugs SF Party Skating Meeting Flames Request AI Question + Note \XXXX \YYYY \Answered \Flagged \Deleted \Seen) + S: * 16 EXISTS + S: * 0 RECENT + S: a002 OK Select complete + U: a003 fetch 16 all + S: * 16 Fetch (Flags (\Seen) InternalDate " 9-Jun-88 12:55:44 PDT" + RFC822.Size 637 Envelope ("Sat, 4 Jun 88 13:27:11 PDT" + "INFO-MAC Mail Message" (("Larry Fagan" NIL "FAGAN" + "SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN" + "SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN" + "SUMEX-AIM.Stanford.EDU")) ((NIL NIL "rindflEISCH" + "SUMEX-AIM.Stanford.EDU")) NIL NIL NIL + "<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>")) + S: a003 OK Fetch completed + U: a004 fetch 16 rfc822 + S: * 16 Fetch (RFC822 {637} + S: Mail-From: RINDFLEISCH created at 9-Jun-88 12:55:43 + S: Mail-From: FAGAN created at 4-Jun-88 13:27:12 + S: Date: Sat, 4 Jun 88 13:27:11 PDT + S: From: Larry Fagan + S: To: rindflEISCH@SUMEX-AIM.Stanford.EDU + S: Subject: INFO-MAC Mail Message + S: Message-ID: <12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU> + S: ReSent-Date: Thu, 9 Jun 88 12:55:43 PDT + S: ReSent-From: TC Rindfleisch + S: ReSent-To: Yeager@SUMEX-AIM.Stanford.EDU, + Crispin@SUMEX-AIM.Stanford.EDU + S: ReSent-Message-ID: + <12405133897.80.RINDFLEISCH@SUMEX-AIM.Stanford.EDU> + S: + S: The file is usenetv4-55.arc ... + S: Larry + S: ------- + S: ) + S: a004 OK Fetch completed + + + +Crispin [Page 22] + +RFC 1176 IMAP2 August 1990 + + + U: a005 logout + S: * BYE DEC-20 IMAP II server terminating connection + S: a005 OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol + Service logout + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin [Page 23] + +RFC 1176 IMAP2 August 1990 + + +Implementation Discussion + + There are several advantages to the scheme of tags and unsolicited + responses. First, the infamous synchronization problems of SMTP and + similar protocols do not happen with tagged commands; a command is + not considered satisfied until a response with the same tag is seen. + Tagging allows an arbitrary amount of other responses ("unsolicited" + data) to be sent by the server with no possibility of the client + losing synchronization. Compare this with the problems that FTP or + SMTP clients have with continuation, partial completion, and + commentary reply codes. + + Another advantage is that a non-lockstep client implementation is + possible. The client could send a command, and entrust the handling + of the server responses to a different process that would signal the + client when the tagged response comes in. Under certain + circumstances, the client may have more than one command outstanding. + + It was observed that synchronization problems can occur with literals + if the literal is not recognized as such. Fortunately, the cases in + which this can happen are rare; a mechanism (the special "+" tag + response) was introduced to handle those few cases. The proper way + to address this problem is probably to move towards a record-oriented + architecture instead of the text stream model provided by TCP. + + An IMAP2 client must maintain a local cache of data from the mailbox. + This cache is an incomplete model of the mailbox, and at startup is + empty. A listener processes all unsolicited data, and updates the + cache based on this data. If a tagged response arrives, the listener + unblocks the process that sent the tagged request. + + Unsolicited data needs some discussion. Unlike most protocols, in + which the server merely does the client's bidding, an IMAP2 server + has a semi-autonomous role. By sending "unsolicited data", the + server is in effect sending a command to the client -- to update or + extend the client's cache with new information from the server. In + other words, a "fetch" command is merely a request to the server to + ensure that the client's cache has the most up-to-date version of the + requested information. A server acknowledgement to the "fetch" is a + statement that all the requested data has been sent. + + Although no current server does this, a server is not obliged by the + protocol to send data that it has already sent and is unchanged. An + exception to this is the actual message text fetching operations + (RFC822, RFC822.HEADER, and RFC822.TEXT), owing to the possibly + excessive resource consumption of maintaining this data in a cache. + It can not be assumed that a FETCH will transmit any data; only that + an OK to the FETCH means that the client's cache has the most up-to- + + + +Crispin [Page 24] + +RFC 1176 IMAP2 August 1990 + + + date information. + + When a mailbox is selected, the initial unsolicited data from the + server arrives. The first piece of data is the number of messages. + By sending a new EXISTS unsolicited data message the server causes + the client to resize its cache (this is how newly arrived mail is + handled). If the client attempts to access information from the + cache, it will encounter empty spots that will trigger "fetch" + requests. The request would be sent, some unsolicited data including + the answer to the fetch will flow back, and then the "fetch" response + will unblock the client. + + People familiar with demand-paged virtual memory operating system + design will recognize this model as being similar to page-fault + handling on a demand-paged system. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin [Page 25] + +RFC 1176 IMAP2 August 1990 + + +Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in RFC 822 with one exception; the + delimiter used with the "#" construct is a single space (SP) and not + a comma. + + address ::= "(" addr_name SP addr_adl SP addr_mailbox SP + addr_host ")" + + addr_adl ::= nil / string + + addr_host ::= nil / string + + addr_mailbox ::= nil / string + + addr_name ::= nil / string + + bboard ::= "BBOARD" SP string + + check ::= "CHECK" + + copy ::= "COPY" SP sequence SP mailbox + + data ::= ("FLAGS" SP flag_list / "SEARCH" SP 1#number / + "BYE" SP text_line / "OK" SP text_line / + "NO" SP text_line / "BAD" SP text_line) + + date ::= string in form "dd-mmm-yy hh:mm:ss-zzz" + + envelope ::= "(" env_date SP env_subject SP env_from SP + env_sender SP env_reply-to SP env_to SP + env_cc SP env_bcc SP env_in-reply-to SP + env_message-id ")" + + env_bcc ::= nil / "(" 1*address ")" + + env_cc ::= nil / "(" 1*address ")" + + env_date ::= string + + env_from ::= nil / "(" 1*address ")" + + env_in-reply-to ::= nil / string + + env_message-id ::= nil / string + + env_reply-to ::= nil / "(" 1*address ")" + + + +Crispin [Page 26] + +RFC 1176 IMAP2 August 1990 + + + env_sender ::= nil / "(" 1*address ")" + + env_subject ::= nil / string + + env_to ::= nil / "(" 1*address ")" + + expunge ::= "EXPUNGE" + + fetch ::= "FETCH" SP sequence SP ("ALL" / "FAST" / + fetch_att / "(" 1#fetch_att ")") + + fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / + "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" / + "RFC822.TEXT" + + find ::= "FIND" SP find_option SP string + + find_option ::= "MAILBOXES" / "BBOARDS" + + flag_list ::= ATOM / "(" 1#ATOM ")" + + literal ::= "{" NUMBER "}" CRLF ASCII-STRING + + login ::= "LOGIN" SP userid SP password + + logout ::= "LOGOUT" + + mailbox ::= "INBOX" / string + + msg_copy ::= "COPY" + + msg_data ::= (msg_exists / msg_recent / msg_expunge / + msg_fetch / msg_copy) + + msg_exists ::= "EXISTS" + + msg_expunge ::= "EXPUNGE" + + msg_fetch ::= ("FETCH" / "STORE") SP "(" 1#("ENVELOPE" SP + envelope / "FLAGS" SP "(" 1#(recent_flag + flag_list) ")" / "INTERNALDATE" SP date / + "RFC822" SP string / "RFC822.HEADER" SP string / + "RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP + string) ")" + + msg_recent ::= "RECENT" + + msg_num ::= NUMBER + + + +Crispin [Page 27] + +RFC 1176 IMAP2 August 1990 + + + nil ::= "NIL" + + noop ::= "NOOP" + + password ::= string + + recent_flag ::= "\RECENT" + + ready ::= "+" SP text_line + + request ::= tag SP (noop / login / logout / select / check / + expunge / copy / fetch / store / search / find / + bboard) CRLF + + response ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF + + search ::= "SEARCH" SP 1#("ALL" / "ANSWERED" / + "BCC" SP string / "BEFORE" SP string / + "BODY" SP string / "CC" SP string / "DELETED" / + "FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" / + "ON" SP string / "RECENT" / "SEEN" / + "SINCE" SP string / "TEXT" SP string / + "TO" SP string / "UNANSWERED" / "UNDELETED" / + "UNFLAGGED" / "UNKEYWORD" / "UNSEEN") + + select ::= "SELECT" SP mailbox + + sequence ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":" + sequence) + + store ::= "STORE" SP sequence SP store_att + + store_att ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list / + "FLAGS" SP flag_list) + + string ::= atom / """" 1*character """" / literal + + system_flags ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED" SP + "\SEEN" + + tag ::= atom + + unsolicited ::= "*" SP (msg_num SP msg_data / data) CRLF + + userid ::= string + + + + + + +Crispin [Page 28] + +RFC 1176 IMAP2 August 1990 + + +Implementation Status + + This information is current as of this writing. + + The University of Washington has developed an electronic mail client + library called the "C-Client". It provides complete IMAP2, SMTP, and + local mailbox (both /usr/spool/mail and mail.txt formats) services in + a well-defined way to a user interface main program. Using the C- + Client, the University of Washington has created an operational + client for BSD Unix and two operational clients (one basic, one + advanced) for the NeXT. + + Stanford University/SUMEX has developed operational IMAP2 clients for + Xerox Lisp machines, Texas Instruments Explorers, and the Apple + Macintosh. The core of the Macintosh client is an early version of + the C-Client. SUMEX has also developed IMAP2 servers for TOPS-20 and + BSD Unix. + + All of the above software is in production use, with enthusiastic + local user communities. Active development continues on the + Macintosh and C-Client based clients and the BSD Unix server. This + software is freely available from the University of Washington and + SUMEX. + + IMAP2 software exists for other platforms; for example Nippon + Telephone and Telegraph (NTT) has developed an operational IMAP2 + client for the NTT ELIS. Several organizations are working on a PC + client. + + IMAP2 can be used to access mailboxes at very remote sites, where + echo delays and frequent outages make TELNET and running a local mail + reader intolerable. For example, from a desktop workstation on the + University of Washington local network the author routinely uses + IMAP2 to read and manage mailboxes on various University of + Washington local servers, at two systems at Stanford University, at a + Milnet site, and at a site in Tokyo, Japan. + + This specification does not make any formal definition of size + restrictions, but the DEC-20 server has the following limitations: + + . length of a mailbox: 7,077,888 characters + . maximum number of messages: 18,432 messages + . length of a command line: 10,000 characters + . length of the local host name: 64 characters + . length of a "short" argument: 39 characters + . length of a "long" argument: 491,520 characters + . maximum amount of data output in a single fetch: + 655,360 characters + + + +Crispin [Page 29] + +RFC 1176 IMAP2 August 1990 + + + To date, nobody has run up against any of these limitations, many of + which are substantially larger than most current user mail reading + programs. + +Acknowledgements + + Bill Yeager and Rich Acuff both contributed invaluable suggestions in + the evolution of IMAP2 from the original IMAP. James Rice pointed + out several ambiguities in the previous IMAP2 specification and + otherwise would not allow me to leave bad enough along. Laurence + Lundblade reviewed a draft of this version and made several helpful + suggestions. + + Many dedicated individuals have worked on IMAP2 software, including: + Mark Crispin, Frank Gilmurray, Christopher Lane, Hiroshi Okuno, + Christopher Schmidt, and Bill Yeager. + + Any mistakes, flaws, or sins of omission in this IMAP2 protocol + specification are, however, strictly my own; and the mention of any + name above does not imply an endorsement. + +Security Considerations + + Security issues are not discussed in this memo. + +Author's Address + + Mark R. Crispin + Panda Programming + 6158 Lariat Loop NE + Bainbridge Island, WA 98110-2020 + + Phone: (206) 842-2385 + + EMail: mrc@Tomobiki-Cho.CAC.Washington.EDU + + + + + + + + + + + + + + + + +Crispin [Page 30] + \ No newline at end of file diff --git a/RFC/rfc1203.txt b/RFC/rfc1203.txt new file mode 100644 index 00000000..a362ca88 --- /dev/null +++ b/RFC/rfc1203.txt @@ -0,0 +1,2747 @@ + + + + + + +Network Working Group J. Rice +Request for Comments: 1203 Stanford +Obsoletes: RFC 1064 February 1991 + + + INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 3 + +Status of this Memo + + This RFC suggests a method for workstations to access mail + dynamically from a mailbox server ("repository"). This RFC specifies + a standard for the SUMEX-AIM community and an Experimental Protocol + for the Internet community. Discussion and suggestions for + improvement are requested. Please refer to the current edition of + the "IAB Official Protocol Standards" for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Scope + + The following document is a modified version of RFC 1064, the + definition of the IMAP2 protocol. This RFC has been written + specifically as a counter proposal to RFC 1176, which itself proposes + modifications to IMAP2. Sadly, RFC 1176 was made without internal + consultation with the IMAP community, so we are in a position of + feeling we have to present a counter proposal to what, if we do not + act, will become a de facto standard. The reasons for this counter + proposal are numerous but fall mostly into the following categories: + + - IMAP2 is insufficiently powerful for a number of server/client + interactions which we believe to be important. RFC 1176 + negligibly enhances the functionality of IMAP2. + + - IMAP2 makes what we believe to be an erroneous definition for + unsolicited vs. solicited data. IMAP3 as specified herein + attempts to correct this. RFC 1176 makes no effort to remedy + these problems. + + - RFC 1176 has explicitly modified the intent of RFC 1064 by + allowing the server to make assumptions about the client's + caching architecture. We believe this to be a grave error + and do not support it in this proposal. + + - RFC 1176 specifies a number of "optional" features in the + protocol without specifying a suitable metaprotocol by which + servers and clients can adequately negotiate over the set of + implemented features. This proposal specifies a mechanism + by which servers and clients can come to an unambiguous + understanding about which features are usable by each party. + + + +Rice [Page 1] + +RFC 1203 IMAP3 February 1991 + + + + - RFC 1176 pays only lip-service to being network protocol + independent and, in fact assumes the use of TCP/IP. Neither + RFC 1064 nor this proposal make any such assumption. + + Although there are numerous other detailed objections to RFC 1176, we + believe that the above will serve to show that we believe strongly in + the importance of mailbox abstraction level mail protocols and, after + a couple of years of use of IMAP2 under RFC 1064 we believe that we + have a good enough understanding of the issues involved to be able to + take the next step. + + It is important to take this next step because of the rapid pace of + both mail system and user interface development. We believe that, + for IMAP not to die in its infancy, IMAP must be ready to respond to + emerging ISO and RFC standards in mail, such as for multi-media mail. + We believe that RFC 1176 not only provides a very small increment in + functionality over RFC 1064 but also adds a number of bugs, which + would be detrimental to the IMAP cause. Thus we propose the + following definition for IMAP3. + +Compatibility notes: + + In revising the IMAP2 protocol it has been our intent, wherever + possible to make upwards compatible changes to produce IMAP3. There + were, however, some places that had to be changed incompatibly in + order to compensate for either ambiguities in the IMAP2 protocol as + defined by RFC 1064 or behavior that proved undesirable in the light + of experience. + + It is our goal, however, that existing IMAP2 clients should still be + supported and that, at least for the foreseeable future, all IMAP3 + servers will support IMAP2 behavior as their default mode. + + The following are the major differences between this proposal, RFC + 1176 and RFC 1064: + + - In this proposal we specify a difference between "solicited" and + "unsolicited" data sent from the server. It is generally the + case that data sent by the server can be sent either in response + to an explicit request by the client or by the server of its own + volition. Any data that the server is required to sent to the + client as the result of a request is said to be solicited and + carries the same tag as the request that provoked it. Any data + sent by the server to the client that is not required by the + protocol is said to be unsolicited and carries the special "*" + tag. RFC 1176 preserves the original RFC 1064 terminology that + calls all such data sent by the server "unsolicited" even when + + + +Rice [Page 2] + +RFC 1203 IMAP3 February 1991 + + + it is, in fact, solicited. + + - This proposal introduces the experimental concept of + distinguishing between Generic, Canonical and Concrete keys, + allowing the mailbox to be viewed as a relational database + indexed by these keys. This should allow the IMAP protocol + to evolve away from its current reliance on RFC 822. RFC 1176 + does not have such a unifying model. + + - The SEARCH command has been changed so as to allow multiple + simultaneous searches to be made and to allow unsolicited + search messages to be sent by the server. Such a change is + essential to allow more sophisticated servers that can process + commands asynchronously, possibly substantially delaying + searches over slow backing storage media, for example. It is + also important to allow servers to be able to send unsolicited + search messages that might inform the client of interesting + patterns of messages, such as new and unseen mail. + + - This proposal introduces a specific protocol for the negotiation + of protocol versions and server features. This is important + because it allows client/server pairs to come to an agreement on + what behavior is really available to it. RFC 1176 introduces a + number of "optional" commands, which are in some way analogous + to "feature-introduced" commands in this proposal. The principle + distinction between these is that in RFC 1176 there is no way + for a client to discover the set of optional commands, nor is + there a way for it to determine whether a specific command + really is supported, since RFC 1176 requires the use of the + "BAD" response if a feature is not supported. There is, + therefore, no way for the client to determine why the attempted + command did not work. This also means that, for example, a + client cannot disable certain user commands or make them + invisible on menus if they are not supported, since there + is no way for the client to discover whether the commands are + indeed supported without trying to execute such a command. + + - This proposal introduces a mechanism for clients to create and + delete user flags (keywords). This is nor supported in either + RFC 1176 or RFC 1064, requiring the user to add keys manually + on the server, generally by editing some form of "init" file. + + - RFC 1064 has no mechanism for determining whether a mailbox is + readonly or not. RFC 1176 introduces a non-enforced convention + of encoding data about the readonly status of a mailbox in the + SELECT message's OK respose comment field. This is not regular + with respect to the rest of the protocol, in which the comment + field is used for no purpose other than documentation. This + + + +Rice [Page 3] + +RFC 1203 IMAP3 February 1991 + + + proposal introduces specific protocol additions for the dynamic + determination and modification of the readonly/readwrite status + of mailboxes. + +Introduction + + The intent of the Interactive Mail Access Protocol, Version 3 (IMAP3) + is to allow a (possibly unreliable) workstation or similar machine to + access electronic mail from a reliable mailbox server in an efficient + manner. + + Although different in many ways from POP2 (RFC 937), IMAP3 may be + thought of as a functional superset of POP2, and the POP2 RFC was + used as a model for this RFC. There was a cognizant reason for this; + RFC 937 deals with an identical problem and it was desirable to offer + a basis for comparison. + + Like POP2, IMAP3 specifies a means of accessing stored mail and not + of posting mail; this function is handled by a mail transfer protocol + such as SMTP (RFC 821). A comparison with the DMSP protocol of + PCMAIL can be found at the end of "System Model and Philosophy" + section. + + This protocol assumes a reliable data stream such as provided by TCP + or any similar protocol. When TCP is used, the IMAP server listens + on port 220. When CHAOS is used the IMAP server listens for the + logical contact name "IMAP3". + + Communication in IMAP is defined to be using the ASCII character + interpretation of data. Communication using other conventions may be + possible by the selection of features on some servers. + +System Model and Philosophy + + Electronic mail is a primary means of communication for the widely + spread SUMEX-AIM community. The advent of distributed workstations + is forcing a significant rethinking of the mechanisms employed to + manage such mail. With mainframes, each user tends to receive and + process mail at the computer he used most of the time, his "primary + host". The first inclination of many users when an independent + workstation is placed in front of them is to begin receiving mail at + the workstation, and, in fact, many vendors have implemented + facilities to do this. However, this approach has several + disadvantages: + + (1) Workstations (especially Lisp workstations) have a software + design that gives full control of all aspects of the system + to the user at the console. As a result, background tasks, + + + +Rice [Page 4] + +RFC 1203 IMAP3 February 1991 + + + like receiving mail, could well be kept from running for + long periods of time either because the user is asking to + use all of the machine's resources, or because, in the course + of working, the user has (perhaps accidentally) manipulated + the environment in such a way as to prevent mail reception. + This could lead to repeated failed delivery attempts by + outside agents. + + (2) The hardware failure of a single workstation could keep its + user "off the air" for a considerable time, since repair of + individual workstation units might be delayed. Given the + growing number of workstations spread throughout office + environments, quick repair would not be assured, whereas a + centralized mainframe is generally repaired very soon after + failure. + + (3) It is more difficult to keep track of mailing addresses when + each person is associated with a distinct machine. Consider + the difficulty in keeping track of a large number of postal + addresses or phone numbers, particularly if there was no + single address or phone number for an organization through + which you could reach any person in that organization. + Traditionally, electronic mail on the ARPANET involved + remembering a name and one of several "hosts" (machines) + whose name reflected the organization in which the + individual worked. This was suitable at a time when most + organizations had only one central host. It is less + satisfactory today unless the concept of a host is changed + to refer to an organizational entity and not a particular + machine. + + (4) It is very difficult to keep a multitude of heterogeneous + workstations working properly with complex mailing protocols, + making it difficult to move forward as progress is made in + electronic communication and as new standards emerge. Each + system has to worry about receiving incoming mail, routing + and delivering outgoing mail, formatting, storing, and + providing for the stability of mailboxes over a variety of + possible filing and mailing protocols. + + Consequently, while the workstation may be viewed as an Internet host + in the sense that it implements IP, it should not be viewed as the + entity which contains the user's mailbox. Rather, a mail server + machine (sometimes called a "repository") should hold the mailbox, + and the workstation (hereafter referred to as a "client") should + access the mailbox via mail transactions. Because the mail server + machine would be isolated from direct user manipulation, it could + achieve high software reliability easily, and, as a shared resource, + + + +Rice [Page 5] + +RFC 1203 IMAP3 February 1991 + + + it could achieve high hardware reliability, perhaps through + redundancy. The mail server could be used from arbitrary locations, + allowing users to read mail across campus, town, or country using + more and more commonly available clients. Furthermore, the same user + may access his mailbox from different clients at different times, and + multiple users may access the same mailbox simultaneously. + + The mail server acts an an interface among users, data storage, and + other mailers. The mail access protocol is used to retrieve + messages, access and change properties of messages, and manage + mailboxes. This differs from some approaches (e.g., Unix mail via + NFS) in that the mail access protocol is used for all message + manipulations, isolating the user and the client from all knowledge + of how the data storage is used. This means that the mail server can + utilize the data storage in whatever way is most efficient to + organize the mail in that particular environment, without having to + worry about storage representation compatibility across different + machines. + + In defining a mail access protocol, it is important to keep in mind + that the client and server form a macrosystem, in which it should be + possible to exploit the strong points of both while compensating for + each other's weaknesses. Furthermore, it's desirable to allow for a + growth path beyond the hoary text-only RFC 822 protocol. Unlike + POP2, IMAP3 has extensive features for remote searching and parsing + of messages on the server. For example, a free text search + (optionally in conjunction with other searching) can be made + throughout the entire mailbox by the server and the results made + available to the client without the client having to transfer the + entire mailbox and searching itself. Since remote parsing of a + message into a structured (and standard format) "envelope" is + available, a client can display envelope information and implement + commands such as REPLY without having any understanding of how to + parse RFC 822, etc., headers. + + Additionally, IMAP3 offers several facilities for managing a mailbox + beyond the simple "delete message" functionality of POP2. + + In spite of this, IMAP3 is a relatively simple protocol. Although + servers should implement the full set of IMAP3 functions, a simple + client can be written which uses IMAP3 in much the way as a POP2 + client. + + IMAP3 differs from the DMSP protocol of PCMAIL (RFC 1056) in a more + fundamental manner, reflecting the differing architectures of IMAP + and PCMAIL. PCMAIL is either an online ("interactive mode"), or + offline ("batch mode") system. IMAP is primarily an online system in + which real-time and simultaneous mail access were considered + + + +Rice [Page 6] + +RFC 1203 IMAP3 February 1991 + + + important. + + In PCMAIL, there is a long-term client/server relationship in which + some mailbox state is preserved on the client. There is a + registration of clients used by a particular user, and the client + keeps a set of "descriptors" for each message which summarize the + message. The server and client synchronize their states when the + DMSP connection starts up, and, if a client has not accessed the + server for a while, the client does a complete reset (reload) of its + state from the server. + + In IMAP, the client/server relationship lasts only for the duration + of the IMAP3 connection. All mailbox state is maintained on the + server. There is no registration of clients. The function of a + descriptor is handled by a structured representation of the message + "envelope". This structure makes it unnecessary for a client to know + anything about RFC 822 parsing. There is no synchronization since + the client does not remember state between IMAP3 connections. This + is not a problem since in general the client never needs the entire + state of the mailbox in a single session, therefore there isn't much + overhead in fetching the state information that is needed as it is + needed. + + There are also some functional differences between IMAP3 and DMSP. + DMSP has functions for sending messages, printing messages, and + changing passwords, all of which are done outside of IMAP3. DMSP has + 16 binary flags of which 8 are defined by the system. IMAP has flag + names; there are currently 5 defined system flag names and a facility + for some number (29 in the current implementations) of user flag + names. IMAP3 has a sophisticated message search facility in the + server to identify interesting messages based on dates, addresses, + flag status, or textual contents without compelling the client to + fetch this data for every message. + + It was felt that maintaining state on the client is advantageous only + in those cases where the client is only used by a single user, or if + there is some means on the client to restrict access to another + user's data. It can be a serious disadvantage in an environment in + which multiple users routinely use the same client, the same user + routinely uses different clients, and where there are no access + restrictions on the client. It was also observed that most user mail + access is to a relatively small set of "interesting" messages, which + were either "new" mail or mail based upon some user-selected + criteria. Consequently, IMAP3 was designed to easily identify those + "interesting" messages so that the client could fetch the state of + those messages and not those that were not "interesting". + + One crucial philosophical difference between IMAP and other common + + + +Rice [Page 7] + +RFC 1203 IMAP3 February 1991 + + + mail protocols is that IMAP is a mailbox access protocol, not a + protocol for manipulating mail files. In the IMAP model, unlike + other mail system models in which mail is stored in a linear mail + file, no specification is made for the implementation architecture + for mail storage. Servers may choose to implement mailboxes as files + but this is a detail of which the client can be totally unaware. + + What is more, in the IMAP model, mailboxes are viewed as mappings + from keys into values. There are broadly three types of keys, + generic, canonical and concrete. Generic keys are generic, mail + protocol independent keys defined by IMAP which are meaningful across + multiple mail encoding formats. An example of such a generic key + might be "TO", which would be associated with the "To:" field of an + RFC 822 format message. + + Canonical keys represent the way in which the server can associate + values that are generally "about" a certain key concept, possibly + integrating several mail format specific fields, without having to + worry the client with the particular details of any particular + message format. Thus, the canonical TO key (called $TO) could denote + anything that could reasonably be construed as being directed towards + someone. Hence, in an RFC 822 message the server could find the + union of the "To:", "Resent-To", "Apparently-To:" and "CC:" fields to + be the appropriate value associated with the canonical $TO key. + + Concrete keys allow the client to gain access to certain mail format + specific concepts, that are not pre-specified by the IMAP protocol, + in a well defined manner. For example, If the client asks for the + value associated with the "APPARENTLY-TO" key then, if the message + were to be in RFC 822 format, the server would look for a header + field called "Apparently-To:". If no such field is found or the + field is not implemented or meaningful for the particular message + format then the server will respond with the null value, called NIL, + indicating the non-existence of the field. + + Thus, IMAP servers are at liberty to implement mailboxes as a + relational databases if it seems convenient. Indeed, we anticipate + that future mail systems will tend to use database technology for the + storage and indexing of mailboxes as a result of the pressure caused + by the increasing size of mailboxes. + + Although for historical reasons IMAP is currently somewhat closely + associated with RFC 822, we anticipate that future developments in + IMAP will remove these mail format specific components and will move + towards the generic model mentioned above. This will allow IMAP more + easily to incorporate such things as multi-media mail. + + + + + +Rice [Page 8] + +RFC 1203 IMAP3 February 1991 + + +The Protocol + + The IMAP3 protocol consists of a sequence of client commands and + server responses to those commands, with extra information from the + server data being sent asynchronously to and independent to the + responses to client commands. Unlike most Internet protocols, + commands and responses are tagged. That is, a command begins with a + unique identifier (typically a short alphanumeric sequence such as a + Lisp "gensym" function would generate e.g., A0001, A0002, etc.), + called a tag. The response to this command is given the same tag + from the server. + + We distinguish between data sent by the server as the result of a + client request, which we term "SOLICITED" and data sent by the server + not as the result of a client request, which we term "UNSOLICITED". + The server may send unsolicited data at any time that would not + fragment another piece of data on the same stream rendering it + unintelligible. The server is contractually required, however, to + return all data that is solicited by the client before the return of + the completion signal for that command, i.e., all solicited data must + be returned within the temporal extent of the request/completion + acknowledgement wrapper. This does not, however, preclude the + simultaneous processing of multiple requests by the client, it simply + requires that the client be confident that it has all the requested + data when a request finishes. This allows the implementation of both + synchronous and asynchronous clients. + + Solicited data is identified by the tag of the initial request by the + client. Unsolicited data is identified by the special reserved tag + of "*". There is another special reserved tag, "+", discussed below. + + Note: the tagging of SOLICITED data is only permitted for a selected + server version other than 2.0. + + No assumptions concerning serial or monolithic processing by the + server can be made by a correct client. The server is at liberty to + process multiple requests by the same client in any order. This + allows servers to process costly searches over mailboxes on slow + backing storage media in the background, while still preserving + interactive performance. Clients can, however, assume the + serialization of the request/data/completion behavior mentioned + above. + + When a connection is opened the server sends an unsolicited OK + response as a greeting message and then waits for commands. When + commands are received the server acts on them and responds with + responses, often interspersed with data. + + + + +Rice [Page 9] + +RFC 1203 IMAP3 February 1991 + + + The client opens a connection, waits for the greeting, then sends a + LOGIN command with user name and password arguments to establish + authorization. Following an OK response from the server, the client + then sends a SELECT command to access the desired mailbox. The + user's default mailbox has a special reserved name of "INBOX" which + is independent of the operating system that the server is implemented + on. The server will generally send a list of valid flags, number of + messages, and number of messages arrived since last access for this + mailbox as solicited data, followed by an OK response. The client + may terminate access to this mailbox and access a different one with + another SELECT command. + + Because the SELECT command affects the state of the server in a + fundamental way, the server is required to process all outstanding + commands for any given mailbox before sending the OK tag for the + SELECT command. Thus, the client will always know that all responses + before an OK SELECT response will refer to the old mailbox and all + responses following it will apply to the new mailbox. + + Because, in the real world, local needs or experimental work will + dictate that servers will support both supersets of the defined + behavior and incompatible changes, servers will support a + SELECT.VERSION command and a SELECT.FEATURES command, the purpose of + which is to allow clients to select the overall behavior and specific + features that they want from a server. The default behavior of any + server is to process commands and to have interaction syntax the same + as is specified by IMAP2 in RFC 1064. A server may not behave in any + other manner unless the SELECT.VERSION or SELECT.FEATURES commands + are used to select different behavior. + + Over time, when groups of generally useful changes to the current, + default behavior of the server are found, these will be collected + together and incorporated in such a way that all of the features can + be selected simply by selecting a particular major version number of + the protocol. It should be noted that the version numbers (both + major and minor) selected by the SELECT.VERSION command denote + versions of the IMAP protocol, not versions of the server per se. + Thus, although in general changes to the protocol specification will + be made in such a way that they are upwards compatible, this cannot + be guaranteed. No client should rely on tests of the form "if + major_version > 2 then..." being valid for all protocol versions, + since incompatible changes might be made in the future. + + The client reads mailbox information by means of FETCH commands. The + actual data is transmitted via the solicited data mechanism (that is, + FETCH should be viewed as poking the server to include the desired + data along with any other data it wishes to transmit to the client). + There are three major categories of data which may be fetched. + + + +Rice [Page 10] + +RFC 1203 IMAP3 February 1991 + + + The first category is that data which is associated with a message as + an entity in the mailbox. There are presently three such items of + data: the "internal date", the "RFC 822 size", and the "flags". The + internal date is the date and time that the message was placed in the + mailbox. The RFC 822 size is subject to deletion in the future; it + is the size in bytes of the message, expressed as an RFC 822 text + string. Current clients only use it as part of a status display + line. The flags are a list of status flags associated with the + message (see below). All of the first category data can be fetched + by using the macro-fetch word "FAST"; that is, "FAST" expands to + "(FLAGS INTERNALDATE RFC822.SIZE)". + + The second category is that data which describes the composition and + delivery information of a message; that is, information such as the + message sender, recipient lists, message-ID, subject, etc. This is + the information which is stored in the message header in RFC 822 + format message and is traditionally called the "envelope". [Note: + this should not be confused with the SMTP (RFC 821) envelope, which + is strictly limited to delivery information.] IMAP3 defines a + structured and unambiguous representation for the envelope which is + particularly nice for Lisp-based parsers. A client can use the + envelope for operations such as replying and not worry about RFC 822 + at all. Envelopes are discussed in more detail below. The first and + second category data can be fetched together by using the macro-fetch + word "ALL"; that is, "ALL" expands to "(FLAGS INTERNALDATE + RFC822.SIZE ENVELOPE)". + + The third category is that data which is intended for direct human + viewing. The present RFC 822 based IMAP3 defines three such items: + RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the two + former appended together in a single text string). Fetching "RFC822" + is equivalent to typing the RFC 822 representation of the message as + stored on the mailbox without any filtering or processing. + + Typically, a client will "FETCH ALL" for some or all of the messages + in the mailbox for use as a presentation menu, and when the user + wishes to read a particular message will "FETCH RFC822.TEXT" to get + the message body. A more primitive client could, of course, simply + "FETCH RFC822" a la POP2-type functionality. + + The client can alter certain data by means of a STORE command. As an + example, a message is deleted from a mailbox by a STORE command which + includes the \DELETED flag as one of the flags being set. + + Other client operations include copying a message to another mailbox + (COPY command), permanently removing deleted messages (EXPUNGE + command), checking for new messages (CHECK command), and searching + for messages which match certain criteria (SEARCH command). + + + +Rice [Page 11] + +RFC 1203 IMAP3 February 1991 + + + The client terminates the session with the LOGOUT command. The + server returns a "BYE" followed by an "OK". + +A Typical Scenario + + Client Server + ------ ------ + {Wait for Connection} + {Open Connection} --> + <-- * OK IMAP3 Server Ready + {Wait for command} + A001 SUPPORTED.VERSIONS --> + <-- * SUPPORTED.VERSIONS ((2 0 ) + (3 0 EIGHT.BIT.TRANSPARENT + AUTO.SET.SEEN + TAGGED.SOLICITED)) + A001 OK Supported Versions returned. + {Wait for command} + A002 SELECT.VERSION (3 0) --> + <-- A002 OK Version 3.0 Selected. + {Wait for command} + A002 SELECT.FEATURES TAGGED.SOLICITED --> + <-- A002 OK Features selected. + {Wait for command} + A003 LOGIN Fred Secret --> + <-- A003 OK User Fred logged in + {Wait for command} + A004 SELECT INBOX --> + <-- A004 FLAGS (Meeting Notice \Answered + \Flagged \Deleted \Seen) + <-- A004 19 EXISTS + <-- A004 2 RECENT + <-- A004 OK Select complete + {Wait for command} + A005 FETCH 1:19 ALL --> + <-- A005 1 Fetch (......) + ... + <-- A005 18 Fetch (......) + <-- A005 19 Fetch (......) + <-- A005 OK Fetch complete + {Wait for command} + A006 FETCH 8 RFC822.TEXT --> + <-- A006 8 Fetch (RFC822.TEXT {893} + ...893 characters of text... + <-- ) + <-- A006 OK Fetch complete + {Wait for command} + + + + +Rice [Page 12] + +RFC 1203 IMAP3 February 1991 + + + A007 STORE 8 +Flags \Deleted --> + <-- A007 8 Store (Flags (\Deleted + \Seen)) + <-- A007 OK Store complete + {Wait for command} + A008 EXPUNGE --> + <-- A008 19 EXISTS + <-- A008 8 EXPUNGE + <-- A008 18 EXISTS + <-- A008 Expunge complete + {Wait for command} + A009 LOGOUT --> + <-- A009 BYE IMAP3 server quitting + <-- A009 OK Logout complete + {Close Connection} --><-- {Close connection} + {Go back to start} + + A more complex scenario produced by a pipelining multiprocess client. + + Client Server + ------ ------ + {Wait for Connection} + {Open session as above} + <-- A004 19 EXISTS + <-- A004 2 RECENT + <-- A004 OK Select complete + {Wait for command} + A005 SEARCH RECENT --> + <-- A005 SEARCH (18 19) (RECENT) + <---A005 OK Search complete + A006 FETCH 18:19 ALL RFC822.TEXT + A007 STORE 18:19 +FLAGS (\SEEN) + A008 FETCH 1:17 ALL --> + <-- A006 18 Fetch (... RFC822.TEXT ...) + A009 STORE 18 +FLAGS (\DELETED) + <-- A006 19 Fetch (... RFC822.TEXT ...) + <-- A006 OK Fetch complete + <-- A007 18 STORE (Flags (\Seen)) + A010 STORE 19 +FLAGS (\DELETED) + <-- A007 19 STORE (Flags (\Seen)) + <-- A007 OK Store complete + <-- A008 1 Fetch (......) + ... + <-- A008 16 Fetch (......) + <-- A008 17 Fetch (......) + <-- A008 OK Fetch complete + <-- A009 18 STORE (Flags (\Seen + \Deleted)) + + + +Rice [Page 13] + +RFC 1203 IMAP3 February 1991 + + + <-- A009 OK Store complete + <-- A010 19 STORE (Flags (\Seen + \Deleted)) + <-- A010 OK Store complete + {Wait for command} + <-- * EXISTS 23 + <-- * RECENT 4 + <-- * SEARCH (20 21 22 23) (RECENT) + A011 FETCH 20:23 ALL RFC822.TEXT + +Conventions + + The following terms are used in a meta-sense in the syntax + specification below: + + An ASCII-STRING is a sequence of arbitrary ASCII characters. + + An ATOM is a sequence of ASCII characters delimited by SP or CRLF. + + A CHARACTER is any ASCII character except """", "{", CR, LF, "%", + or "\". + + A CRLF is an ASCII carriage-return character followed immediately + by an ASCII linefeed character. + + A NUMBER is a sequence of the ASCII characters which represent + decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or + ":". + + A SP is the ASCII space character. + + A TEXT_LINE is a human-readable sequence of ASCII characters up to + but not including a terminating CRLF. + + One of the most common fields in the IMAP3 protocol is a STRING, + which may be an ATOM, QUOTED-STRING (a sequence of CHARACTERs inside + double-quotes), or a LITERAL. A literal consists of an open brace + ("{"), a number, a close brace ("}"), a CRLF, and then an ASCII- + STRING of n characters, where n is the value of the number inside the + brace. In general, a string should be represented as an ATOM or + QUOTED-STRING if at all possible. The semantics for QUOTED-STRING or + LITERAL are checked before those for ATOM; therefore an ATOM used in + a STRING may only contain CHARACTERs. Literals are most often sent + from the server to the client; in the rare case of a client to server + literal there is a special consideration (see the "+ text" response + below). + + Another important field is the SEQUENCE, which identifies a set of + + + +Rice [Page 14] + +RFC 1203 IMAP3 February 1991 + + + messages by consecutive numbers from 1 to n where n is the number of + messages in the mailbox. A sequence may consist of a single number, + a pair of numbers delimited by colon indicating all numbers between + those two numbers, or a list of single numbers and/or number pairs. + For example, the sequence 2,4:7,9,12:15 is equivalent to + 2,4,5,6,7,9,12,13,14,15 and identifies all of those messages. + +Definitions of Commands and Responses + + Summary of Commands and Responses + +Commands: + tag NOOP + tag LOGIN user password + tag LOGOUT + tag SELECT mailbox + tag CHECK + tag EXPUNGE + tag COPY sequence mailbox + tag FETCH sequence data + tag STORE sequence data value + tag SEARCH criteria + tag BBOARD bboard + tag FIND (BBOARDS / MAILBOXES) pattern + tag READONLY + tag READWRITE + tag SELECT.VERSION (major_version minor_version) + tag SELECT.FEATURES features + tag SUPPORTED.VERSIONS + tag FLAGS + tag SET.FLAGS + +Responses (can be either solicited or unsolicited): + */tag FLAGS flag_list + */tag SEARCH (numbers) (criteria) + */tag EXISTS + */tag RECENT + */tag EXPUNGE + */tag STORE data + */tag FETCH data + */tag BBOARD bboard_name + */tag MAILBOX non_inbox_mailbox_name + */tag SUPPORTED.VERSIONS version_data + */tag READONLY + */tag READWRITE + */tag OK text + */tag NO text + */tag BAD text + + + +Rice [Page 15] + +RFC 1203 IMAP3 February 1991 + + + */tag BYE text + +Responses (can only be solicited): + tag COPY message_number + +Responses (can only be unsolicited): + + text + +Commands + + tag NOOP + + The NOOP command returns an OK to the client. By itself, it does + nothing, but certain things may happen as side effects. For + example, server implementations which implicitly check the mailbox + for new mail may do so as a result of this command. The primary + use of this command is to for the client to see if the server is + still alive (and notify the server that the client is still alive, + for those servers which have inactivity autologout timers). + + tag LOGIN user password + + The LOGIN command identifies the user to the server and carries + the password authenticating this user. This information is used + by the server to control access to the mailboxes. + + EXAMPLE: A001 LOGIN SMITH SESAME logs in as user SMITH with + password SESAME. + + tag LOGOUT + + The LOGOUT command indicates the client is done with the session. + The server sends a solicited BYE response before the (tagged) OK + response, and then closes the connection. + + tag SELECT mailbox + + The SELECT command selects a particular mailbox. The server must + check that the user is permitted read access to this mailbox. + Prior to returning an OK to the client, the server must send an + solicited FLAGS and EXISTS response to the client giving the + flags list for this mailbox (simply the system flags if this + mailbox doesn't have any special flags) and the number of messages + in the mailbox. It is also recommended that the server send a + RECENT unsolicited response to the client for the benefit of + clients which make use of the number of new messages in a mailbox. + It is further recommended that servers should send an unsolicited + READONLY message if the mailbox that has been selected is not + + + +Rice [Page 16] + +RFC 1203 IMAP3 February 1991 + + + writable by the user. + + Multiple SELECT commands are permitted in a session, in which case + the prior mailbox is deselected first. + + The default mailbox for the SELECT command is INBOX, which is a + special name reserved to mean "the primary mailbox for this user + on this server". The format of other mailbox names is operating + system dependent (as of this writing, it reflects the path of the + mailbox on the current servers), though it could reflect any + server-specific naming convention for the namespace of mailboxes. + Such a namespace need not and should not be viewed as being + equivalent or linked to the server machine's file system. + + EXAMPLES: A002 SELECT INBOX ;; selects the default mailbox. + A002 197 EXISTS ;; server says 197 messages in INBOX + A002 5 RECENT ;; server says 5 are recent. + A002 OK Select complete. + or + A003 SELECT /usr/fred/my-mail.txt + ;; select a different user specified mailbox. + ... + + tag CHECK + + The CHECK command forces a check for new messages and a rescan of + the mailbox for internal change for those implementations which + allow multiple simultaneous read/write access to the same mailbox + (e.g., TOPS-20). It is recommend that periodic implicit checks + for new mail be done by servers as well. The server must send a + solicited EXISTS response prior to returning an OK to the + client. + + tag EXPUNGE + + The EXPUNGE command permanently removes all messages with the + \DELETED flag set in its flags from the mailbox. Prior to + returning an OK to the client, for each message which is removed, + a solicited EXPUNGE response is sent indicating which message + was removed. The message number of each subsequent message in the + mailbox is immediately decremented by 1; this means that if the + last 5 messages in a 9-message mailbox are expunged you will + receive 5 "5 EXPUNGE" responses for message 5. To ensure mailbox + integrity and server/client synchronization, it is recommended + that the server do an implicit check prior to commencing the + expunge and again when the expunge is completed. Furthermore, if + the server allows multiple simultaneous access to the same mailbox + the server must guarantee both the integrity of the mailbox and + + + +Rice [Page 17] + +RFC 1203 IMAP3 February 1991 + + + the views of it held by the clients. + + EXPUNGE is not allowed if the user does not have write access to + this mailbox. If a user does not have write access to the mailbox + then the server is required to signal this fact by replying with a + NO response with a suitable text string that can be presented to + the user explaining that the mailbox is read-only. It is further + recommended that servers send an unsolicited READONLY message to + clients that attempt an expunge operation on a read only mailbox. + + tag COPY sequence mailbox + + The COPY command copies the specified message(s) to the specified + destination mailbox. If the destination mailbox does not exist, + the server should create it. Prior to returning an OK to the + client, the server must return a solicited COPY response for + each message copied. + + EXAMPLE: A003 COPY 2:4 MEETING copies messages 2, 3, and 4 to + mailbox "MEETING". + + COPY is not allowed if the user does not have write access to the + destination mailbox. If a user does not have write access to the + destination mailbox then the server is required to signal this + fact by replying with a NO response with a suitable text string + that can be presented to the user explaining that the mailbox is + read-only. It is further recommended that servers send an + unsolicited READONLY message to clients that attempt to copy to a + read only mailbox. IMAP3 does not specify "where" the message + will be put in the mailbox to which it has been copied. + + tag FETCH sequence fetch_att + + The FETCH command retrieves data associated with a message in the + mailbox. The data items to be fetched may be either a single atom + or an S-expression list. The attributes that can be fetched are + any of those mentioned specifically below along with any generic, + canonical or concrete key. The set of predefined generic keys is: + {BCC, BODY, CC, FROM, HEADER, SIZE, SUBJECT, TEXT, TO}. The set + of predefined canonical keys is {$CC, $FROM, $SUBJECT, $TO}. The + value returned by the server for a non-existent or non-meaningful + key is defined to be the null value, NIL. + + ALL Equivalent to: + (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE) + + ENVELOPE The envelope of the message. The envelope is + computed by the server by parsing the header, + + + +Rice [Page 18] + +RFC 1203 IMAP3 February 1991 + + + i.e., the RFC 822 header for an RFC822 format + message, into the component parts, defaulting + various fields as necessary. + + FAST Macro equivalent to: + (FLAGS INTERNALDATE RFC822.SIZE) + + FLAGS The flags which are set for this message. + This may include the following system flags: + + \RECENT Message arrived since + last read of this mailbox + \SEEN Message has been read + \ANSWERED Message has been answered + \FLAGGED Message is "flagged" for + urgent/special attention + \DELETED Message is "deleted" for + removal by later EXPUNGE + + INTERNALDATE The date and time the message was written to + the mailbox. + + RFC822 The message in RFC 822 format. + + RFC822.HEADER The RFC 822 format header of the message. + + RFC822.SIZE The number of characters in the message as + expressed in RFC 822 format. + + RFC822.TEXT The text body of the message, omitting the + RFC 822 header. + + EXAMPLES: + + A003 FETCH 2:4 ALL + fetches the flags, internal date, RFC 822 size, and envelope + for messages 2, 3, and 4. + + A004 FETCH 3 RFC822 + fetches the RFC 822 representation for message 3. + + A005 FETCH 4 (FLAGS RFC822.HEADER) + fetches the flags and RFC 822 format header for message 4. + + A006 FETCH 42 $SUBJECT + A006 FETCH $SUBJECT "Some subject text..." + A006 OK FETCH completed ok. + fetches the canonical subject field. + + + +Rice [Page 19] + +RFC 1203 IMAP3 February 1991 + + + A007 FETCH 42 APPARENTLY-TO + A007 FETCH APPARENTLY-TO NIL + A007 OK FETCH found no value. + fetches the concrete apparently-to field. + + tag STORE sequence data value + + The STORE command alters the values associated with particular + keys for a message in the mailbox. As is the case for the FETCH + command, any generic, canonical or concrete key may be used to + index the value provided. In addition to these, the following + pre-defined keys are provided. + + FLAGS Replace the flags for the message with the + argument (in flag list format). + The server must respond with a solicited STORE FLAGS + message, showing the new state of the flags after + the store. + + +FLAGS Add the flags in the argument to the + message's flag list. + The server must respond with a solicited STORE FLAGS + message, showing the new state of the flags after + the store. + + -FLAGS Remove the flags in the argument from the + message's flag list. + The server must respond with a solicited STORE FLAGS + message, showing the new state of the flags after + the store. + + RFC822.HEADER Replace the header of the message(s) with that + specified. This allows users to use their mailboxes + as databases with header fields as keys. + The server must respond with solicited + STORE RFC822.HEADER, STORE RFC822.SIZE and + STORE ENVELOPE messages, showing the new state + of the reparsed header after the store. + + RFC822.TEXT Replace the body of the messages with that specified. + The server must respond with solicited + STORE RFC822.TEXT and STORE RFC822.SIZE messages, + showing the new state of the message after the store. + + STORE is not allowed if the user does not have write access to + this mailbox. + + The server is required to send a solicited STORE response for + + + +Rice [Page 20] + +RFC 1203 IMAP3 February 1991 + + + each store operation that results in a format transformation by + the server. For example, the server is required to send a + STORE FLAGS response when the client performs a STORE +FLAGS or + a STORE -FLAGS, since the client may not easily be able to know + what the result of this command will be. Similarly, if the + client emits a STORE FROM command then the server should + respond with a suitable STORE FROM response because the client + would be sending a string value to be stored and the server + should transform this into a set of addresses. In general, + however, although it is legal for the server to send a + solicited STORE response for each STORE operation, this is + discouraged, since it might result in the retransmission of + very large and unnecessary amounts of data that have been + stored. + + EXAMPLE: A003 STORE 2:4 +FLAGS (\DELETED) marks messages 2, 3, + and 4 for deletion. + + tag SEARCH search_criteria + + The SEARCH command searches the mailbox for messages which match + the given set of criteria. The server response SEARCH (criteria) + (numbers) gives the set of messages which match the conjunction of + the criteria specified. In addition to each of the search + criteria there is its logical inverse. The logical inverse + criterion is denoted by the ~ (tilda) sign. + + Thus, no message that matches the criterion: + FROM crispin + + will match the criterion: + ~FROM crispin + + The criteria for the search can be any generic, canonical or + concrete key. In addition to these, the following pre-defined + keys are also provided: + + ALL All messages in the mailbox; the default + initial criterion for ANDing. + + ANSWERED Messages with the \ANSWERED flag set. + + BCC string Messages which contain the specified string + in the envelope's BCC field. + + BEFORE date Messages whose internal date is earlier than + the specified date. + + + + +Rice [Page 21] + +RFC 1203 IMAP3 February 1991 + + + BODY string Messages which contain the specified string + in the body of the message. + + CC string Messages which contain the specified string + in the envelope's CC field. + + DELETED Messages with the \DELETED flag set. + + FLAGGED Messages with the \FLAGGED flag set. + + FROM string Messages which contain the specified string + in the envelope's FROM field. + + HEADER string Messages which contain the specified string + in the message header. + + KEYWORD flag Messages with the specified flag set. + + NEW Messages which have the \RECENT flag set but + not the \SEEN flag. This is functionally + equivalent to "RECENT UNSEEN". + + OLD Messages which do not have the \RECENT flag + set. + + ON date Messages whose internal date is the same as + the specified date. + + RECENT Messages which have the \RECENT flag set. + + SEEN Messages which have the \SEEN flag set. + + SINCE date Messages whose internal date is later than + the specified date. + + SUBJECT string Messages which contain the specified string + in the envelope's SUBJECT field. + + TEXT string Messages which contain the specified string. + + TO string Messages which contain the specified string in + the envelope's TO field. + + EXAMPLE: A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87 + returns the message numbers for all deleted messages from Smith + that were placed in the mailbox since October 1, 1987. + + Implementation note: The UNANSWERED, UNDELETED, UNFLAGGED, + + + +Rice [Page 22] + +RFC 1203 IMAP3 February 1991 + + + UNKEYWORD and UNSEEN criteria, described below, are preserved in + IMAP3 for IMAP2 compatibility. They are, however, considered + obsolete and new Client programs are encouraged to use the ~ + notation for the logical inverses of search criteria with a view + to the dropping of this outmoded syntax in later versions. + + UNANSWERED Messages which do not have the \ANSWERED flag + set. + + UNDELETED Messages which do not have the \DELETED flag + set. + + UNFLAGGED Messages which do not have the \FLAGGED flag + set. + + UNKEYWORD flag Messages which do not have the specified flag + set. + + UNSEEN Messages which do not have the \SEEN flag set. + + tag READONLY + + The READONLY command indicates that the client wishes to make the + mailbox read-only. The server is required to reply with a + solicited READONLY or READWRITE response. + + tag READWRITE + + The READWRITE command indicates that the client wishes to make the + mailbox read-write. The server is required to reply with a + solicited READONLY or READWRITE response. + + tag SUPPORTED.VERSIONS + + The SUPPORTED.VERSIONS solicits from the server a + SUPPORTED.VERSIONS message, which encapsulates information about + which versions and features the server supports. + + tag SELECT.VERSION (major_version minor_version) + + The SELECT.VERSION command indicates that the client wishes to + select certain behavior on the part of the server. The major and + minor versions indicate the specific version of the protocol being + selected. + + EXAMPLE: A002 SELECT.VERSION (3 0) + + A client may not request a server version that is not supported by + + + +Rice [Page 23] + +RFC 1203 IMAP3 February 1991 + + + the server, i.e., which is specifically mentioned in the response + to a SUPPORTED.VERSIONS command. An attempt to do so by a client + will result in a NO response from the server. It is an error for + the SELECT.VERSION command to be used after a mailbox has been + selected. The rationale for this is that for some server + implementations it might be necessary to spawn separate programs + to implement widely divergent protocol versions. Thus, the client + cannot be allowed to expect any server state to be preserved after + the use of the SELECT.VERSION command. The default version of all + servers is 2.0, i.e., IMAP2 as defined by RFC 1064. + + tag SELECT.FEATURES 1#features + + The SELECT.FEATURES command indicates that the client wishes to + select certain specific features on the part of the server. A + client may not request a feature that is not supported by the + server, i.e., one that is explicitly mentioned in the set of + features for the selected version returned by the + SUPPORTED.VERSIONS command. An attempt to do so by a client will + result in a NO response from the server. + + EXAMPLE: A002 SELECT.FEATURES AUTO.SET.SEEN ~TAGGED.SOLICITED + EIGHT.BIT.TRANSPARENT + + i.e., select the set of features called AUTO.SET.SEEN and + EIGHT.BIT.TRANSPARENT and deselect the feature called + TAGGED.SOLICITED. The use of the SELECT.FEATURES command + completely resets the set of selected features. Note: These are + only example feature names and are not necessarily supported by + any server. See the appendix on features for more information on + features. Note: Some features, when present in the server, will + cause the upwards compatible extension of the grammar, i.e., by + adding extra commands. The server is at liberty not to remove + these upwards compatible extensions to the command tables when a + feature is disabled. Thus, it is an error for a client to rely on + getting a NO or BAD response in any way, for instance to determine + the selectedness or presence of a feature. + + tag BBOARD bboard + + The BBOARD command is equivalent to SELECT, except that its + argument is a bulletin board (BBoard) name. The format of a + BBoard name is implementation specific, although it is strongly + encouraged to use something that resembles a name in a generic + sense and not a file or mailbox name on the particular system. + There is no requirement that a BBoard name be a mailbox name or a + file name (in particular, Unix netnews has a completely different + namespace from mailbox or file names). + + + +Rice [Page 24] + +RFC 1203 IMAP3 February 1991 + + + The result from the BBOARD command is identical from that of the + SELECT command. For example, in the TOPS-20 server + implementation, the command + A0002 BBOARD FOO + is exactly equivalent to the command + A0002 SELECT POBOX:FOO.TXT + Note: the equivalence in this example is *not* required by the + protocol, and merely reflects the fuzzy distinction between + mailboxes and BBoards on TOPS-20. + + tag FIND (BBOARDS / MAILBOXES) pattern + + The FIND command accepts as arguments the keywords BBOARDS or + MAILBOXES and a pattern which specifies some set of BBoard/mailbox + names which are usable by the BBOARD/SELECT command. Two wildcard + characters are defined; "*" specifies that any number (including + zero) characters may match at this position and "%" specifies that + a single character may match at this position. For example, + FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR, whereas + FOO%BAR will match only FOO.BAR; furthermore, "*" will match all + BBoards/mailboxes. The following quoting convention applies to + wildcards: "\*" is the literal "*" character, "\%" is the literal + "%" character and "\\" is the literal "\" character. Notes: The + format of mailboxes is server implementation dependent. The + special mailbox name INBOX is not included in the output to the + FIND MAILBOXES command. + + The FIND command solicits any number of BBOARD or MAILBOX + responses from the server as appropriate. + + Examples: + A0002 FIND BBOARDS * + A0002 BBOARD FOOBAR + A0002 BBOARD GENERAL + A0002 OK FIND completed + or + A0002 FIND MAILBOXES FOO%BA* + A0002 MAILBOX FOO.BAR + A0002 MAILBOX FOO.BAZZAR + A0002 OK FIND completed + + Note: Although the use of explicit file or path names for + mailboxes is discouraged by this standard, it may be unavoidable. + It is important that the value returned in the MAILBOX solicited + reply be usable in the SELECT command without remembering any path + specification which may have been used in the FIND MAILBOXES + pattern. + + + + +Rice [Page 25] + +RFC 1203 IMAP3 February 1991 + + + tag FLAGS + + The FLAGS command solicits a FLAGS response from the server. + + tag SET.FLAGS flag_list + + The SET.FLAGS command defines the user specifiable flags for this + mailbox, i.e., the keywords. If this set does not include flags + formerly sent to the client by the server in a FLAGS message then + this constitutes a request to delete the flag. Any new flags + should be created. This command does not affect the system + defined flags and any system flags that are included in the + flag_list will be ignored. The server must respond to this + command with a solicited FLAGS message. If the deletion of a flag + results in the invalidation of the flag sets of any messages then + the server is required to send solicited STORE FLAGS messages to + the client for each modified message. + +Responses: + + */tag OK text + + In its solicited form this response identifies successful + completion of the command with the indicated tag. The text is a + line of human-readable text which may be useful in a protocol + telemetry log for debugging purposes. + + In its unsolicited form, this response indicates simply that the + server is alive. No special action on the part of the client is + called for. This is presently only used by servers at startup as + a greeting message indicating that they are ready to accept the + first command. This usage, although legal, is by no means + required. The text is a line of human-readable text which may be + logged in protocol telemetry. + + */tag NO text + + In its solicited form this response identifies unsuccessful + completion of the command with the indicated tag. The text is a + line of human-readable text which probably should be displayed to + the user in an error report by the client. + + In its unsolicited form this response indicates some operational + error at the server which cannot be traced to any protocol + command. The text is a line of human-readable text which should + be logged in protocol telemetry for the maintainer of the server + and/or the client. + + + + +Rice [Page 26] + +RFC 1203 IMAP3 February 1991 + + + */tag BAD text + + In its solicited form response indicates faulty protocol received + from the client and indicates a bug. The text is a line of + human-readable text which should be recorded in any telemetry as + part of a bug report to the maintainer of the client. + + In its unsolicited form response indicates some protocol error at + the server which cannot be traced to any protocol command. The + text is a line of human-readable text which should be logged in + protocol telemetry for the maintainer of the server and/or the + client. This generally indicates a protocol synchronization + problem, and examination of the protocol telemetry is advised to + determine the cause of the problem. + + */tag BYE text + + This indicates that the server is about to close the connection. + The text is a line of human-readable text which should be + displayed to the user in a status report by the client. IMAP2 + requires that the server emit a solicited BYE response as part of + a normal logout sequence. This solicited form is not required + under IMAP3, though is still legal for compatibility. In its + unsolicited form the BYE response is used as a panic shutdown + announcement by the server. It is required to be used by any + server which performs autologouts due to inactivity. + + */tag number message_data + + The solicited (tag number message_data) response is generated as + the result of a number of client requests. The server may also + emit any the following at any time as unsolicited data (i.e., * + number message_data). The message_data is one of the following: + + EXISTS The specified number of messages exists in the mailbox. + + RECENT The specified number of messages have arrived since the + last time this mailbox was selected with the SELECT + command or equivalent. + + EXPUNGE The specified message number has been permanently + removed from the mailbox, and the next message in the + mailbox (if any) becomes that message number. + The server must send a solicited EXPUNGE response + for each message that it expunges as the result + of an EXPUNGE command. Note: future versions of the + protocol may allow the use of a message sequence + as a value returned by the EXPUNGE response to allow the + + + +Rice [Page 27] + +RFC 1203 IMAP3 February 1991 + + + more efficient compaction of client representations of + mailboxes. + + STORE data + Functionally equivalent to FETCH, only it is sent by the + server when the state of a mailbox changes. The server + must send solicited STORE responses as the result of + any change caused by a STORE command. + + FETCH data + This is the principle means by which data about a + message is sent to the client. The data is in a + Lisp-like S-expression property list form. Just as the + FETCH request from the client can fetch any generic, + canonical or concrete key, so also the FETCH response + can return values for any of these keys as well as for + the pre-defined attributes mentioned below. Note that + the server is permitted to send any unsolicited FETCH + or STORE messages that it should choose, be they the + values associated with generic, canonical or concrete + keys. Clients are required to ignore any such + FETCH responses that it cannot interpret. For example, + clients are not required to be able to understand, i.e., + use fruitfully, the canonical $TO key, but they are + required to be able to ignore an unsolicited $TO message + correctly. + + ENVELOPE An S-expression format list which describes the + envelope of a message. The envelope is computed + by the server by parsing the RFC 822 header into + the component parts, defaulting various fields + as necessary. + + The fields of the envelope are in the following + order: date, subject, from, sender, reply-to, to, + cc, bcc, in-reply-to, and message-id. The date, + subject, in-reply-to, and message-id fields are + strings. The from, sender, reply-to, to, cc, + and bcc fields are lists of addresses. + + An address is an S-expression format list which + describes an electronic mail address. The fields + of an address are in the following order: + personal name, source-route (i.e., the + at-domain-list in SMTP), mailbox name, host name + and comments. Implementation note: The addition + of the comment field is an incompatible extension + from IMAP2. The server is required not to provide + + + +Rice [Page 28] + +RFC 1203 IMAP3 February 1991 + + + this field when running in IMAP2 mode. + + Any field of an envelope or address which is + not applicable is presented as the atom NIL. + Note that the server must default the reply-to + and sender fields from the from field; a client is + not expected to know to do this. + + FLAGS An S-expression format list of flags which are set + for this message. This may include the following + system flags: + + \RECENT Message arrived since last + read of this mailbox + \SEEN Message has been read + \ANSWERED Message has been answered + \FLAGGED Message is "flagged" for + urgent/special attention + \DELETED Message is "deleted" for + removal by later EXPUNGE + + INTERNALDATE A string containing the date and time the + message was written to the mailbox. + + RFC822 A string expressing the message in RFC 822 + format. + Note: Some implementations of IMAP2 servers + had the (undocumented) behavior of setting + the \SEEN flag as a side effect of fetching + the body of a message. This resulted in + erroneous behavior for clients that prefetch + messages that the user might not get + around to reading. Thus, this behavior is + explicitly disallowed in IMAP3. + Note: this is not a significant performance + restriction because it is always possible for + IMAP3 clients to use an interaction with the + server of the following type: + A001 FETCH 42 RFC822 + A002 STORE 42 +FLAGS (\SEEN) + A001 42 FETCH RFC822 {637} ...... + A001 OK Fetch completed + A002 42 STORE FLAGS (\SEEN \FLAGGED...) + A002 OK Store Completed. + + RFC822.HEADER A string expressing the RFC 822 format + header of the message + + + + +Rice [Page 29] + +RFC 1203 IMAP3 February 1991 + + + RFC822.SIZE A number indicating the number of + characters in the message as expressed + in RFC 822 format. + + RFC822.TEXT A string expressing the text body of the + message, omitting the RFC 822 header. + See also note for RFC822. + + */tag FLAGS flag_list + + A solicited FLAGS response must occur as a result of a SELECT + command. The flag list is the list of flags (at a minimum, the + IMAP defined flags) which are applicable for this mailbox. Flags + other than the system flags are a function of the server + implementation. + + */tag SEARCH (numbers) (search_criteria) + + This response occurs as a result of a SEARCH command. The + number(s) refer to those messages which match the search criteria. + In its solicited form this message allows clients to find + interesting groups of messages, e.g., unseen messages from + Crispin. In its unsolicited form it allows the server to inform + the client of interesting patterns, e.g., when new mail arrives, + recent and from Crispin. Compatibility note: The search_criteria + are sent by the server along with the matching numbers so + unsolicited SEARCH messages may be interpreted. This syntax is + not upwards compatible with IMAP2 and so the new syntax is + intended to make it simple for clients that are not able to take + advantage of unsolicited SEARCH messages still to interpret + solicited SEARCH messages simply by ignoring everything that + follows the list of numbers with minimal parsing. Such clients + may not, however, simply discard the rest of the line because + there might be LITERALs in the search pattern. + + Examples: + A00042 SEARCH (2 3 6) (FROM Crispin ~SEEN) + and + * SEARCH (42) (FROM Crispin RECENT) + + */tag READONLY + + This indicates that the mailbox is read-only. The server is + required to respond to a READONLY or READWRITE command with either + a solicited READONLY or a solicited READWRITE response. Note: If + the client attempts a mutation operation, such as STORE, on a + mailbox to which it does not have write access then the server is + required to reply with a solicited READONLY response on the first + + + +Rice [Page 30] + +RFC 1203 IMAP3 February 1991 + + + such attempted mutation. The server may also choose to send + solicited READONLY responses for each subsequent attempted + mutation. + + */tag READWRITE + + This indicates that the mailbox is read-write. The server is + required to respond to a READONLY or READWRITE command with either + a solicited READONLY or a solicited READWRITE response. + + */tag BBOARD bboard_name + + This message is produced in its solicited form as a response to a + FIND BBOARDS command. In its unsolicited form it represents a + notification by the server that a new BBoard has been added. + Bboard_name must be a name that can be supplied to the BBOARD + command so as to select the appropriate bboard. + + */tag MAILBOX non_inbox_mailbox_name + + This message is produced in its solicited form as a response to a + FIND MAILBOXES command. In its unsolicited form it represents a + notification by the server that a new mailbox has been added, + perhaps as the result of a COPY command creating a new mailbox. + Non_inbox_mailbox_name must be a name that can be supplied to the + SELECT command so as to select the appropriate mailbox. Note: + non_inbox_mailbox_name is never the string "INBOX". + + */tag SUPPORTED.VERSIONS (version_specs) + + This message is used either as a response to the + SUPPORTED.VERSIONS or, in its unsolicited form, to indicate the + dynamic addition or removal of support for features or protocol + versions. Each version_spec is of the form (4 2 + EIGHT.BIT.TRANSPARENT AUTO.SET.SEEN ...), i.e., a major version + number and a minor version number for the protocol and the set of + features supported under the server's implementation of that + protocol version. A server may not dynamically remove support for + any version or feature that has been selected by any currently + logged in client by the use of the VERSION command. + + Example: + A00005 SUPPORTED.VERSIONS ((2 0 ) + (2 2 TAGGED.SOLICITED) + (3 0 EIGHT.BIT.TRANSPARENT TAGGED.SOLICITED)) + + Indicates that two major versions are supported and one minor + version is supported and that tagged solicited messages are + + + +Rice [Page 31] + +RFC 1203 IMAP3 February 1991 + + + supported in versions 2.2 and 3.0 with eight bit characters being + supported under version 3. For each feature mentioned in the list + of features there is also always the negation of that feature. + For example, if the server supports the TAGGED.SOLICITED feature + then it also supports the ~TAGGED.SOLICITED feature, which + disables this feature. Note: These are only example feature + names and are not necessarily supported by any server. See the + appendix on features for more information on features. + + + text + + This response indicates that the server is ready to accept the + text of a literal from the client. Normally, a command from the + client is a single text line. If the server detects an error in + the command, it can simply discard the remainder of the line. It + cannot do this in the case of commands which contain literals, + since a literal can be an arbitrarily long amount of text, and the + server may not even be expecting a literal. This mechanism is + provided so the client knows not to send a literal until the + server definitely expects it, preserving client/server + synchronization. + + In actual practice, this situation is rarely encountered. In the + current protocol, the only client commands likely to contain + literals are the LOGIN command and the STORE RFC822.HEADER or + STORE RFC822.TEXT commands. Consider a situation in which a + server validates the user before checking the password. If the + password contains "funny" characters and hence is sent as a + literal, then if the user is invalid an error would occur before + the password is parsed. + + No such synchronization protection is provided for literals sent + from the server to the client, for performance reasons. Any + synchronization problems in this direction would be due to a bug + in the client or server and not for some operational problem. + +Sample IMAP3 session + + The following is a transcript of an actual IMAP3 session. Server + output is identified by "S:" and client output by "U:". In cases + where lines were too long to fit within the boundaries of this + document, the line was continued on the next line preceded by a tab. + + S: * OK SUMEX-AIM.Stanford.EDU Interactive Mail Access Protocol + III Service 6.1(349) at Mon, 14 May 90 14:58:30 PDT + U: a001 SUPPORTED.VERSIONS + S: * SUPPORTED.VERSIONS ((2 0 ) (3 0 EIGHT.BIT.TRANSPARENT + AUTO.SET.SEEN TAGGED.SOLICITED)) + + + +Rice [Page 32] + +RFC 1203 IMAP3 February 1991 + + + S: A001 Supported Versions returned. + U: a002 SELECT.VERSION (3 0) + S: a002 OK Version 3.0 Selected. + U: a003 SELECT.FEATURES TAGGED.SOLICITED + S: a003 OK Features selected. + U: a004 login crispin secret + S: a004 OK User CRISPIN logged in at Thu, 9 Jun 90 14:58:42 PDT, + job 76 + U: a005 select inbox + S: a005 FLAGS (Bugs SF Party Skating Meeting Flames Request AI + Question Note \XXXX \YYYY \Answered \Flagged \Deleted + \Seen) + S: a005 16 EXISTS + S: a005 0 RECENT + S: a006 OK Select complete + U: a006 fetch 16 all + S: a006 16 Fetch (Flags (\Seen) InternalDate " 9-Jun-88 12:55: + RFC822.Size 637 Envelope ("Sat, 4 Jun 88 13:27:11 PDT" + "INFO-MAC Mail Message" (("Larry Fagan" NIL "FAGAN" + "SUMEX-AIM.Stanford.EDU" NIL)) (("Larry Fagan" NIL "FAGAN" + "SUMEX-AIM.Stanford.EDU" NIL)) (("Larry Fagan" NIL "FAGAN" + "SUMEX-AIM.Stanford.EDU" NIL)) ((NIL NIL "rindflEISCH" + "SUMEX-AIM.Stanford.EDU" NIL)) NIL NIL NIL + "<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>")) + S: a006 OK Fetch completed + U: a007 fetch 16 rfc822 + S: a007 16 Fetch (RFC822 {637} + S: Mail-From: RINDFLEISCH created at 9-Jun-88 12:55:43 + S: Mail-From: FAGAN created at 4-Jun-88 13:27:12 + S: Date: Sat, 4 Jun 88 13:27:11 PDT + S: From: Larry Fagan + S: To: rindflEISCH@SUMEX-AIM.Stanford.EDU + S: Subject: INFO-MAC Mail Message + S: Message-ID: <12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU> + S: ReSent-Date: Thu, 9 Jun 88 12:55:43 PDT + S: ReSent-From: TC Rindfleisch + S: ReSent-To: Yeager@SUMEX-AIM.Stanford.EDU, + Crispin@SUMEX-AIM.Stanford.EDU + S: ReSent-Message-ID: + <12405133897.80.RINDFLEISCH@SUMEX-AIM.Stanford.EDU> + S: + S: The file is usenetv4-55.arc ... + S: Larry + S: ------- + S: ) + S: a007 OK Fetch completed + U: a008 logout + S: a008 BYE UNIX IMAP III server terminating connection + + + +Rice [Page 33] + +RFC 1203 IMAP3 February 1991 + + + S: a008 OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol + Service logout + +Implementation Discussion + + As of this writing, SUMEX has completed an IMAP2 client for Xerox + Lisp machines written in hybrid Interlisp/CommonLisp and is beginning + distribution of a client for TI Explorer Lisp machines. SUMEX has + also completed a portable IMAP2 client protocol library module + written in C. This library, with the addition of a small main + program (primarily user interface) and a TCP/IP driver, became a + rudimentary remote system mail-reading program under Unix. The first + production use of this library is as a part of a MacII client which + has now been under daily use (by real users) at Stanford for quite + some time. + + As of this writing, SUMEX has completed IMAP2 servers for TOPS-20 + written in DEC-20 assembly language and 4.2/3 BSD Unix written in C. + The TOPS-20 server is fully compatible with MM-20, the standard + TOPS-20 mailsystem, and requires no special action or setup on the + part of the user. The INBOX under TOPS-20 is the user's MAIL.TXT. + The TOPS-20 server also supports multiple simultaneous access to the + same mailbox, including simultaneous access between the IMAP3 server + and MM-20. The 4.2/3 BSD Unix server requires that the user use + either Unix Mail format or mail.txt format which is compatible with + SRI MM-32 or Columbia MM-C. The 4.2/3 BSD Unix server allows + simultaneous read access; write access must be exclusive. There is + also an experimental IMAP3 server running on the TI Explorer class of + machine, which uses MM mailbox format and which can communicate over + both TCP and Chaos. + + The Xerox Lisp client and DEC-20 server have been in production use + for over two years; the Unix server was been in production use for + over a year. IMAP3 has been used to access mailboxes at remote sites + from a local workstation via the Internet. For example, from the + Stanford local network one of the authors has read his mailbox at a + Milnet site. + + A number of IMAP clients have now been developed or are being + developed. Amongst these are versions that run on the following + machines: + + . Xerox Lisp machines + . Apple Macintosh + . NeXT + . IBM PC + . TI Explorer Lisp machines + . "Glass teletype" version that runs under Unix + + + +Rice [Page 34] + +RFC 1203 IMAP3 February 1991 + + + . GNU Emacs + . X Windows + . NTT ELIS + + Each of these client programs is carefully tuned to optimize the + performance and user interface in a manner that is consistent with + the the user interface model of the native machine. For example, the + Macintosh client features a "messy-desk" interface that allows the + cutting and pasting of text with the use of the clipboard with a menu + driven interface with keyboard accelerators. + + This specification does not make any formal definition of size + restrictions, but some of the existing servers have the following + limitations: + + DEC-20 + . length of a mailbox: 7,077,888 characters + . maximum number of messages: 18,432 messages + . length of a command line: 10,000 characters + . length of the local host name: 64 characters + . length of a "short" argument: 39 characters + . length of a "long" argument: 491,520 characters + . maximum amount of data output in a single fetch: + 655,360 characters + + TI-Explorer + . length of a mailbox: limited by the Minimum of the size of the + virtual address space and the size of the file system + . maximum number of messages: limited by the the size of the + virtual address space + . length of a command line: limited by the the size of the + virtual address space + . length of the local host name: limited by the the size of the + virtual address space + . length of a "short" argument: limited by the the size of the + virtual address space + . length of a "long" argument: limited by the the size of the + virtual address space + . maximum amount of data output in a single fetch: not limited + + Typical values for these limits are 30Mb for file systems and 128Mb + for virtual address space. + + To date, nobody has run up against any of these limitations, many of + which are substantially larger than most current user mail reading + programs. + + There are several advantages to the scheme of tags and solicited + + + +Rice [Page 35] + +RFC 1203 IMAP3 February 1991 + + + responses and unsolicited data. First, the infamous synchronization + problems of SMTP and similar protocols do not happen with tagged + commands; a command is not considered satisfied until a completion + acknowledgement with the same tag is seen. Tagging allows an + arbitrary amount of other responses ("solicited" data) to be sent by + the server with no possibility of the client losing synchronization. + Compare this with the problems that FTP or SMTP clients have with + continuation, partial completion, and commentary reply codes. + + Another advantage is that a non-lockstep client implementation is + possible. The client could send a command, and entrust the handling + of the server responses to a different process which would signal the + client when the tagged response comes in. Some clients might be + implemented in a thoroughly asynchronous manner, having, perhaps, + multiple outstanding commands at any given time. Note: this does + not require that the server process these commands in anything other + than a lock-step manner. It simply allows clients to take advantage + of servers that are able to do such asynchronous operations. + + It was observed that synchronization problems can occur with literals + if the literal is not recognized as such. Fortunately, the cases in + which this can happen are relatively rare; a mechanism (the special + "+" tag response) was introduced to handle those few cases which + could happen. The proper way to address this problem in all cases is + probably to move towards a record-oriented architecture instead of + the text stream model provided by TCP. + + Unsolicited data needs some discussion. Unlike most protocols, in + which the server merely does the client's bidding, an IMAP3 server + has a semi-autonomous role. By means of sending "unsolicited data", + the server is in effect sending a command to the client -- to update + and/or extend its (incomplete) model of the mailbox with new + information from the server. In this viewpoint, although a "fetch" + command is a request for specific information from the client, the + server is always at liberty to include more than the desired data as + "unsolicited". A server acknowledgement to the "fetch" is a + statement that at least all the requested data has been sent. + + In terms of implementation, a simple lock-step client may have a + local cache of data from the mailbox. This cache is incomplete in + general, and at select time is empty. A listener on the IMAP + connection in the client processes all solicited and unsolicited data + symmetrically, and updates the cache based on this data, i.e., the + client faults on a cache miss and asks the server to fill that cache + slot synchronously. If a tagged completion response arrives, the + listener unblocks the process which sent the tagged request. + + Clearly, given this model it is not strictly necessary to distinguish + + + +Rice [Page 36] + +RFC 1203 IMAP3 February 1991 + + + most solicited from unsolicited data. Doing so, however, apart from + being clearer, also allows such simplistic, lock-step client + implementations that extract the specific value of the response to + command by trapping the tagged response. This allows the client not + to have to block on some complex predicate that involves watching to + see an update in a cache cell. + + For example, perhaps as a result of opening a mailbox, solicited data + from the server arrives. The first piece of data is the number of + messages. This is used to size the cache; note that, if new mail + arrives, by sending a new "number of messages" unsolicited data + message server will cause the cache to be re-sized. If the client + attempts to access information from the cache, it will encounter + empty spots which will trigger "fetch" requests. The request would + be sent, some solicited data including the answer to the fetch will + flow back, and then the "fetch" response will unblock the client. + + People familiar with demand-paged virtual memory design will + recognize this model as being very similar to page-fault handling on + a demand-paged system. + +Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in RFC 822 with one exception; the + delimiter used with the "#" construct is a single space (SP) and not + a comma. + +address ::= "(" addr_name SP addr_adl SP addr_mailbox SP + addr_host addr_comment ")" + +addr_adl ::= nil / string + +addr_comment ::= nil / string + +addr_host ::= nil / string + +addr_mailbox ::= nil / string + +addr_name ::= nil / string + +bboard ::= "BBOARD" SP bboard_name + +bboard_name ::= string + +bboard_notify ::= "BBOARD" sp bboard_name + +canonical_key ::= "$CC" / "$FROM" / "$SUBJECT" / "$TO" + + + +Rice [Page 37] + +RFC 1203 IMAP3 February 1991 + + +check ::= "CHECK" + +concrete_key ::= string + +copy ::= "COPY" SP sequence SP mailbox + +criterion ::= "ALL" / "ANSWERED" / + "BCC" SP string / "BEFORE" SP string / + "BODY" SP string / "CC" SP string / "DELETED" / + "FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" / + "ON" SP string / "RECENT" / "SEEN" / + "SINCE" SP string / "TEXT" SP string / + "TO" SP string / "UNANSWERED" / "UNDELETED" / + "UNFLAGGED" / "UNKEYWORD" / "UNSEEN" / key SP string + +criteria ::= 1#criterion + +data ::= ("FLAGS" SP flag_list / + search_notify / bboard_notify / mailbox_notify / + supported_versions_notify / "READONLY" / "READWRITE" / + "BYE" SP text_line / "OK" SP text_line / + "NO" SP text_line / "BAD" SP text_line) + +date ::= string in form "dd-mmm-yy hh:mm:ss-zzz" + +envelope ::= "(" env_date SP env_subject SP env_from SP + env_sender SP env_reply-to SP env_to SP + env_cc SP env_bcc SP env_in-reply-to SP + env_message-id ")" + +env_bcc ::= nil / "(" 1*address ")" + +env_cc ::= nil / "(" 1*address ")" + +env_date ::= string + +env_from ::= nil / "(" 1*address ")" + +env_in-reply-to ::= nil / string + +env_length ::= NUMBER + +env_message-id ::= nil / string + +env_reply-to ::= nil / "(" 1*address ")" + +env_sender ::= nil / "(" 1*address ")" + + + + +Rice [Page 38] + +RFC 1203 IMAP3 February 1991 + + +env_subject ::= nil / string + +env_to ::= nil / "(" 1*address ")" + +expunge ::= "EXPUNGE" + +feature ::= ATOM + +fetch ::= "FETCH" SP sequence SP ("ALL" / "FAST" / + fetch_att / "(" 1#fetch_att ")") + +fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / + "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" / + "RFC822.TEXT" / key + +find ::= "FIND" ("BBOARDS" / "MAILBOXES") pattern + +flag_list ::= ATOM / "(" 1#ATOM ")" + +flags ::= "FLAGS" + +generic_key ::= "BCC" / "BODY" / "CC" / "FROM" / "HEADER" / "SIZE" / + "SUBJECT" / "TEXT" / "TO" + +key ::= generic_key / canonical_key / concrete_key + +literal ::= "{" NUMBER "}" CRLF ASCII-STRING + +login ::= "LOGIN" SP userid SP password + +logout ::= "LOGOUT" + +mailbox ::= "INBOX" / string + +mailbox_notify ::= MAILBOX non_inbox_mailbox_name + +msg_copy ::= "COPY" + +msg_data ::= (msg_exists / msg_recent / msg_expunge / + msg_fetch / msg_copy) + +msg_exists ::= "EXISTS" + +msg_expunge ::= "EXPUNGE" + +msg_fetch ::= ("FETCH" / "STORE") SP "(" 1#("ENVELOPE" SP + env_length envelope / "FLAGS" SP "(" 1#(recent_flag + flag_list) ")" / "INTERNALDATE" SP date / + + + +Rice [Page 39] + +RFC 1203 IMAP3 February 1991 + + + "RFC822" SP string / "RFC822.HEADER" SP string / + "RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP + string / key SP string_list) ")" + +msg_recent ::= "RECENT" + +msg_num ::= NUMBER + +nil ::= "NIL" + +non_inbox_mailbox_name ::= string + +noop ::= "NOOP" + +numbers ::= 1#NUMBER + +password ::= string + +pattern ::= string + +recent_flag ::= "\RECENT" + +read_only ::= "READONLY" + +read_write ::= "READWRITE" + +ready ::= "+" SP text_line + +request ::= tag SP (noop / login / logout / select / check / + expunge / copy / fetch / store / search / + select_version / select_features / + supported_versions / bboard / find / + read_only / read_write / flags / set_flags ) CRLF + +response ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF + +search ::= "SEARCH" SP criteria + +search_notify ::= "SEARCH" SP (numbers) SP (criteria) + +select ::= "SELECT" SP mailbox + +select_features ::= "SELECT.FEATURES" 1#feature + +select_version ::= "SELECT.VERSION" SP "(" NUMBER SP NUMBER ")" + +sequence ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":" + sequence) + + + +Rice [Page 40] + +RFC 1203 IMAP3 February 1991 + + +set_flags ::= "SET.FLAGS" SP flag_list + +solicited ::= tag SP (msg_num SP msg_data / data / + solicited_only) CRLF + +solicited_only ::= {None currently defined} + +store ::= "STORE" SP sequence SP store_att + +store_att ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list / + "FLAGS" SP flag_list / RFC822.TEXT SP string + / RFC822.HEADER SP string / key SP string) + +string ::= atom / """" 1*character """" / literal + +string_list ::= string / ("(" 1#string ")") + +supported_versions ::= "SUPPORTED.VERSIONS" + +supported_versions_notify ::= "SUPPORTED.VERSIONS" "(" 1#version_spec + ")" + +system_flags ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED" SP + "\SEEN" + +tag ::= atom + +unsolicited ::= "*" SP (msg_num SP msg_data / data) CRLF + +userid ::= string + +version_spec ::= "(" NUMBER SP NUMBER SP 1#feature ")" + +Appendix: Features. + + In this section we outline the standard features that are supported + by all IMAP3 servers and identify those features which are + recommended or experimental. For each of these features the default + setting is specified. This means that it is required of any server + that supports a given feature to make the default enabledness of that + feature as is specified below. It is required that for each feature + supported by a server the inverse feature should also be supported. + The inverse feature name shall always be defined as the feature name + preceded by the "~" character. Thus, the AUTO.SET.SEEN feature is + disabled by the ~AUTO.SET.SEEN feature. + + + + + + +Rice [Page 41] + +RFC 1203 IMAP3 February 1991 + + + Required Features: + + AUTO.SET.SEEN - When this features is enabled (default is disabled), + the \\SEEN flag is set for all appropriate messages as a side + effect of any of the following: + FETCH of RFC822 + FETCH of RFC822.TEXT + COPY + Justification: This feature is provided for the use of clients + that are unable to pipeline their commands effectively and + communicate over high latency connections. When disabled, + the server will not perform any such side effects. This feature + is also provided so as to smooth the transition from IMAP2 to + IMAP3. + + + TAGGED.SOLICITED - When this feature is enabled (default is enabled + for IMAP3, disabled for IMAP2 mode), solicited responses from + the server will have the tag specified by the client. + When this feature is disabled, solicited responses from the + server will have the IMAP2 compatible tag "*", not the + tag specified by the client. + Justification: This feature is provided so as to smooth the + transition from IMAP2 to IMAP3. + + Recommended Features. + + EIGHT.BIT.TRANSPARENT - When this feature is enabled + (default is disabled), the server allows the transparent + transmission of eight bit characters. When this feature is + disabled, the value of any bit other than the least significant + 7 bits transmitted by the server is unspecified. If this + feature is enabled, the characters that compose all command + keywords specified in the IMAP3 grammar and all feature names + use only their 7 least significant bits. + Justification: This feature is provided for the purpose of + supporting national character sets within messages, encoded + languages such as Japanese Kanji characters and also of binary + data, such as programs, graphics and sound. + + + NEW.MAIL.NOTIFY - When this feature is enabled (default is + disabled for compatibility with the majority of existing + IMAP2 servers), the server will notify the client of the + arrival of new mail in the currently selected mailbox + using the appropriate RECENT and EXISTS unsolicited messages + without the client needing to send periodic CHECK commands. + Justification: This feature is provided to allow clients to + + + +Rice [Page 42] + +RFC 1203 IMAP3 February 1991 + + + switch off any periodic polling strategy that they may use + to look for new mail. Such polling unnecessarily uses bandwidth + and can cause the interactive performance to degrade because + the user can be kept waiting while some background process + is doing a CHECK. + + + SEND - When this feature is enabled (default is disabled) a new + "SEND" command becomes available to the client. The SEND + command instructs the server to send a message, rather + than requiring the client to use its own, local message + sending capability, for example. An example of of the + send command might be as follows: + tag42 SEND RFC822 {2083} + From: James Rice + To:..... + If the server is unable to parse the message being sent then + it is required to issue a suitable NO notification to the client. + If the message cannot be delivered for some reason then the + server should send a suitable message to the FROM: address + of the message detailing the delivery failure. + When the SEND feature is enabled, the "send" production in + the grammar is added and as defined below. The "send" + request is added to the list of requests in the request + production also as shown below: + + message_format ::= RFC822 + + request ::= tag SP (noop / login / logout / select / check / + expunge / copy / fetch / store / search / + select_version / select_features / + supported_versions / bboard / find / + read_only / read_write / flags / + set_flags / send) CRLF + + send ::= SEND SP message_format SP string + + Justification: This feature is provided so that mail can be + sent by the same reliable server that is used for the storage + of mail. This has, amongst others, the following benefits: + - Single process clients need not be delayed by mail + transmission. + - Mail sent by the client will have the server named as the + message's sender. This can be important because there are + a lot of mailers that erroneously cause reply mail to be + sent to the Sender, not the From or Reply-To address. Since + the client in general is not listening for mail being sent + to it directly this can cause mail to be lost. + + + +Rice [Page 43] + +RFC 1203 IMAP3 February 1991 + + + - Clients can be written that do not have any native message + sending capability. + + + ADD.MESSAGE - When this feature is enabled (default is disabled) + a new "ADD.MESSAGE" command becomes available to the client. + The ADD.MESSAGE command instructs the server to add the + specified message to the designated mailbox. This command + can be thought of as being like a COPY command except in + this case the message that is put in the designated mailbox + is specified as a string, rather than as a message number to + be copied from the currently selected mailbox. An example + use of this command might be as follows: + tag42 ADD.MESSAGE OUTGOING-MAIL RFC822 {2083} + From: James Rice + To:..... + This will have the effect of adding the message to the mailbox + called OUTGOING-MAIL. + If the server is unable to parse the message being added then + it is required to issue a suitable NO notification to the client. + When the ADD.MESSAGE feature is enabled, the "add_message" + production in the grammar is added and as defined below. + The "add_message" request is added to the list of requests + in the request production also as shown below: + + add_message ::= ADD.MESSAGE SP mailbox SP format SP string + + message_format ::= RFC822 + + request ::= tag SP (noop / login / logout / select / check / + expunge / copy / fetch / store / search / + select_version / select_features / + supported_versions / bboard / find / + read_only / read_write / flags / set_flags / + add_message) CRLF + + Justification: This feature is provided so that clients can + easily add mail to specific mailboxes. This allows clients + to implement such behavior as outgoing mail storage (BCC) + without the need to resort to mailing to special BCC mailboxes. + + + RENUMBER - When this feature is enabled (default is disabled) + the RENUMBER command becomes available to the client. + The RENUMBER command will reorder the assignment of message + numbers to the messages in the mailbox. If this results in a + change to the association of any message number with any + message then the server is required to send solicited RESET + + + +Rice [Page 44] + +RFC 1203 IMAP3 February 1991 + + + responses to the client. The intent of this command is + to allow users to view mailboxes in user-meaningful order + efficiently. While the client could do the ordering, + it would be less efficient in general. Note that the + server may or may not change the actual storage of the + messages and the ordering may or may not remain in effect + after another mailbox is selected or the IMAP session is + terminated. Informally, the syntax for the RENUMBER + command is: + + tag RENUMBER field_name ordering_type + + this has the effect of changing the IMAP grammar to be + as follows: + + ordering_type ::= DATE / NUMERIC / ALPHA + + renumber ::= RENUMBER SP field_name SP ordering_type + + request ::= tag SP (noop / login / logout / select / check / + expunge / copy / fetch / store / search / + select_version / select_features / + supported_versions / bboard / find / + read_only / read_write / flags / set_flags / + renumber) CRLF + + For example: + tag42 RENUMBER FROM ALPHA + ;;;RENUMBER alphabetically by the from field + tag42 RESET 10:20,49 + ;;;Messages 10 to 20 and 49 have changed + tag42 OK RENUMBER finished. Sequence has changed + tag43 FETCH ALL 10:20,49 + ;;;Client chooses to fetch the changed msgs. + + To support this the RESET message is defined as follows: + + */tag RESET message_sequence + This solicited of unsolicited message from the server informs the + client that it should flush any information that it has + retained for the specified messages. + + Justification: This feature is provided so that clients can + view mailboxes in an order that is convenient to the user. + This is particularly important in the context of mailboxes + that the user copies messages to from other mailboxes. This + user-controlled filing process often does not happen in any + well-defined order. Because messages in a mailbox are + + + +Rice [Page 45] + +RFC 1203 IMAP3 February 1991 + + + implicitly ordered (usually by arrival date, though this is + not a required ordering predicate), the user can be confused + by the apparent order of messages in the mailbox. The + addition of the RENUMBER command makes it unnecessary + for the user to leave IMAP and use some other mail system to + sort mailboxes. + + + ENCODING - When this feature is enabled (default is disabled) a new + generic key named ENCODING is defined. The value associated + with the generic ENCODING key is a list of (tag encoding-type + options...) lists that represent the ordered, possibly encoded + body of the message. Each such list represents a segment of + the body of the message and the way in which it is encoded. + Any options that follow the encoding_type are further + qualifiers that describe the format of the segment. Each tag + is created by the server and is unique with respect to the + other tags allocated for the other elements in the ENCODING + list. The client may use the tags returned by the server as + concrete keys to access a field which is encoded using the + encoding type and options mentioned in the appropriate list. + Thus: + + tag41 FETCH 196 ENCODING ; Client asks for encoding field of msg 196. + tag41 FETCH ENCODING NIL ; Server replies. This message is not encoded. + tag41 OK Fetch completed. + tag42 FETCH 197 ENCODING ; Client asks for encoding field of msg 197. + tag42 FETCH ENCODING ((G001 UUENCODE) (G002 HEX)) ; Server replies. + tag42 OK Fetch completed. + tag43 FETCH 197 G002 ; Client asks for field named G002 + tag43 FETCH G002 "A0 00 FF 13 42......." ; Server sends value of field. + tag43 OK Fetch completed. + + or + + tag44 STORE 197 G002 "0A 00 FF 31 24......." + ; Store back the segment with nibbles swapped + + Note: As a side-effect of enabling this feature, the generic key + TEXT will be redefined so as to return only those body parts of a + message that are of type TEXT. The concrete key RFC822.TEXT, on + the other hand, would still return everything in the body of the + message, even if it was full of strange, binary character + sequences. + + When the client STOREs to a field denoted by one of the above tags + the server will interpret the value being passed as being in the + same format as is currently specified in the ENCODING field. The + + + +Rice [Page 46] + +RFC 1203 IMAP3 February 1991 + + + server is not required to be able to reformat the data associated + with the ENCODING tags if the client STOREs a new value for the + ENCODING field. The interpretability of a message in the context + of its ENCODING field is undefined if the client side-effects that + ENCODING field, unless the client also STOREs new, reformatted + values for the fields that have had their encoding changed. + + If the client stores a new value for the ENCODING field then the + tags in the new value will be used to index the parts of the body. + All tags in a client-STOREd ENCODING that are the same as those + originally generated by the server in response to a FETCH ENCODING + command are said still to denote the fields that they originally + denoted, though possibly reordered. Any tags not originally + defined by the server will denote new message parts, in the + appropriate format, in the relative position specified. The + exclusion of any tags that the server originally defined in a + FETCH of the ENCODING field will indicate the deletion of that + part of the message. Newly created message parts are undefined by + default, so if the client fails to follow the STOREing of the + ENCODING field with suitable STORE commands for the values + associated with any newly created tags, these fields will contain + the null value NIL. + + Justification: This feature is supplied so as to allow support + for emergent multi-part and multi-media mail standards. + + INDEXABLE.FIELDS - When this feature is enabled (default is + disabled) the grammar of fetch commands is changed to allow the + client to select a specific subsequence from the field in + question. For example: + + tag42 FETCH 197 BODY 2000:3999 + + would fetch the second two thousand bytes of the body of message + 197. This feature allows resource limited clients to access + small parts of large messages. The formal syntax for this is: + + fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / + fetch_key / (fetch_key SP NUMBER ":" NUMBER) + + fetch_key ::= "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" / + "RFC822.TEXT" / key + + If the lower bound number (the number to the left of the colon) + exceeds the maximum size of the field then the empty string is + returned. If the upper bound exceeds the maximum size of the + field but the lower bound does not then the server will return the + remaining substring of the field after the lower bound. The + + + +Rice [Page 47] + +RFC 1203 IMAP3 February 1991 + + + bounds specified are zero indexed into the fields and the bounds + index fields by 8-bit bytes. + + Justification: This feature is provided so as to allow resource- + limited clients to read very large messages and also to allow + clients to improve interactive response for the reading of large + messages by fetching the first "screen full" of data to display + immediately and fetching the rest of the message in the + background. + + SET.EOL - When enabled (default is disabled), this feature + allows the new command SET.EOL to be available, changing the + grammar as follows: + + character ::= "CR" / "LF" / number + + request ::= tag SP (noop / login / logout / select / check / + expunge / copy / fetch / store / search / + select_version / select_features / + supported_versions / bboard / find / + read_only / read_write / flags / set_flags / + set_eol) CRLF + + set_eol ::= "SET.EOL" 1#character + + This has the effect of changing the end of line character sequence + generated by the server for newlines within strings to the + sequence of characters specified. The characters in the sequence + can be either the specified symbolically named characters or a + numerical value, specifying the decimal value of the character to + use. Thus, if the client would like newlines in strings to be + indicated by a carriage return followed by a control-d, the client + would issue the following command: + + tag42 SET.EOL CR 4 + + If the server is unable to support the combination of characters + requested by the client as its end-of-line pattern it will reply + with a NO response. This might be the case, for example, if a + server is only able to generate its own native line feed pattern + and the CRLF required by IMAP by default. + + The server is required to change any length denoting values, such + as envelope byte counts for all future transactions to reflect the + new eol setting. This change in reported sizes should apply to + all generic size fetching keys, but not to concrete ones such as + RFC822.SIZE, which by their very nature require a size measurement + in RFC822 format, i.e., with CRLF as the end-of-line convention. + + + +Rice [Page 48] + +RFC 1203 IMAP3 February 1991 + + + Justification: This feature is provided because frequently clients + and servers might have end-of-line conventions other than the CRLF + specified by RFC822. It is undesirable that the IMAP be linked + too closely to RFC822 and selecting a different convention might + allow substantial performance improvements in both clients and + servers by saving either client, server or both from having to + shuffle text around so as to add or remove non-local end-of-line + sequences. + +Acknowledgements: + + This text is based on RFC 1064 by Mark Crispin. + + The following have made major contributions to this proposed update + to the IMAP2 protocol: + + James Rice + Richard Acuff + Bill Yeager + Christopher Lane + Bjorn Victor + + Additional input was also received from: + + Andrew Sweer + Tom Gruber + Kevin Brock + Mark Crispin + +Security Considerations + + Security issues are not discussed in this memo. + +Author's Address + + James Rice + Stanford University + Knowledge Systems Laboratory + 701 Welch Road + Building C + Palo Alto, CA 94304 + + Phone: (415) 723-8405 + EMail: RICE@SUMEX-AIM.STANFORD.EDU + + + + + + + +Rice [Page 49] + \ No newline at end of file diff --git a/RFC/rfc1225.txt b/RFC/rfc1225.txt new file mode 100644 index 00000000..8d7e0029 --- /dev/null +++ b/RFC/rfc1225.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group M. Rose +Request for Comments: 1225 Performance Systems International +Obsoletes: RFC 1081 May 1991 + + + Post Office Protocol - Version 3 + +Status of this Memo + + This memo suggests a simple method for workstations to dynamically + access mail from a mailbox server. This RFC specifies an IAB + standards track protocol for the Internet community, and requests + discussion and suggestions for improvements. Please refer to the + current edition of the "IAB Official Protocol Standards" for the + standardization state and status of this protocol. Distribution of + this memo is unlimited. + +Overview + + This memo is a republication of RFC 1081 which was based on RFC 918 + (since revised as RFC 937). Although similar in form to the original + Post Office Protocol (POP) proposed for the Internet community, the + protocol discussed in this memo is similar in spirit to the ideas + investigated by the MZnet project at the University of California, + Irvine. + + Further, substantial work was done on examining POP in a PC-based + environment. This work, which resulted in additional functionality + in this protocol, was performed by the ACIS Networking Systems Group + at Stanford University. The author gratefully acknowledges their + interest. + +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 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 + + + +Rose [Page 1] + +RFC 1225 POP3 May 1991 + + + permit a workstation to dynamically access a maildrop on a server + host in a useful fashion. Usually, this means that the POP3 is used + to allow a workstation to retrieve mail that the server is holding + for it. + + 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. + +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 (this relay host could be, but need not be, the + POP3 server host for the client host). + + If this method is followed, then the client host appears to the MTS + as a user agent, and should NOT be regarded as a "trusted" MTS entity + in any sense whatsoever. This concept, along with the role of the + POP3 as a part of a split-UA model is discussed later in this memo. + + 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 keyword possibly followed by an + argument. All commands are terminated by a CRLF pair. + + Responses in the POP3 consist of a success indicator and a keyword + possibly followed by additional information. All responses are + terminated by a CRLF pair. There are currently two success + indicators: positive ("+OK") and negative ("-ERR"). + + 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. + + + +Rose [Page 2] + +RFC 1225 POP3 May 1991 + + + 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 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 + finished its transactions, 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. + +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 string terminated + by CRLF. An example might be: + + S. +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU) + + Note that this greeting is a POP3 reply. The POP3 server should + always give a positive response as the greeting. + + The POP3 session is now in the AUTHORIZATION state. The client must + now issue the USER command. If the POP3 server responds with a + positive success indicator ("+OK"), then the client may issue either + the PASS command to complete the authorization, or the QUIT command + to terminate the POP3 session. If the POP3 server responds with a + negative success indicator ("-ERR") to the USER command, then the + client may either issue a new USER command or may issue the QUIT + command. + + 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. If so, + the POP3 server then acquires an exclusive-access lock on the + maildrop. If the lock is successfully acquired, the POP3 server + parses the maildrop into individual messages (read note below), + + + +Rose [Page 3] + +RFC 1225 POP3 May 1991 + + + determines the last message (if any) present in the maildrop that was + referenced by the RETR command, and responds with a positive success + indicator. The POP3 session now enters the TRANSACTION state. If + the lock can not be acquired or the client should is denied access to + the appropriate maildrop or the maildrop can't be parsed for some + reason, the POP3 server responds with a negative success indicator. + (If a lock was acquired but the POP3 server intends to respond with a + negative success indicator, the POP3 server must release the lock + prior to rejecting the command.) At this point, the client may + either issue a new USER command and start again, or the client may + issue the QUIT command. + + NOTE: Minimal implementations of the POP3 need only be + able to break a maildrop into its component messages; + they need NOT be able to parse individual messages. + More advanced implementations may wish to have this + capability, for reasons discussed later. + + After the POP3 server has parsed the maildrop into individual + messages, it assigns a message-id to each message, and notes the size + of the message in octets. The first message in the maildrop is + assigned a message-id of "1", the second is assigned "2", and so on, + so that the n'th message in a maildrop is assigned a message-id of + "n". In POP3 commands and responses, all message-id's and message + sizes are expressed in base-10 (i.e., decimal). + + It sets the "highest number accessed" to be that of the last message + referenced by the RETR command. + + Here are summaries for the three POP3 commands discussed thus far: + + USER name + Arguments: a server specific user-id (required) + Restrictions: may only be given in the AUTHORIZATION + state after the POP3 greeting or after an + unsuccessful USER or PASS command + Possible Responses: + +OK name is welcome here + -ERR never heard of name + Examples: + C: USER mrose + S: +OK mrose is a real hoopy frood + ... + C: USER frated + S: -ERR sorry, frated doesn't get his mail here + + PASS string + Arguments: a server/user-id specific password (required) + + + +Rose [Page 4] + +RFC 1225 POP3 May 1991 + + + Restrictions: may only be given in the AUTHORIZATION + state after a successful USER command + 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: +OK mrose's maildrop has 2 messages + (320 octets) + ... + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + S: -ERR unable to lock mrose's maildrop, file + already locked + + QUIT + Arguments: none + Restrictions: none + Possible Responses: + +OK + Examples: + C: QUIT + S: +OK dewey POP3 server signing off + + +The TRANSACTION State + + Once the client has successfully identified itself to the POP3 server + and the POP3 server has locked and burst 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. + + 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. + + + +Rose [Page 5] + +RFC 1225 POP3 May 1991 + + + In order to simplify parsing, all POP3 servers are + required to use a certain format for drop listings. + The first octets present must indicate the number of + messages in the maildrop. Following this is 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-id (optionally) If a message-id is + given, it 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 "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 called a "scan listing" for that message. + + In order to simplify parsing, all POP3 servers are + required to use a certain format for scan listings. + The first octets present must be the message-id of + + + +Rose [Page 6] + +RFC 1225 POP3 May 1991 + + + the message. Following the message-id is the size of + the message in octets. 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 + 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-id (required) This message-id 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-id, being careful to byte-stuff the + termination character (as with all multi-line + responses). + + If the number associated with this message is higher + than the "highest number accessed" in the maildrop, the + + + +Rose [Page 7] + +RFC 1225 POP3 May 1991 + + + POP3 server updates the "highest number accessed" to + the number associated with this message. + + Possible Responses: + +OK message follows + -ERR no such message + Examples: + C: RETR 1 + S: +OK 120 octets + S: + S: . + + DELE msg + Arguments: a message-id (required) This message-id + may NOT refer to a message marked as deleted. + Restrictions: may only be given in the TRANSACTION state. + Discussion: + + The POP3 server marks the message as deleted. Any + future reference to the message-id 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. + + If the number associated with this message is higher + than the "highest number accessed" in the maildrop, + the POP3 server updates the "highest number accessed" + to the number associated with this message. + + 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: + + + +Rose [Page 8] + +RFC 1225 POP3 May 1991 + + + +OK + Examples: + C: NOOP + S: +OK + + LAST + Arguments: none + Restrictions: may only be issued in the TRANSACTION state. + Discussion: + + The POP3 server issues a positive response with a line + containing the highest message number which accessed. + Zero is returned in case no message in the maildrop has + been accessed during previous transactions. A client + may thereafter infer that messages, if any, numbered + greater than the response to the LAST command are + messages not yet accessed by the client. + + Possible Response: + +OK nn + + Examples: + C: STAT + S: +OK 4 320 + C: LAST + S: +OK 1 + C: RETR 3 + S: +OK 120 octets + S: + S: . + C: LAST + S: +OK 3 + C: DELE 2 + S: +OK message 2 deleted + C: LAST + S: +OK 3 + C: RSET + S: +OK + C: LAST + S: +OK 1 + + RSET + Arguments: none + Restrictions: may only be given in the TRANSACTION + state. + Discussion: + + + + +Rose [Page 9] + +RFC 1225 POP3 May 1991 + + + If any messages have been marked as deleted by the POP3 + server, they are unmarked. The POP3 server then + replies with a positive response. In addition, the + "highest number accessed" is also reset to the value + determined at the beginning of the POP3 session. + + Possible Responses: + +OK + Examples: + C: RSET + S: +OK maildrop has 2 messages (320 octets) + + + +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.) + + QUIT + Arguments: none + Restrictions: none + Discussion: + + The POP3 server removes all messages marked as deleted + from the maildrop. It then releases the + exclusive-access lock on the maildrop and replies as + to the success of + these operations. The TCP connection is then closed. + + Possible Responses: + +OK + Examples: + C: QUIT + S: +OK dewey POP3 server signing off (maildrop + empty) + ... + C: QUIT + S: +OK dewey POP3 server signing off (2 messages + left) + ... + + +Optional POP3 Commands + + The POP3 commands discussed above must be supported by all minimal + + + +Rose [Page 10] + +RFC 1225 POP3 May 1991 + + + 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-id (required) and a number. This + message-id 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 headers of the message, + the blank line separating the headers from the body, + and then the number of lines 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 10 + S: +OK + S: + S: . + ... + C: TOP 100 + S: -ERR no such message + + RPOP user + Arguments: a client specific user-id (required) + Restrictions: may only be given in the AUTHORIZATION + + + +Rose [Page 11] + +RFC 1225 POP3 May 1991 + + + state after a successful USER command; in addition, + may only be given if the client used a reserved + (privileged) TCP port to connect to the server. + Discussion: + + The RPOP command may be used instead of the PASS + command to authenticate access to the maildrop. In + order for this command to be successful, the POP3 + client must use a reserved TCP port (port < 1024) to + connect tothe server. The POP3 server uses the + argument pair from the USER and RPOP commands to + determine if the client should be given access to + the appropriate maildrop. Unlike the PASS command + however, the POP3 server considers if the remote user + specified by the RPOP command who resides on the POP3 + client host is allowed to access the maildrop for the + user specified by the USER command (e.g., on Berkeley + UNIX, the .rhosts mechanism is used). With the + exception of this differing in authentication, this + command is identical to the PASS command. + + Note that the use of this feature has allowed much wider + penetration into numerous hosts on local networks (and + sometimes remote networks) by those who gain illegal + access to computers by guessing passwords or otherwise + breaking into the system. + + Possible Responses: + +OK maildrop locked and ready + -ERR permission denied + Examples: + C: USER mrose + S: +OK mrose is a real hoopy frood + C: RPOP mrose + S: +OK mrose's maildrop has 2 messages (320 + octets) + + 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 + LAST + + + +Rose [Page 12] + +RFC 1225 POP3 May 1991 + + + RSET + + QUIT valid in the UPDATE state + + Optional POP3 Commands: + RPOP user valid in the AUTHORIZATION state + + TOP msg n valid in the TRANSACTION state + + POP3 Replies: + +OK + -ERR + + Note that with the exception of the STAT command, 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. + +Example POP3 Session + + S: + ... + C: + S: +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU) + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + 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: + S: . + C: DELE 1 + S: +OK message 1 deleted + C: RETR 2 + S: +OK 200 octets + S: + S: . + C: DELE 2 + S: +OK message 2 deleted + C: QUIT + + + +Rose [Page 13] + +RFC 1225 POP3 May 1991 + + + S: +OK dewey POP3 server signing off (maildrop empty) + C: + S: + +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 byte 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 client + can calculate the size of each message in octets when it parses the + maildrop into messages. 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 be counted twice, since the POP3 + client will remove all byte-stuffed termination characters when it + receives a multi-line response. + +The POP and the Split-UA model + + The underlying paradigm in which the POP3 functions is that of a + split-UA model. The POP3 client host, being a remote PC based + workstation, acts solely as a client to the message transport system. + It does not provide delivery/authentication services to others. + Hence, it is acting as a UA, on behalf of the person using the + workstation. Furthermore, the workstation uses SMTP to enter mail + into the MTS. + + In this sense, we have two UA functions which interface to the + message transport system: Posting (SMTP) and Retrieval (POP3). The + entity which supports this type of environment is called a split-UA + (since the user agent is split between two hosts which must + interoperate to provide these functions). + + ASIDE: Others might term this a remote-UA instead. + There are arguments supporting the use of both terms. + + This memo has explicitly referenced TCP as the underlying transport + agent for the POP3. This need not be the case. In the MZnet split- + UA, for example, personal micro-computer systems are used which do + not have IP-style networking capability. To connect to the POP3 + server host, a PC establishes a terminal connection using some simple + protocol (PhoneNet). A program on the PC drives the connection, + first establishing a login session as a normal user. The login shell + + + +Rose [Page 14] + +RFC 1225 POP3 May 1991 + + + for this pseudo-user is a program which drives the other half of the + terminal protocol and communicates with one of two servers. Although + MZnet can support several PCs, a single pseudo-user login is present + on the server host. The user-id and password for this pseudo-user + login is known to all members of MZnet. Hence, the first action of + the login shell, after starting the terminal protocol, is to demand a + USER/PASS authorization pair from the PC. This second level of + authorization is used to ascertain who is interacting with the MTS. + Although the server host is deemed to support a "trusted" MTS entity, + PCs in MZnet are not. Naturally, the USER/PASS authorization pair + for a PC is known only to the owner of the PC (in theory, at least). + + After successfully verifying the identity of the client, a modified + SMTP server is started, and the PC posts mail with the server host. + After the QUIT command is given to the SMTP server and it terminates, + a modified POP3 server is started, and the PC retrieves mail from the + server host. After the QUIT command is given to the POP3 server and + it terminates, the login shell for the pseudo-user terminates the + terminal protocol and logs the job out. The PC then closes the + terminal connection to the server host. + + The SMTP server used by MZnet is modified in the sense that it knows + that it's talking to a user agent and not a "trusted" entity in the + message transport system. Hence, it does performs the validation + activities normally performed by an entity in the MTS when it accepts + a message from a UA. + + The POP3 server used by MZnet is modified in the sense that it does + not require a USER/PASS combination before entering the TRANSACTION + state. The reason for this (of course) is that the PC has already + identified itself during the second-level authorization step + described above. + + NOTE: Truth in advertising laws require that the author + of this memo state that MZnet has not actually been + fully implemented. The concepts presented and proven + by the project led to the notion of the MZnet + split-slot model. This notion has inspired the + split-UA concept described in this memo, led to the + author's interest in the POP, and heavily influenced + the the description of the POP3 herein. + + In fact, some UAs present in the Internet already support the notion + of posting directly to an SMTP server and retrieving mail directly + from a POP server, even if the POP server and client resided on the + same host! + + ASIDE: this discussion raises an issue which this memo + + + +Rose [Page 15] + +RFC 1225 POP3 May 1991 + + + purposedly avoids: how does SMTP know that it's talking + to a "trusted" MTS entity? + +References + + [MZnet] Stefferud, E., J. Sweet, and T. Domae, "MZnet: Mail + Service for Personal Micro-Computer Systems", + Proceedings, IFIP 6.5 International Conference on + Computer Message Systems, Nottingham, U.K., May 1984. + + [RFC821] Postel, J., "Simple Mail Transfer Protocol", + USC/Information Sciences Institute, August 1982. + + [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet + Text Messages", University of Delaware, August 1982. + + [RFC937] Butler, M., J. Postel, D. Chase, J. Goldberger, and J. + Reynolds, "Post Office Protocol - Version 2", RFC 937, + USC/Information Sciences Institute, February 1985. + + [RFC1060] Reynolds, J., and J. Postel, "Assigned Numbers", RFC + 1060, USC/Information Sciences Institute, March 1990. + +Security Considerations + + Security issues are not discussed in this memo. + +Author's Address: + + Marshall T. Rose + Performance Systems International + 5201 Great America Parkway + Suite 3106 + Santa Clara, CA 95054 + + Phone: +1 408 562 6222 + + EMail: mrose@psi.com + X.500: rose, psi, us + + + + + + + + + + + + +Rose [Page 16] + \ No newline at end of file diff --git a/RFC/rfc1460.txt b/RFC/rfc1460.txt new file mode 100644 index 00000000..d6177599 --- /dev/null +++ b/RFC/rfc1460.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group M. Rose +Request for Comments: 1460 Dover Beach Consulting, Inc. +Obsoletes: 1225 June 1993 + + + Post Office Protocol - Version 3 + + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community, and requests discussion and suggestions for improvements. + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + Distribution of this memo is unlimited. + +Overview + + This memo is a revision to RFC 1225, a Draft Standard. It makes the + following changes from that document: + + - the RPOP facility is removed; + + - the optional APOP facility is added (which is in interoperable, + operational use in at least three implementations); + + - a typo was corrected with respect to the interaction of LAST + and RSET; + + - section numbers were added; and, + + - an acknowledgements section was added. + +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 + + + +Rose [Page 1] + +RFC 1460 POP3 June 1993 + + + 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 is used + to allow a workstation to retrieve mail that the server is holding + for it. + + 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 (this relay host could be, but need not be, the + POP3 server host for the client host). + + If this method is followed, then the client host appears to the MTS + as a user agent, and should NOT be regarded as a "trusted" MTS entity + in any sense whatsoever. This concept, along with the role of the + POP3 as a part of a split-UA model is discussed later in this memo. + +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 keyword possibly followed by an + argument. All commands are terminated by a CRLF pair. + + Responses in the POP3 consist of a success indicator and a keyword + possibly followed by additional information. All responses are + terminated by a CRLF pair. There are currently two success + indicators: positive ("+OK") and negative ("-ERR"). + + 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 + + + +Rose [Page 2] + +RFC 1460 POP3 June 1993 + + + 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 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 + finished its transactions, 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. + +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 string terminated + by CRLF. An example might be: + + S. +OK POP3 server ready + + Note that this greeting is a POP3 reply. The POP3 server should + always give a positive response as the greeting. + + The POP3 session is now in the AUTHORIZATION state. The client must + now issue the USER command. If the POP3 server responds with a + positive success indicator ("+OK"), then the client may issue either + the PASS command to complete the authorization, or the QUIT command + to terminate the POP3 session. If the POP3 server responds with a + negative success indicator ("-ERR") to the USER command, then the + client may either issue a new USER command or may issue the QUIT + command. + + + + +Rose [Page 3] + +RFC 1460 POP3 June 1993 + + + 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. If so, + the POP3 server then acquires an exclusive-access lock on the + maildrop. If the lock is successfully acquired, the POP3 server + parses the maildrop into individual messages (read note below), + determines the last message (if any) present in the maildrop that was + referenced by the RETR command, and responds with a positive success + indicator. The POP3 session now enters the TRANSACTION state. If + the lock can not be acquired or the client should is denied access to + the appropriate maildrop or the maildrop can't be parsed for some + reason, the POP3 server responds with a negative success indicator. + (If a lock was acquired but the POP3 server intends to respond with a + negative success indicator, the POP3 server must release the lock + prior to rejecting the command.) At this point, the client may + either issue a new USER command and start again, or the client may + issue the QUIT command. + + NOTE: Minimal implementations of the POP3 need only be + able to break a maildrop into its component messages; + they need NOT be able to parse individual messages. + More advanced implementations may wish to have this + capability, for reasons discussed later. + + After the POP3 server has parsed the maildrop into individual + messages, it assigns a message-id to each message, and notes the size + of the message in octets. The first message in the maildrop is + assigned a message-id of "1", the second is assigned "2", and so on, + so that the n'th message in a maildrop is assigned a message-id of + "n". In POP3 commands and responses, all message-id's and message + sizes are expressed in base-10 (i.e., decimal). + + It sets the "highest number accessed" to be that of the last message + referenced by the RETR command. + + Here are summaries for the three POP3 commands discussed thus far: + + USER name + Arguments: a server specific user-id (required) + Restrictions: may only be given in the AUTHORIZATION + state after the POP3 greeting or after an + unsuccessful USER or PASS command + Possible Responses: + +OK name is welcome here + -ERR never heard of name + Examples: + C: USER mrose + S: +OK mrose is a real hoopy frood + + + +Rose [Page 4] + +RFC 1460 POP3 June 1993 + + + ... + C: USER frated + S: -ERR sorry, frated doesn't get his mail here + + PASS string + Arguments: a server/user-id specific password (required) + Restrictions: may only be given in the AUTHORIZATION + state after a successful USER command + 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: +OK mrose's maildrop has 2 messages + (320 octets) + ... + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + S: -ERR unable to lock mrose's maildrop, file + already locked + + 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 burst 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. + + Here are the POP3 commands valid in the TRANSACTION state: + + STAT + Arguments: none + Restrictions: may only be given in the TRANSACTION state. + + + +Rose [Page 5] + +RFC 1460 POP3 June 1993 + + + 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 first octets present must indicate the number of + messages in the maildrop. Following this is 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-id (optionally) If a message-id is + given, it 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 "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 + + + +Rose [Page 6] + +RFC 1460 POP3 June 1993 + + + containing information for that message. This line + is called a "scan listing" for that message. + + In order to simplify parsing, all POP3 servers are + required to use a certain format for scan listings. + The first octets present must be the message-id of + the message. Following the message-id is the size of + the message in octets. 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 + 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-id (required) This message-id 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 + + + +Rose [Page 7] + +RFC 1460 POP3 June 1993 + + + given message-id, being careful to byte-stuff the + termination character (as with all multi-line + responses). + + If the number associated with this message is higher + than the "highest number accessed" in the maildrop, the + POP3 server updates the "highest number accessed" to + the number associated with this message. + + Possible Responses: + +OK message follows + -ERR no such message + Examples: + C: RETR 1 + S: +OK 120 octets + S: + S: . + + DELE msg + Arguments: a message-id (required) This message-id + may NOT refer to a message marked as deleted. + Restrictions: may only be given in the TRANSACTION state. + Discussion: + + The POP3 server marks the message as deleted. Any + future reference to the message-id 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. + + If the number associated with this message is higher + than the "highest number accessed" in the maildrop, + the POP3 server updates the "highest number accessed" + to the number associated with this message. + + 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. + + + +Rose [Page 8] + +RFC 1460 POP3 June 1993 + + + Discussion: + + The POP3 server does nothing, it merely replies with a + positive response. + + Possible Responses: + +OK + Examples: + C: NOOP + S: +OK + + LAST + Arguments: none + Restrictions: may only be issued in the TRANSACTION state. + Discussion: + + The POP3 server issues a positive response with a line + containing the highest message number which accessed. + Zero is returned in case no message in the maildrop has + been accessed during previous transactions. A client + may thereafter infer that messages, if any, numbered + greater than the response to the LAST command are + messages not yet accessed by the client. + + Possible Response: + +OK nn + + Examples: + C: STAT + S: +OK 4 320 + C: LAST + S: +OK 1 + C: RETR 3 + S: +OK 120 octets + S: + S: . + C: LAST + S: +OK 3 + C: DELE 2 + S: +OK message 2 deleted + C: LAST + S: +OK 3 + C: RSET + S: +OK + C: LAST + S: +OK 0 + + + + +Rose [Page 9] + +RFC 1460 POP3 June 1993 + + + 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 with a positive response. In addition, the + "highest number accessed" is also reset to zero. + + 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.) + + QUIT + Arguments: none + Restrictions: none + Discussion: + + The POP3 server removes all messages marked as deleted + from the maildrop. It then releases the + exclusive-access lock on the maildrop and replies as + to the success of these operations. The TCP + connection is then closed. + + Possible Responses: + +OK + Examples: + C: QUIT + S: +OK dewey POP3 server signing off (maildrop + empty) + ... + C: QUIT + S: +OK dewey POP3 server signing off (2 messages + left) + ... + + + + + +Rose [Page 10] + +RFC 1460 POP3 June 1993 + + +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-id (required) and a number. This + message-id 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 headers of the message, + the blank line separating the headers from the body, + and then the number of lines 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 10 + S: +OK + S: + S: . + ... + C: TOP 100 + S: -ERR no such message + + + + +Rose [Page 11] + +RFC 1460 POP3 June 1993 + + + APOP name digest + Arguments: a server specific user-id and a digest string + (both required). + Restrictions: may only be given in the AUTHORIZATION + state after the POP3 greeting + 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: + + + + 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 secret. This + + + +Rose [Page 12] + +RFC 1460 POP3 June 1993 + + + 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. + + 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 "tanstaaf". + Hence, the MD5 algorithm is applied to the string + + <1896.697170952@dbc.mtview.ca.us>tanstaaf + + which produces a digest value of + + c4c9334bac560ecc979e58001b3e22fb + +8. 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 + LAST + RSET + + + + +Rose [Page 13] + +RFC 1460 POP3 June 1993 + + + QUIT valid in the UPDATE state + + Optional POP3 Commands: + APOP name digest valid in the AUTHORIZATION state + + TOP msg n valid in the TRANSACTION state + + POP3 Replies: + +OK + -ERR + + Note that with the exception of the STAT command, 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. + +9. Example POP3 Session + + S: + ... + C: + 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: + S: . + C: DELE 1 + S: +OK message 1 deleted + C: RETR 2 + S: +OK 200 octets + S: + S: . + C: DELE 2 + S: +OK message 2 deleted + C: QUIT + S: +OK dewey POP3 server signing off (maildrop empty) + C: + S: + + + + +Rose [Page 14] + +RFC 1460 POP3 June 1993 + + +10. 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 byte 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 client + can calculate the size of each message in octets when it parses the + maildrop into messages. 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 be counted twice, since the POP3 + client will remove all byte-stuffed termination characters when it + receives a multi-line response. + +11. The POP and the Split-UA model + + The underlying paradigm in which the POP3 functions is that of a + split-UA model. The POP3 client host, being a remote PC based + workstation, acts solely as a client to the message transport system. + It does not provide delivery/authentication services to others. + Hence, it is acting as a UA, on behalf of the person using the + workstation. Furthermore, the workstation uses SMTP to enter mail + into the MTS. + + In this sense, we have two UA functions which interface to the + message transport system: Posting (SMTP) and Retrieval (POP3). The + entity which supports this type of environment is called a split-UA + (since the user agent is split between two hosts which must + interoperate to provide these functions). + + ASIDE: Others might term this a remote-UA instead. + There are arguments supporting the use of both terms. + + This memo has explicitly referenced TCP as the underlying transport + agent for the POP3. This need not be the case. In the MZnet split- + UA, for example, personal micro-computer systems are used which do + not have IP-style networking capability [MZnet]. To connect to the + POP3 server host, a PC establishes a terminal connection using some + simple protocol (PhoneNet). A program on the PC drives the + connection, first establishing a login session as a normal user. The + login shell for this pseudo-user is a program which drives the other + half of the terminal protocol and communicates with one of two + servers. Although MZnet can support several PCs, a single pseudo- + user login is present on the server host. The user-id and password + + + +Rose [Page 15] + +RFC 1460 POP3 June 1993 + + + for this pseudo-user login is known to all members of MZnet. Hence, + the first action of the login shell, after starting the terminal + protocol, is to demand a USER/PASS authorization pair from the PC. + This second level of authorization is used to ascertain who is + interacting with the MTS. Although the server host is deemed to + support a "trusted" MTS entity, PCs in MZnet are not. Naturally, the + USER/PASS authorization pair for a PC is known only to the owner of + the PC (in theory, at least). + + After successfully verifying the identity of the client, a modified + SMTP server is started, and the PC posts mail with the server host. + After the QUIT command is given to the SMTP server and it terminates, + a modified POP3 server is started, and the PC retrieves mail from the + server host. After the QUIT command is given to the POP3 server and + it terminates, the login shell for the pseudo-user terminates the + terminal protocol and logs the job out. The PC then closes the + terminal connection to the server host. + + The SMTP server used by MZnet is modified in the sense that it knows + that it's talking to a user agent and not a "trusted" entity in the + message transport system. Hence, it does performs the validation + activities normally performed by an entity in the MTS when it accepts + a message from a UA. + + The POP3 server used by MZnet is modified in the sense that it does + not require a USER/PASS combination before entering the TRANSACTION + state. The reason for this (of course) is that the PC has already + identified itself during the second-level authorization step + described above. + + NOTE: Truth in advertising laws require that the author + of this memo state that MZnet has not actually been + fully implemented. The concepts presented and proven + by the project led to the notion of the MZnet + split-slot model. This notion has inspired the + split-UA concept described in this memo, led to the + author's interest in the POP, and heavily influenced + the the description of the POP3 herein. + + In fact, some UAs present in the Internet already support the notion + of posting directly to an SMTP server and retrieving mail directly + from a POP3 server, even if the POP3 server and client resided on the + same host! + + ASIDE: this discussion raises an issue which this memo + purposedly avoids: how does SMTP know that it's talking + to a "trusted" MTS entity? + + + + +Rose [Page 16] + +RFC 1460 POP3 June 1993 + + +12. References + + [MZnet] Stefferud, E., Sweet, J., and T. Domae, "MZnet: Mail + Service for Personal Micro-Computer Systems,: + Proceedings, IFIP 6.5 International Conference on + Computer Message Systems, Nottingham, U.K., May 1984. + + [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", MIT + Laboratory for Computer Science, April 1992. + +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 must not allow both methods of access for a given user; that + is, for a given "USER name" either the PASS or APOP command is + allowed, but not both. + + 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 [RFC1225], 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. + +15. Author's Address + + Marshall T. Rose + Dover Beach Consulting, Inc. + Mountain View, CA 94043-2186 + + Phone: +1 415 968 1052 + Fax: +1 415 968 2510 + + EMail: mrose@dbc.mtview.ca.us + X.500: rose, dbc, us + + + +Rose [Page 17] + \ No newline at end of file diff --git a/RFC/rfc1521.txt b/RFC/rfc1521.txt new file mode 100644 index 00000000..cb4ee75a --- /dev/null +++ b/RFC/rfc1521.txt @@ -0,0 +1,4539 @@ + + + + + + +Network Working Group N. Borenstein +Request for Comments: 1521 Bellcore +Obsoletes: 1341 N. Freed +Category: Standards Track Innosoft + September 1993 + + + MIME (Multipurpose Internet Mail Extensions) Part One: + Mechanisms for Specifying and Describing + the Format of Internet Message Bodies + +Status of this Memo + + This RFC 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" 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 which + specifies considerable detail about message headers, but which leaves + the message content, or message body, as flat ASCII text. This + document redefines the format of message bodies to allow multi-part + textual and non-textual message bodies to be represented and + exchanged without loss of information. This is based on earlier work + documented in RFC 934 and STD 11, RFC 1049, but extends and revises + that work. Because RFC 822 said so little about message bodies, this + document is largely orthogonal to (rather than a revision of) RFC + 822. + + In particular, this document is designed to provide facilities to + include multiple objects in a single message, to represent body text + in character sets other than US-ASCII, to represent formatted multi- + font text messages, to represent non-textual material such as images + and audio fragments, and generally to facilitate later extensions + defining new types of Internet mail for use by cooperating mail + agents. + + This document does NOT extend Internet mail header fields to permit + anything other than US-ASCII text data. Such extensions are the + subject of a companion document [RFC-1522]. + + This document is a revision of RFC 1341. Significant differences + from RFC 1341 are summarized in Appendix H. + + + + + +Borenstein & Freed [Page 1] + +RFC 1521 MIME September 1993 + + +Table of Contents + + 1. Introduction....................................... 3 + 2. Notations, Conventions, and Generic BNF Grammar.... 6 + 3. The MIME-Version Header Field...................... 7 + 4. The Content-Type Header Field...................... 9 + 5. The Content-Transfer-Encoding Header Field......... 13 + 5.1. Quoted-Printable Content-Transfer-Encoding......... 18 + 5.2. Base64 Content-Transfer-Encoding................... 21 + 6. Additional Content-Header Fields................... 23 + 6.1. Optional Content-ID Header Field................... 23 + 6.2. Optional Content-Description Header Field.......... 24 + 7. The Predefined Content-Type Values................. 24 + 7.1. The Text Content-Type.............................. 24 + 7.1.1. The charset parameter.............................. 25 + 7.1.2. The Text/plain subtype............................. 28 + 7.2. The Multipart Content-Type......................... 28 + 7.2.1. Multipart: The common syntax...................... 29 + 7.2.2. The Multipart/mixed (primary) subtype.............. 34 + 7.2.3. The Multipart/alternative subtype.................. 34 + 7.2.4. The Multipart/digest subtype....................... 36 + 7.2.5. The Multipart/parallel subtype..................... 37 + 7.2.6. Other Multipart subtypes........................... 37 + 7.3. The Message Content-Type........................... 38 + 7.3.1. The Message/rfc822 (primary) subtype............... 38 + 7.3.2. The Message/Partial subtype........................ 39 + 7.3.3. The Message/External-Body subtype.................. 42 + 7.3.3.1. The "ftp" and "tftp" access-types............... 44 + 7.3.3.2. The "anon-ftp" access-type...................... 45 + 7.3.3.3. The "local-file" and "afs" access-types......... 45 + 7.3.3.4. The "mail-server" access-type................... 45 + 7.3.3.5. Examples and Further Explanations............... 46 + 7.4. The Application Content-Type....................... 49 + 7.4.1. The Application/Octet-Stream (primary) subtype..... 50 + 7.4.2. The Application/PostScript subtype................. 50 + 7.4.3. Other Application subtypes......................... 53 + 7.5. The Image Content-Type............................. 53 + 7.6. The Audio Content-Type............................. 54 + 7.7. The Video Content-Type............................. 54 + 7.8. Experimental Content-Type Values................... 54 + 8. Summary............................................ 56 + 9. Security Considerations............................ 56 + 10. Authors' Addresses................................. 57 + 11. Acknowledgements................................... 58 + Appendix A -- Minimal MIME-Conformance.................... 60 + Appendix B -- General Guidelines For Sending Email Data... 63 + Appendix C -- A Complex Multipart Example................. 66 + Appendix D -- Collected Grammar........................... 68 + + + +Borenstein & Freed [Page 2] + +RFC 1521 MIME September 1993 + + + Appendix E -- IANA Registration Procedures................ 72 + E.1 Registration of New Content-type/subtype Values...... 72 + E.2 Registration of New Access-type Values + for Message/external-body............................ 73 + Appendix F -- Summary of the Seven Content-types.......... 74 + Appendix G -- Canonical Encoding Model.................... 76 + Appendix H -- Changes from RFC 1341....................... 78 + References................................................ 80 + +1. Introduction + + Since its publication in 1982, STD 11, RFC 822 [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 STD 10, RFC 821 [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 + [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. + + One of the notable limitations of RFC 821/822 based mail systems is + the fact that they limit the contents of electronic mail messages to + relatively short lines of seven-bit ASCII. This forces users to + convert any non-textual data that they may wish to send into seven- + bit bytes representable as printable ASCII characters before invoking + a local mail UA (User Agent, a program with which human users send + and receive mail). Examples of such encodings currently used in the + Internet include pure hexadecimal, uuencode, the 3-in-4 base 64 + scheme specified in RFC 1421, the Andrew Toolkit Representation + [ATK], and many others. + + The limitations of RFC 822 mail become even more apparent as gateways + are designed to allow for the exchange of mail messages between RFC + 822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for the + inclusion of non-textual body parts within electronic mail messages. + The current standards for the mapping of X.400 messages to RFC 822 + messages specify either that X.400 non-textual body parts must be + converted to (not encoded in) an ASCII format, or that they must be + discarded, notifying the RFC 822 user that discarding has occurred. + This is clearly undesirable, as information that a user may wish to + + + +Borenstein & Freed [Page 3] + +RFC 1521 MIME September 1993 + + + receive is lost. Even though a user's UA may not have the capability + of dealing with the non-textual body part, the user might have some + mechanism external to the UA that can extract useful information from + the body part. Moreover, it does not allow for the fact that the + message may eventually be gatewayed back into an X.400 message + handling system (i.e., the X.400 message is "tunneled" through + Internet mail), where the non-textual information would definitely + become useful again. + + This document describes several mechanisms that combine to solve most + of these problems without introducing any serious incompatibilities + with the existing world of RFC 822 mail. In particular, it + describes: + + 1. A MIME-Version header field, which uses a version number to + declare a message to be conformant with this specification and + allows mail processing agents to distinguish between such + messages and those generated by older or non-conformant software, + which is presumed to lack such a field. + + 2. A Content-Type header field, generalized from RFC 1049 [RFC-1049], + which can be used to specify the type and subtype of data in the + body of a message and to fully specify the native representation + (encoding) of such data. + + 2.a. A "text" Content-Type value, which can be used to represent + textual information in a number of character sets and + formatted text description languages in a standardized + manner. + + 2.b. A "multipart" Content-Type value, which can be used to + combine several body parts, possibly of differing types of + data, into a single message. + + 2.c. An "application" Content-Type value, which can be used to + transmit application data or binary data, and hence, among + other uses, to implement an electronic mail file transfer + service. + + 2.d. A "message" Content-Type value, for encapsulating another + mail message. + + 2.e An "image" Content-Type value, for transmitting still image + (picture) data. + + 2.f. An "audio" Content-Type value, for transmitting audio or + voice data. + + + + +Borenstein & Freed [Page 4] + +RFC 1521 MIME September 1993 + + + 2.g. A "video" Content-Type value, for transmitting video or + moving image data, possibly with audio as part of the + composite video data format. + + 3. A Content-Transfer-Encoding header field, which can be used to + specify an auxiliary encoding that was applied to the data in + order to allow it to pass through mail transport mechanisms which + may have data or character set limitations. + + 4. Two additional header fields that can be used to further describe + the data in a message body, the Content-ID and Content- + Description header fields. + + MIME has been carefully designed as an extensible mechanism, and it + is expected that the set of content-type/subtype pairs and their + associated parameters will grow significantly with time. Several + other MIME fields, notably including character set names, are likely + to have new values defined over time. In order to ensure that the + set of such values is developed in an orderly, well-specified, and + public manner, MIME defines a registration process which uses the + Internet Assigned Numbers Authority (IANA) as a central registry for + such values. Appendix E provides details about how IANA registration + is accomplished. + + Finally, to specify and promote interoperability, Appendix A of this + document provides a basic applicability statement for a subset of the + above mechanisms that defines a minimal level of "conformance" with + this document. + + HISTORICAL NOTE: Several of the mechanisms described in this + document may seem somewhat strange or even baroque at first + reading. It is important to note that compatibility with existing + standards AND robustness across existing practice were two of the + highest priorities of the working group that developed this + document. In particular, compatibility was always favored over + elegance. + + MIME was first defined and published as RFCs 1341 and 1342 [RFC-1341] + [RFC-1342]. This document is a relatively minor updating of RFC + 1341, and is intended to supersede it. The differences between this + document and RFC 1341 are summarized in Appendix H. Please refer to + the current edition of the "IAB Official Protocol Standards" for the + standardization state and status of this protocol. Several other RFC + documents will be of interest to the MIME implementor, in particular + [RFC 1343], [RFC-1344], and [RFC-1345]. + + + + + + +Borenstein & Freed [Page 5] + +RFC 1521 MIME September 1993 + + +2. Notations, Conventions, and Generic BNF Grammar + + This document is being published in two versions, one as plain ASCII + text and one as PostScript (PostScript is a trademark of Adobe + Systems Incorporated.). While the text version is the official + specification, some will find the PostScript version easier to read. + The textual contents are identical. An Andrew-format copy of this + document is also available from the first author (Borenstein). + + Although the mechanisms specified in this document are all described + in prose, most are also described formally in the modified BNF + notation of RFC 822. Implementors will need to be familiar with this + notation in order to understand this specification, and are referred + to RFC 822 for a complete explanation of the modified BNF notation. + + Some of the modified BNF in this document makes reference to + syntactic entities that are defined in RFC 822 and not in this + document. A complete formal grammar, then, is obtained by combining + the collected grammar appendix of this document with that of RFC 822 + plus the modifications to RFC 822 defined in RFC 1123, which + specifically changes the syntax for `return', `date' and `mailbox'. + + The term CRLF, in this document, refers to the sequence of the two + ASCII characters CR (13) and LF (10) which, taken together, in this + order, denote a line break in RFC 822 mail. + + The term "character set" is used in this document to refer to a + method used with one or more tables to convert encoded text to a + series of octets. This definition is intended to allow various kinds + of text encodings, from simple single-table mappings such as ASCII to + complex table switching methods such as those that use ISO 2022's + techniques. However, a MIME character set name must fully specify + the mapping to be performed. + + The term "message", when not further qualified, means either the + (complete or "top-level") message being transferred on a network, or + a message encapsulated in a body of type "message". + + The term "body part", in this document, means one of the parts of the + body of a multipart entity. A body part has a header and a body, so + it makes sense to speak about the body of a body part. + + The term "entity", in this document, means either a message or a body + part. All kinds of entities share the property that they have a + header and a body. + + The term "body", when not further qualified, means the body of an + entity, that is the body of either a message or of a body part. + + + +Borenstein & Freed [Page 6] + +RFC 1521 MIME September 1993 + + + NOTE: The previous four definitions are clearly circular. This is + unavoidable, since the overall structure of a MIME message is + indeed recursive. + + In this document, all numeric and octet values are given in decimal + notation. + + It must be noted that Content-Type values, subtypes, and parameter + names as defined in this document are case-insensitive. However, + parameter values are case-sensitive unless otherwise specified for + the specific parameter. + + FORMATTING NOTE: This document has been carefully formatted for + ease of reading. The PostScript version of this document, in + particular, places notes like this one, which may be skipped by + the reader, in a smaller, italicized, font, and indents it as + well. In the text version, only the indentation is preserved, so + if you are reading the text version of this you might consider + using the PostScript version instead. However, all such notes will + be indented and preceded by "NOTE:" or some similar introduction, + even in the text version. + + The primary purpose of these non-essential notes is to convey + information about the rationale of this document, or to place this + document in the proper historical or evolutionary context. Such + information may be skipped by those who are focused entirely on + building a conformant implementation, but may be of use to those + who wish to understand why this document is written as it is. + + For ease of recognition, all BNF definitions have been placed in a + fixed-width font in the PostScript version of this document. + +3. The MIME-Version Header Field + + Since RFC 822 was published in 1982, there has really been only one + format standard for Internet messages, and there has been little + perceived need to declare the format standard in use. This document + is an independent document that complements RFC 822. Although the + extensions in this document have been defined in such a way as to be + compatible with RFC 822, there are still circumstances in which it + might be desirable for a mail-processing agent to know whether a + message was composed with the new standard in mind. + + Therefore, this document defines a new header field, "MIME-Version", + which is to be used to declare the version of the Internet message + body format standard in use. + + Messages composed in accordance with this document MUST include such + + + +Borenstein & Freed [Page 7] + +RFC 1521 MIME September 1993 + + + a header field, with the following verbatim text: + + MIME-Version: 1.0 + + The presence of this header field is an assertion that the message + has been composed in compliance with this document. + + Since it is possible that a future document might extend the message + format standard again, a formal BNF is given for the content of the + MIME-Version field: + + version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT + + Thus, future format specifiers, which might replace or extend "1.0", + are constrained to be two integer fields, separated by a period. If + a message is received with a MIME-version value other than "1.0", it + cannot be assumed to conform with this specification. + + Note that the MIME-Version header field is required at the top level + of a message. It is not required for each body part of a multipart + entity. It is required for the embedded headers of a body of type + "message" if and only if the embedded message is itself claimed to be + MIME-conformant. + + It is not possible to fully specify how a mail reader that conforms + with MIME as defined in this document should treat a message that + might arrive in the future with some value of MIME-Version other than + "1.0". However, conformant software is encouraged to check the + version number and at least warn the user if an unrecognized MIME- + version is encountered. + + It is also worth noting that version control for specific content- + types is not accomplished using the MIME-Version mechanism. In + particular, some formats (such as application/postscript) have + version numbering conventions that are internal to the document + format. Where such conventions exist, MIME does nothing to supersede + them. Where no such conventions exist, a MIME type might use a + "version" parameter in the content-type field if necessary. + + NOTE TO IMPLEMENTORS: All header fields defined in this document, + including MIME-Version, Content-type, etc., are subject to the + general syntactic rules for header fields specified in RFC 822. In + particular, all can include comments, which means that the following + two MIME-Version fields are equivalent: + + MIME-Version: 1.0 + MIME-Version: 1.0 (Generated by GBD-killer 3.7) + + + + +Borenstein & Freed [Page 8] + +RFC 1521 MIME September 1993 + + +4. The Content-Type Header Field + + The purpose of the Content-Type field is to describe the data + contained in the body fully enough that the receiving user agent can + pick an appropriate agent or mechanism to present the data to the + user, or otherwise deal with the data in an appropriate manner. + + HISTORICAL NOTE: The Content-Type header field was first defined in + RFC 1049. RFC 1049 Content-types used a simpler and less powerful + syntax, but one that is largely compatible with the mechanism given + here. + + The Content-Type header field is used to specify the nature of the + data in the body of an entity, by giving type and subtype + identifiers, and by providing auxiliary information that may be + required for certain types. After the type and subtype names, the + remainder of the header field is simply a set of parameters, + specified in an attribute/value notation. The set of meaningful + parameters differs for the different types. In particular, there are + NO globally-meaningful parameters that apply to all content-types. + Global mechanisms are best addressed, in the MIME model, by the + definition of additional Content-* header fields. The ordering of + parameters is not significant. Among the defined parameters is a + "charset" parameter by which the character set used in the body may + be declared. Comments are allowed in accordance with RFC 822 rules + for structured header fields. + + In general, the top-level Content-Type is used to declare the general + type of data, while the subtype specifies a specific format for that + type of data. Thus, a Content-Type of "image/xyz" is enough to tell + a user agent that the data is an image, even if the user agent has no + knowledge of the specific image format "xyz". Such information can + be used, for example, to decide whether or not to show a user the raw + data from an unrecognized subtype -- such an action might be + reasonable for unrecognized subtypes of text, but not for + unrecognized subtypes of image or audio. For this reason, registered + subtypes of audio, image, text, and video, should not contain + embedded information that is really of a different type. Such + compound types should be represented using the "multipart" or + "application" types. + + Parameters are modifiers of the content-subtype, and do not + fundamentally affect the requirements of the host system. Although + most parameters make sense only with certain content-types, others + are "global" in the sense that they might apply to any subtype. For + example, the "boundary" parameter makes sense only for the + "multipart" content-type, but the "charset" parameter might make + sense with several content-types. + + + +Borenstein & Freed [Page 9] + +RFC 1521 MIME September 1993 + + + An initial set of seven Content-Types is defined by this document. + This set of top-level names is intended to be substantially complete. + It is expected that additions to the larger set of supported types + can generally be accomplished by the creation of new subtypes of + these initial types. In the future, more top-level types may be + defined only by an extension to this standard. If another primary + type is to be used for any reason, it must be given a name starting + with "X-" to indicate its non-standard status and to avoid a + potential conflict with a future official name. + + In the Augmented BNF notation of RFC 822, a Content-Type header field + value is defined as follows: + + content := "Content-Type" ":" type "/" subtype *(";" + parameter) + ; case-insensitive matching of type and subtype + + type := "application" / "audio" + / "image" / "message" + / "multipart" / "text" + / "video" / extension-token + ; All values case-insensitive + + extension-token := x-token / iana-token + + iana-token := + + x-token := + + subtype := token ; case-insensitive + + parameter := attribute "=" value + + attribute := token ; case-insensitive + + value := token / quoted-string + + token := 1* + + tspecials := "(" / ")" / "<" / ">" / "@" + / "," / ";" / ":" / "\" / <"> + / "/" / "[" / "]" / "?" / "=" + ; Must be in quoted-string, + ; to use within parameter values + + + +Borenstein & Freed [Page 10] + +RFC 1521 MIME September 1993 + + + Note that the definition of "tspecials" is the same as the RFC 822 + definition of "specials" with the addition of the three characters + "/", "?", and "=", and the removal of ".". + + Note also that a subtype specification is MANDATORY. There are no + default subtypes. + + The type, subtype, and parameter names are not case sensitive. For + example, TEXT, Text, and TeXt are all equivalent. Parameter values + are normally case sensitive, but certain parameters are interpreted + to be case-insensitive, depending on the intended use. (For example, + multipart boundaries are case-sensitive, but the "access-type" for + message/External-body is not case-sensitive.) + + Beyond this syntax, the only constraint on the definition of subtype + names is the desire that their uses must not conflict. That is, it + would be undesirable to have two different communities using + "Content-Type: application/foobar" to mean two different things. The + process of defining new content-subtypes, then, is not intended to be + a mechanism for imposing restrictions, but simply a mechanism for + publicizing the usages. There are, therefore, two acceptable + mechanisms for defining new Content-Type subtypes: + + 1. Private values (starting with "X-") may be + defined bilaterally between two cooperating + agents without outside registration or + standardization. + + 2. New standard values must be documented, + registered with, and approved by IANA, as + described in Appendix E. Where intended for + public use, the formats they refer to must + also be defined by a published specification, + and possibly offered for standardization. + + The seven standard initial predefined Content-Types are detailed in + the bulk of this document. They are: + + text -- textual information. The primary subtype, + "plain", indicates plain (unformatted) text. No + special software is required to get the full + meaning of the text, aside from support for the + indicated character set. Subtypes are to be used + for enriched text in forms where application + software may enhance the appearance of the text, + but such software must not be required in order to + get the general idea of the content. Possible + subtypes thus include any readable word processor + + + +Borenstein & Freed [Page 11] + +RFC 1521 MIME September 1993 + + + format. A very simple and portable subtype, + richtext, was defined in RFC 1341, with a future + revision expected. + + multipart -- data consisting of multiple parts of + independent data types. Four initial subtypes + are defined, including the primary "mixed" + subtype, "alternative" for representing the same + data in multiple formats, "parallel" for parts + intended to be viewed simultaneously, and "digest" + for multipart entities in which each part is of + type "message". + + message -- an encapsulated message. A body of + Content-Type "message" is itself all or part of a + fully formatted RFC 822 conformant message which + may contain its own different Content-Type header + field. The primary subtype is "rfc822". The + "partial" subtype is defined for partial messages, + to permit the fragmented transmission of bodies + that are thought to be too large to be passed + through mail transport facilities. Another + subtype, "External-body", is defined for + specifying large bodies by reference to an + external data source. + + image -- image data. Image requires a display device + (such as a graphical display, a printer, or a FAX + machine) to view the information. Initial + subtypes are defined for two widely-used image + formats, jpeg and gif. + + audio -- audio data, with initial subtype "basic". + Audio requires an audio output device (such as a + speaker or a telephone) to "display" the contents. + + video -- video data. Video requires the capability to + display moving images, typically including + specialized hardware and software. The initial + subtype is "mpeg". + + application -- some other kind of data, typically + either uninterpreted binary data or information to + be processed by a mail-based application. The + primary subtype, "octet-stream", is to be used in + the case of uninterpreted binary data, in which + case the simplest recommended action is to offer + to write the information into a file for the user. + + + +Borenstein & Freed [Page 12] + +RFC 1521 MIME September 1993 + + + An additional subtype, "PostScript", is defined + for transporting PostScript documents in bodies. + Other expected uses for "application" include + spreadsheets, data for mail-based scheduling + systems, and languages for "active" + (computational) email. (Note that active email + and other application data may entail several + security considerations, which are discussed later + in this memo, particularly in the context of + application/PostScript.) + + Default RFC 822 messages are typed by this protocol as plain text in + the US-ASCII character set, which can be explicitly specified as + "Content-type: text/plain; charset=us-ascii". If no Content-Type is + specified, this default is assumed. In the presence of a MIME- + Version header field, a receiving User Agent can also assume that + plain US-ASCII text was the sender's intent. In the absence of a + MIME-Version specification, plain US-ASCII text must still be + assumed, but the sender's intent might have been otherwise. + + RATIONALE: In the absence of any Content-Type header field or + MIME-Version header field, it is impossible to be certain that a + message is actually text in the US-ASCII character set, since it + might well be a message that, using the conventions that predate + this document, includes text in another character set or non- + textual data in a manner that cannot be automatically recognized + (e.g., a uuencoded compressed UNIX tar file). Although there is + no fully acceptable alternative to treating such untyped messages + as "text/plain; charset=us-ascii", implementors should remain + aware that if a message lacks both the MIME-Version and the + Content-Type header fields, it may in practice contain almost + anything. + + It should be noted that the list of Content-Type values given here + may be augmented in time, via the mechanisms described above, and + that the set of subtypes is expected to grow substantially. + + When a mail reader encounters mail with an unknown Content-type + value, it should generally treat it as equivalent to + "application/octet-stream", as described later in this document. + +5. The Content-Transfer-Encoding Header Field + + Many Content-Types which could usefully be transported via email are + represented, in their "natural" format, as 8-bit character or binary + data. Such data cannot be transmitted over some transport protocols. + For example, RFC 821 restricts mail messages to 7-bit US-ASCII data + with lines no longer than 1000 characters. + + + +Borenstein & Freed [Page 13] + +RFC 1521 MIME September 1993 + + + It is necessary, therefore, to define a standard mechanism for re- + encoding such data into a 7-bit short-line format. This document + specifies that such encodings will be indicated by a new "Content- + Transfer-Encoding" header field. The Content-Transfer-Encoding field + is used to indicate the type of transformation that has been used in + order to represent the body in an acceptable manner for transport. + + Unlike Content-Types, a proliferation of Content-Transfer-Encoding + values is undesirable and unnecessary. However, establishing only a + single Content-Transfer-Encoding mechanism does not seem possible. + There is a tradeoff between the desire for a compact and efficient + encoding of largely-binary data and the desire for a readable + encoding of data that is mostly, but not entirely, 7-bit data. For + this reason, at least two encoding mechanisms are necessary: a + "readable" encoding and a "dense" encoding. + + The Content-Transfer-Encoding field is designed to specify an + invertible mapping between the "native" representation of a type of + data and a representation that can be readily exchanged using 7 bit + mail transport protocols, such as those defined by RFC 821 (SMTP). + This field has not been defined by any previous standard. The field's + value is a single token specifying the type of encoding, as + enumerated below. Formally: + + encoding := "Content-Transfer-Encoding" ":" mechanism + + mechanism := "7bit" ; case-insensitive + / "quoted-printable" + / "base64" + / "8bit" + / "binary" + / x-token + + These values are not case sensitive. That is, Base64 and BASE64 and + bAsE64 are all equivalent. An encoding type of 7BIT requires that + the body is already in a seven-bit mail-ready representation. This + is the default value -- that is, "Content-Transfer-Encoding: 7BIT" is + assumed if the Content-Transfer-Encoding header field is not present. + + The values "8bit", "7bit", and "binary" all mean that NO encoding has + been performed. However, they are potentially useful as indications + of the kind of data contained in the object, and therefore of the + kind of encoding that might need to be performed for transmission in + a given transport system. In particular: + + "7bit" means that the data is all represented as short + lines of US-ASCII data. + + + + +Borenstein & Freed [Page 14] + +RFC 1521 MIME September 1993 + + + "8bit" means that the lines are short, but there may be + non-ASCII characters (octets with the high-order + bit set). + + "Binary" means that not only may non-ASCII characters + be present, but also that the lines are not + necessarily short enough for SMTP transport. + + The difference between "8bit" (or any other conceivable bit-width + token) and the "binary" token is that "binary" does not require + adherence to any limits on line length or to the SMTP CRLF semantics, + while the bit-width tokens do require such adherence. If the body + contains data in any bit-width other than 7-bit, the appropriate + bit-width Content-Transfer-Encoding token must be used (e.g., "8bit" + for unencoded 8 bit wide data). If the body contains binary data, + the "binary" Content-Transfer-Encoding token must be used. + + NOTE: The distinction between the Content-Transfer-Encoding values + of "binary", "8bit", etc. may seem unimportant, in that all of + them really mean "none" -- that is, there has been no encoding of + the data for transport. However, clear labeling will be of + enormous value to gateways between future mail transport systems + with differing capabilities in transporting data that do not meet + the restrictions of RFC 821 transport. + + Mail transport for unencoded 8-bit data is defined in RFC-1426 + [RFC-1426]. As of the publication of this document, there are no + standardized Internet mail transports for which it is legitimate + to include unencoded binary data in mail bodies. Thus there are + no circumstances in which the "binary" Content-Transfer-Encoding + is actually legal on the Internet. However, in the event that + binary mail transport becomes a reality in Internet mail, or when + this document is used in conjunction with any other binary-capable + transport mechanism, binary bodies should be labeled as such using + this mechanism. + + NOTE: The five values defined for the Content-Transfer-Encoding + field imply nothing about the Content-Type other than the + algorithm by which it was encoded or the transport system + requirements if unencoded. + + Implementors may, if necessary, define new Content-Transfer-Encoding + values, but must use an x-token, which is a name prefixed by "X-" to + indicate its non-standard status, e.g., "Content-Transfer-Encoding: + x-my-new-encoding". However, unlike Content-Types and subtypes, the + creation of new Content-Transfer-Encoding values is explicitly and + strongly discouraged, as it seems likely to hinder interoperability + with little potential benefit. Their use is allowed only as the + + + +Borenstein & Freed [Page 15] + +RFC 1521 MIME September 1993 + + + result of an agreement between cooperating user agents. + + If a Content-Transfer-Encoding header field appears as part of a + message header, it applies to the entire body of that message. If a + Content-Transfer-Encoding header field appears as part of a body + part's headers, it applies only to the body of that body part. If an + entity is of type "multipart" or "message", the Content-Transfer- + Encoding is not permitted to have any value other than a bit width + (e.g., "7bit", "8bit", etc.) or "binary". + + It should be noted that email is character-oriented, so that the + mechanisms described here are mechanisms for encoding arbitrary octet + streams, not bit streams. If a bit stream is to be encoded via one + of these mechanisms, it must first be converted to an 8-bit byte + stream using the network standard bit order ("big-endian"), in which + the earlier bits in a stream become the higher-order bits in a byte. + A bit stream not ending at an 8-bit boundary must be padded with + zeroes. This document provides a mechanism for noting the addition + of such padding in the case of the application Content-Type, which + has a "padding" parameter. + + The encoding mechanisms defined here explicitly encode all data in + ASCII. Thus, for example, suppose an entity has header fields such + as: + + Content-Type: text/plain; charset=ISO-8859-1 + Content-transfer-encoding: base64 + + This must be interpreted to mean that the body is a base64 ASCII + encoding of data that was originally in ISO-8859-1, and will be in + that character set again after decoding. + + The following sections will define the two standard encoding + mechanisms. The definition of new content-transfer-encodings is + explicitly discouraged and should only occur when absolutely + necessary. All content-transfer-encoding namespace except that + beginning with "X-" is explicitly reserved to the IANA for future + use. Private agreements about content-transfer-encodings are also + explicitly discouraged. + + Certain Content-Transfer-Encoding values may only be used on certain + Content-Types. In particular, it is expressly forbidden to use any + encodings other than "7bit", "8bit", or "binary" with any Content- + Type that recursively includes other Content-Type fields, notably the + "multipart" and "message" Content-Types. All encodings that are + desired for bodies of type multipart or message must be done at the + innermost level, by encoding the actual body that needs to be + encoded. + + + +Borenstein & Freed [Page 16] + +RFC 1521 MIME September 1993 + + + NOTE ON ENCODING RESTRICTIONS: Though the prohibition against + using content-transfer-encodings on data of type multipart or + message may seem overly restrictive, it is necessary to prevent + nested encodings, in which data are passed through an encoding + algorithm multiple times, and must be decoded multiple times in + order to be properly viewed. Nested encodings add considerable + complexity to user agents: aside from the obvious efficiency + problems with such multiple encodings, they can obscure the basic + structure of a message. In particular, they can imply that + several decoding operations are necessary simply to find out what + types of objects a message contains. Banning nested encodings may + complicate the job of certain mail gateways, but this seems less + of a problem than the effect of nested encodings on user agents. + + NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT- + TRANSFER-ENCODING: It may seem that the Content-Transfer-Encoding + could be inferred from the characteristics of the Content-Type + that is to be encoded, or, at the very least, that certain + Content-Transfer-Encodings could be mandated for use with specific + Content-Types. There are several reasons why this is not the case. + First, given the varying types of transports used for mail, some + encodings may be appropriate for some Content-Type/transport + combinations and not for others. (For example, in an 8-bit + transport, no encoding would be required for text in certain + character sets, while such encodings are clearly required for 7- + bit SMTP.) Second, certain Content-Types may require different + types of transfer encoding under different circumstances. For + example, many PostScript bodies might consist entirely of short + lines of 7-bit data and hence require little or no encoding. + Other PostScript bodies (especially those using Level 2 + PostScript's binary encoding mechanism) may only be reasonably + represented using a binary transport encoding. Finally, since + Content-Type is intended to be an open-ended specification + mechanism, strict specification of an association between + Content-Types and encodings effectively couples the specification + of an application protocol with a specific lower-level transport. + This is not desirable since the developers of a Content-Type + should not have to be aware of all the transports in use and what + their limitations are. + + NOTE ON TRANSLATING ENCODINGS: The quoted-printable and base64 + encodings are designed so that conversion between them is + possible. The only issue that arises in such a conversion is the + handling of line breaks. When converting from quoted-printable to + base64 a line break must be converted into a CRLF sequence. + Similarly, a CRLF sequence in base64 data must be converted to a + quoted-printable line break, but ONLY when converting text data. + + + + +Borenstein & Freed [Page 17] + +RFC 1521 MIME September 1993 + + + NOTE ON CANONICAL ENCODING MODEL: There was some confusion, in + earlier drafts of this memo, regarding the model for when email + data was to be converted to canonical form and encoded, and in + particular how this process would affect the treatment of CRLFs, + given that the representation of newlines varies greatly from + system to system, and the relationship between content-transfer- + encodings and character sets. For this reason, a canonical model + for encoding is presented as Appendix G. + +5.1. Quoted-Printable Content-Transfer-Encoding + + The Quoted-Printable encoding is intended to represent data that + largely consists of octets that correspond to printable characters in + the ASCII character set. It encodes the data in such a way that the + resulting octets are unlikely to be modified by mail transport. If + the data being encoded are mostly ASCII text, the encoded form of the + data remains largely recognizable by humans. A body which is + entirely ASCII may also be encoded in Quoted-Printable to ensure the + integrity of the data should the message pass through a character- + translating, and/or line-wrapping gateway. + + In this encoding, octets are to be represented as determined by the + following rules: + + Rule #1: (General 8-bit representation) Any octet, except those + indicating a line break according to the newline convention of the + canonical (standard) form of the data being encoded, may be + represented by an "=" followed by a two digit hexadecimal + representation of the octet's value. The digits of the + hexadecimal alphabet, for this purpose, are "0123456789ABCDEF". + Uppercase letters must be used when sending hexadecimal data, + though a robust implementation may choose to recognize lowercase + letters on receipt. Thus, for example, the value 12 (ASCII form + feed) can be represented by "=0C", and the value 61 (ASCII EQUAL + SIGN) can be represented by "=3D". Except when the following + rules allow an alternative encoding, this rule is mandatory. + + Rule #2: (Literal representation) Octets with decimal values of 33 + through 60 inclusive, and 62 through 126, inclusive, MAY be + represented as the ASCII characters which correspond to those + octets (EXCLAMATION POINT through LESS THAN, and GREATER THAN + through TILDE, respectively). + + Rule #3: (White Space): Octets with values of 9 and 32 MAY be + represented as ASCII TAB (HT) and SPACE characters, respectively, + but MUST NOT be so represented at the end of an encoded line. Any + TAB (HT) or SPACE characters on an encoded line MUST thus be + followed on that line by a printable character. In particular, an + + + +Borenstein & Freed [Page 18] + +RFC 1521 MIME September 1993 + + + "=" at the end of an encoded line, indicating a soft line break + (see rule #5) may follow one or more TAB (HT) or SPACE characters. + It follows that an octet with value 9 or 32 appearing at the end + of an encoded line must be represented according to Rule #1. This + rule is necessary because some MTAs (Message Transport Agents, + programs which transport messages from one user to another, or + perform a part of such transfers) are known to pad lines of text + with SPACEs, and others are known to remove "white space" + characters from the end of a line. Therefore, when decoding a + Quoted-Printable body, any trailing white space on a line must be + deleted, as it will necessarily have been added by intermediate + transport agents. + + Rule #4 (Line Breaks): A line break in a text body, independent of + what its representation is following the canonical representation + of the data being encoded, must be represented by a (RFC 822) line + break, which is a CRLF sequence, in the Quoted-Printable encoding. + Since the canonical representation of types other than text do not + generally include the representation of line breaks, no hard line + breaks (i.e. line breaks that are intended to be meaningful and + to be displayed to the user) should occur in the quoted-printable + encoding of such types. Of course, occurrences of "=0D", "=0A", + "0A=0D" and "=0D=0A" will eventually be encountered. In general, + however, base64 is preferred over quoted-printable for binary + data. + + Note that many implementations may elect to encode the local + representation of various content types directly, as described in + Appendix G. In particular, this may apply to plain text material + on systems that use newline conventions other than CRLF + delimiters. Such an implementation is permissible, but the + generation of line breaks must be generalized to account for the + case where alternate representations of newline sequences are + used. + + Rule #5 (Soft Line Breaks): The Quoted-Printable encoding REQUIRES + that encoded lines be no more than 76 characters long. If longer + lines are to be encoded with the Quoted-Printable encoding, 'soft' + line breaks must be used. An equal sign as the last character on a + encoded line indicates such a non-significant ('soft') line break + in the encoded text. Thus if the "raw" form of the line is a + single unencoded line that says: + + Now's the time for all folk to come to the aid of + their country. + + This can be represented, in the Quoted-Printable encoding, as + + + + +Borenstein & Freed [Page 19] + +RFC 1521 MIME September 1993 + + + Now's the time = + for all folk to come= + to the aid of their country. + + This provides a mechanism with which long lines are encoded in + such a way as to be restored by the user agent. The 76 character + limit does not count the trailing CRLF, but counts all other + characters, including any equal signs. + + Since the hyphen character ("-") is represented as itself in the + Quoted-Printable encoding, care must be taken, when encapsulating a + quoted-printable encoded body in a multipart entity, to ensure that + the encapsulation boundary does not appear anywhere in the encoded + body. (A good strategy is to choose a boundary that includes a + character sequence such as "=_" which can never appear in a quoted- + printable body. See the definition of multipart messages later in + this document.) + + NOTE: The quoted-printable encoding represents something of a + compromise between readability and reliability in transport. + Bodies encoded with the quoted-printable encoding will work + reliably over most mail gateways, but may not work perfectly over + a few gateways, notably those involving translation into EBCDIC. + (In theory, an EBCDIC gateway could decode a quoted-printable body + and re-encode it using base64, but such gateways do not yet + exist.) A higher level of confidence is offered by the base64 + Content-Transfer-Encoding. A way to get reasonably reliable + transport through EBCDIC gateways is to also quote the ASCII + characters + + !"#$@[\]^`{|}~ + + according to rule #1. See Appendix B for more information. + + Because quoted-printable data is generally assumed to be line- + oriented, it is to be expected that the representation of the breaks + between the lines of quoted printable data may be altered in + transport, in the same manner that plain text mail has always been + altered in Internet mail when passing between systems with differing + newline conventions. If such alterations are likely to constitute a + corruption of the data, it is probably more sensible to use the + base64 encoding rather than the quoted-printable encoding. + + WARNING TO IMPLEMENTORS: If binary data are encoded in quoted- + printable, care must be taken to encode CR and LF characters as "=0D" + and "=0A", respectively. In particular, a CRLF sequence in binary + data should be encoded as "=0D=0A". Otherwise, if CRLF were + represented as a hard line break, it might be incorrectly decoded on + + + +Borenstein & Freed [Page 20] + +RFC 1521 MIME September 1993 + + + platforms with different line break conventions. + + For formalists, the syntax of quoted-printable data is described by + the following grammar: + + quoted-printable := ([*(ptext / SPACE / TAB) ptext] ["="] CRLF) + ; Maximum line length of 76 characters excluding CRLF + + ptext := octet / 127, =, SPACE, or TAB, + ; and is recommended for any characters not listed in + ; Appendix B as "mail-safe". + +5.2. Base64 Content-Transfer-Encoding + + The Base64 Content-Transfer-Encoding is designed to represent + arbitrary sequences of octets in a form that need not be humanly + readable. The encoding and decoding algorithms are simple, but the + encoded data are consistently only about 33 percent larger than the + unencoded data. This encoding is virtually identical to the one used + in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421. + The base64 encoding is adapted from RFC 1421, with one change: base64 + eliminates the "*" mechanism for embedded clear text. + + A 65-character subset of US-ASCII is used, enabling 6 bits to be + represented per printable character. (The extra 65th character, "=", + is used to signify a special processing function.) + + NOTE: This subset has the important property that it is + represented identically in all versions of ISO 646, including US + ASCII, and all characters in the subset are also represented + identically in all versions of EBCDIC. Other popular encodings, + such as the encoding used by the uuencode utility and the base85 + encoding specified as part of Level 2 PostScript, do not share + these properties, and thus do not fulfill the portability + requirements a binary transport encoding for mail must meet. + + The encoding process represents 24-bit groups of input bits as output + strings of 4 encoded characters. Proceeding from left to right, a + 24-bit input group is formed by concatenating 3 8-bit input groups. + These 24 bits are then treated as 4 concatenated 6-bit groups, each + of which is translated into a single digit in the base64 alphabet. + When encoding a bit stream via the base64 encoding, the bit stream + must be presumed to be ordered with the most-significant-bit first. + + + +Borenstein & Freed [Page 21] + +RFC 1521 MIME September 1993 + + + That is, the first bit in the stream will be the high-order bit in + the first byte, and the eighth bit will be the low-order bit in the + first byte, and so on. + + Each 6-bit group is used as an index into an array of 64 printable + characters. The character referenced by the index is placed in the + output string. These characters, identified in Table 1, below, are + selected so as to be universally representable, and the set excludes + characters with particular significance to SMTP (e.g., ".", CR, LF) + and to the encapsulation boundaries defined in this document (e.g., + "-"). + + Table 1: The Base64 Alphabet + + Value Encoding Value Encoding Value Encoding Value Encoding + 0 A 17 R 34 i 51 z + 1 B 18 S 35 j 52 0 + 2 C 19 T 36 k 53 1 + 3 D 20 U 37 l 54 2 + 4 E 21 V 38 m 55 3 + 5 F 22 W 39 n 56 4 + 6 G 23 X 40 o 57 5 + 7 H 24 Y 41 p 58 6 + 8 I 25 Z 42 q 59 7 + 9 J 26 a 43 r 60 8 + 10 K 27 b 44 s 61 9 + 11 L 28 c 45 t 62 + + 12 M 29 d 46 u 63 / + 13 N 30 e 47 v + 14 O 31 f 48 w (pad) = + 15 P 32 g 49 x + 16 Q 33 h 50 y + + The output stream (encoded bytes) must be represented in lines of no + more than 76 characters each. All line breaks or other characters + not found in Table 1 must be ignored by decoding software. In base64 + data, characters other than those in Table 1, line breaks, and other + white space probably indicate a transmission error, about which a + warning message or even a message rejection might be appropriate + under some circumstances. + + Special processing is performed if fewer than 24 bits are available + at the end of the data being encoded. A full encoding quantum is + always completed at the end of a body. When fewer than 24 input bits + are available in an input group, zero bits are added (on the right) + to form an integral number of 6-bit groups. Padding at the end of + the data is performed using the '=' character. Since all base64 + input is an integral number of octets, only the following cases can + + + +Borenstein & Freed [Page 22] + +RFC 1521 MIME September 1993 + + + arise: (1) the final quantum of encoding input is an integral + multiple of 24 bits; here, the final unit of encoded output will be + an integral multiple of 4 characters with no "=" padding, (2) the + final quantum of encoding input is exactly 8 bits; here, the final + unit of encoded output will be two characters followed by two "=" + padding characters, or (3) the final quantum of encoding input is + exactly 16 bits; here, the final unit of encoded output will be three + characters followed by one "=" padding character. + + Because it is used only for padding at the end of the data, the + occurrence of any '=' characters may be taken as evidence that the + end of the data has been reached (without truncation in transit). No + such assurance is possible, however, when the number of octets + transmitted was a multiple of three. + + Any characters outside of the base64 alphabet are to be ignored in + base64-encoded data. The same applies to any illegal sequence of + characters in the base64 encoding, such as "=====" + + Care must be taken to use the proper octets for line breaks if base64 + encoding is applied directly to text material that has not been + converted to canonical form. In particular, text line breaks must be + converted into CRLF sequences prior to base64 encoding. The important + thing to note is that this may be done directly by the encoder rather + than in a prior canonicalization step in some implementations. + + NOTE: There is no need to worry about quoting apparent + encapsulation boundaries within base64-encoded parts of multipart + entities because no hyphen characters are used in the base64 + encoding. + +6. Additional Content-Header Fields + +6.1. Optional Content-ID Header Field + + In constructing a high-level user agent, it may be desirable to allow + one body to make reference to another. Accordingly, bodies may be + labeled using the "Content-ID" header field, which is syntactically + identical to the "Message-ID" header field: + + id := "Content-ID" ":" msg-id + Like the Message-ID values, Content-ID values must be generated to be + world-unique. + + The Content-ID value may be used for uniquely identifying MIME + entities in several contexts, particularly for cacheing data + referenced by the message/external-body mechanism. Although the + Content-ID header is generally optional, its use is mandatory in + + + +Borenstein & Freed [Page 23] + +RFC 1521 MIME September 1993 + + + implementations which generate data of the optional MIME Content-type + "message/external-body". That is, each message/external-body entity + must have a Content-ID field to permit cacheing of such data. + + It is also worth noting that the Content-ID value has special + semantics in the case of the multipart/alternative content-type. + This is explained in the section of this document dealing with + multipart/alternative. + +6.2. Optional Content-Description Header Field + + The ability to associate some descriptive information with a given + body is often desirable. For example, it may be useful to mark an + "image" body as "a picture of the Space Shuttle Endeavor." Such text + may be placed in the Content-Description header field. + + description := "Content-Description" ":" *text + + The description is presumed to be given in the US-ASCII character + set, although the mechanism specified in [RFC-1522] may be used for + non-US-ASCII Content-Description values. + +7. The Predefined Content-Type Values + + This document defines seven initial Content-Type values and an + extension mechanism for private or experimental types. Further + standard types must be defined by new published specifications. It + is expected that most innovation in new types of mail will take place + as subtypes of the seven types defined here. The most essential + characteristics of the seven content-types are summarized in Appendix + F. + +7.1 The Text Content-Type + + The text Content-Type is intended for sending material which is + principally textual in form. It is the default Content-Type. A + "charset" parameter may be used to indicate the character set of the + body text for some text subtypes, notably including the primary + subtype, "text/plain", which indicates plain (unformatted) text. The + default Content-Type for Internet mail is "text/plain; charset=us- + ascii". + + Beyond plain text, there are many formats for representing what might + be known as "extended text" -- text with embedded formatting and + presentation information. An interesting characteristic of many such + representations is that they are to some extent readable even without + the software that interprets them. It is useful, then, to + distinguish them, at the highest level, from such unreadable data as + + + +Borenstein & Freed [Page 24] + +RFC 1521 MIME September 1993 + + + images, audio, or text represented in an unreadable form. In the + absence of appropriate interpretation software, it is reasonable to + show subtypes of text to the user, while it is not reasonable to do + so with most nontextual data. + + Such formatted textual data should be represented using subtypes of + text. Plausible subtypes of text are typically given by the common + name of the representation format, e.g., "text/richtext" [RFC-1341]. + +7.1.1. The charset parameter + + A critical parameter that may be specified in the Content-Type field + for text/plain data is the character set. This is specified with a + "charset" parameter, as in: + + Content-type: text/plain; charset=us-ascii + + Unlike some other parameter values, the values of the charset + parameter are NOT case sensitive. The default character set, which + must be assumed in the absence of a charset parameter, is US-ASCII. + + The specification for any future subtypes of "text" must specify + whether or not they will also utilize a "charset" parameter, and may + possibly restrict its values as well. When used with a particular + body, the semantics of the "charset" parameter should be identical to + those specified here for "text/plain", i.e., the body consists + entirely of characters in the given charset. In particular, definers + of future text subtypes should pay close attention the the + implications of multibyte character sets for their subtype + definitions. + + This RFC specifies the definition of the charset parameter for the + purposes of MIME to be a unique mapping of a byte stream to glyphs, a + mapping which does not require external profiling information. + + An initial list of predefined character set names can be found at the + end of this section. Additional character sets may be registered + with IANA, although the standardization of their use requires the + usual IESG [RFC-1340] review and approval. Note that if the + specified character set includes 8-bit data, a Content-Transfer- + Encoding header field and a corresponding encoding on the data are + required in order to transmit the body via some mail transfer + protocols, such as SMTP. + + The default character set, US-ASCII, has been the subject of some + confusion and ambiguity in the past. Not only were there some + ambiguities in the definition, there have been wide variations in + practice. In order to eliminate such ambiguity and variations in the + + + +Borenstein & Freed [Page 25] + +RFC 1521 MIME September 1993 + + + future, it is strongly recommended that new user agents explicitly + specify a character set via the Content-Type header field. "US- + ASCII" does not indicate an arbitrary seven-bit character code, but + specifies that the body uses character coding that uses the exact + correspondence of codes to characters specified in ASCII. National + use variations of ISO 646 [ISO-646] are NOT ASCII and their use in + Internet mail is explicitly discouraged. The omission of the ISO 646 + character set is deliberate in this regard. The character set name + of "US-ASCII" explicitly refers to ANSI X3.4-1986 [US-ASCII] only. + The character set name "ASCII" is reserved and must not be used for + any purpose. + + NOTE: RFC 821 explicitly specifies "ASCII", and references an + earlier version of the American Standard. Insofar as one of the + purposes of specifying a Content-Type and character set is to + permit the receiver to unambiguously determine how the sender + intended the coded message to be interpreted, assuming anything + other than "strict ASCII" as the default would risk unintentional + and incompatible changes to the semantics of messages now being + transmitted. This also implies that messages containing + characters coded according to national variations on ISO 646, or + using code-switching procedures (e.g., those of ISO 2022), as well + as 8-bit or multiple octet character encodings MUST use an + appropriate character set specification to be consistent with this + specification. + + The complete US-ASCII character set is listed in [US-ASCII]. Note + that the control characters including DEL (0-31, 127) have no defined + meaning apart from the combination CRLF (ASCII values 13 and 10) + indicating a new line. Two of the characters have de facto meanings + in wide use: FF (12) often means "start subsequent text on the + beginning of a new page"; and TAB or HT (9) often (though not always) + means "move the cursor to the next available column after the current + position where the column number is a multiple of 8 (counting the + first column as column 0)." Apart from this, any use of the control + characters or DEL in a body must be part of a private agreement + between the sender and recipient. Such private agreements are + discouraged and should be replaced by the other capabilities of this + document. + + NOTE: Beyond US-ASCII, an enormous proliferation of character sets + is possible. It is the opinion of the IETF working group that a + large number of character sets is NOT a good thing. We would + prefer to specify a single character set that can be used + universally for representing all of the world's languages in + electronic mail. Unfortunately, existing practice in several + communities seems to point to the continued use of multiple + character sets in the near future. For this reason, we define + + + +Borenstein & Freed [Page 26] + +RFC 1521 MIME September 1993 + + + names for a small number of character sets for which a strong + constituent base exists. + + The defined charset values are: + + US-ASCII -- as defined in [US-ASCII]. + + ISO-8859-X -- where "X" is to be replaced, as necessary, for the + parts of ISO-8859 [ISO-8859]. Note that the ISO 646 + character sets have deliberately been omitted in favor of + their 8859 replacements, which are the designated character + sets for Internet mail. As of the publication of this + document, the legitimate values for "X" are the digits 1 + through 9. + + The character sets specified above are the ones that were relatively + uncontroversial during the drafting of MIME. This document does not + endorse the use of any particular character set other than US-ASCII, + and recognizes that the future evolution of world character sets + remains unclear. It is expected that in the future, additional + character sets will be registered for use in MIME. + + Note that the character set used, if anything other than US-ASCII, + must always be explicitly specified in the Content-Type field. + + No other character set name may be used in Internet mail without the + publication of a formal specification and its registration with IANA, + or by private agreement, in which case the character set name must + begin with "X-". + + Implementors are discouraged from defining new character sets for + mail use unless absolutely necessary. + + The "charset" parameter has been defined primarily for the purpose of + textual data, and is described in this section for that reason. + However, it is conceivable that non-textual data might also wish to + specify a charset value for some purpose, in which case the same + syntax and values should be used. + + In general, mail-sending software must always use the "lowest common + denominator" character set possible. For example, if a body contains + only US-ASCII characters, it must be marked as being in the US-ASCII + character set, not ISO-8859-1, which, like all the ISO-8859 family of + character sets, is a superset of US-ASCII. More generally, if a + widely-used character set is a subset of another character set, and a + body contains only characters in the widely-used subset, it must be + labeled as being in that subset. This will increase the chances that + the recipient will be able to view the mail correctly. + + + +Borenstein & Freed [Page 27] + +RFC 1521 MIME September 1993 + + +7.1.2. The Text/plain subtype + + The primary subtype of text is "plain". This indicates plain + (unformatted) text. The default Content-Type for Internet mail, + "text/plain; charset=us-ascii", describes existing Internet practice. + That is, it is the type of body defined by RFC 822. + + No other text subtype is defined by this document. + + The formal grammar for the content-type header field for text is as + follows: + + text-type := "text" "/" text-subtype [";" "charset" "=" charset] + + text-subtype := "plain" / extension-token + + charset := "us-ascii"/ "iso-8859-1"/ "iso-8859-2"/ "iso-8859-3" + / "iso-8859-4"/ "iso-8859-5"/ "iso-8859-6"/ "iso-8859-7" + / "iso-8859-8" / "iso-8859-9" / extension-token + ; case insensitive + +7.2. The Multipart Content-Type + + In the case of multiple part entities, in which one or more different + sets of data are combined in a single body, a "multipart" Content- + Type field must appear in the entity's header. The body must then + contain one or more "body parts," each preceded by an encapsulation + boundary, and the last one followed by a closing boundary. Each part + starts with an encapsulation boundary, and then contains a body part + consisting of header area, a blank line, and a body area. Thus a + body part is similar to an RFC 822 message in syntax, but different + in meaning. + + A body part is NOT to be interpreted as actually being an RFC 822 + message. To begin with, NO header fields are actually required in + body parts. A body part that starts with a blank line, therefore, is + allowed and is a body part for which all default values are to be + assumed. In such a case, the absence of a Content-Type header field + implies that the corresponding body is plain US-ASCII text. The only + header fields that have defined meaning for body parts are those the + names of which begin with "Content-". All other header fields are + generally to be ignored in body parts. Although they should + generally be retained in mail processing, they may be discarded by + gateways if necessary. Such other fields are permitted to appear in + body parts but must not be depended on. "X-" fields may be created + for experimental or private purposes, with the recognition that the + information they contain may be lost at some gateways. + + + + +Borenstein & Freed [Page 28] + +RFC 1521 MIME September 1993 + + + NOTE: The distinction between an RFC 822 message and a body part + is subtle, but important. A gateway between Internet and X.400 + mail, for example, must be able to tell the difference between a + body part that contains an image and a body part that contains an + encapsulated message, the body of which is an image. In order to + represent the latter, the body part must have "Content-Type: + message", and its body (after the blank line) must be the + encapsulated message, with its own "Content-Type: image" header + field. The use of similar syntax facilitates the conversion of + messages to body parts, and vice versa, but the distinction + between the two must be understood by implementors. (For the + special case in which all parts actually are messages, a "digest" + subtype is also defined.) + + As stated previously, each body part is preceded by an encapsulation + boundary. The encapsulation boundary MUST NOT appear inside any of + the encapsulated parts. Thus, it is crucial that the composing agent + be able to choose and specify the unique boundary that will separate + the parts. + + All present and future subtypes of the "multipart" type must use an + identical syntax. Subtypes may differ in their semantics, and may + impose additional restrictions on syntax, but must conform to the + required syntax for the multipart type. This requirement ensures + that all conformant user agents will at least be able to recognize + and separate the parts of any multipart entity, even of an + unrecognized subtype. + + As stated in the definition of the Content-Transfer-Encoding field, + no encoding other than "7bit", "8bit", or "binary" is permitted for + entities of type "multipart". The multipart delimiters and header + fields are always represented as 7-bit ASCII in any case (though the + header fields may encode non-ASCII header text as per [RFC-1522]), + and data within the body parts can be encoded on a part-by-part + basis, with Content-Transfer-Encoding fields for each appropriate + body part. + + Mail gateways, relays, and other mail handling agents are commonly + known to alter the top-level header of an RFC 822 message. In + particular, they frequently add, remove, or reorder header fields. + Such alterations are explicitly forbidden for the body part headers + embedded in the bodies of messages of type "multipart." + +7.2.1. Multipart: The common syntax + + All subtypes of "multipart" share a common syntax, defined in this + section. A simple example of a multipart message also appears in + this section. An example of a more complex multipart message is + + + +Borenstein & Freed [Page 29] + +RFC 1521 MIME September 1993 + + + given in Appendix C. + + The Content-Type field for multipart entities requires one parameter, + "boundary", which is used to specify the encapsulation boundary. The + encapsulation boundary is defined as a line consisting entirely of + two hyphen characters ("-", decimal code 45) followed by the boundary + parameter value from the Content-Type header field. + + NOTE: The hyphens are for rough compatibility with the earlier RFC + 934 method of message encapsulation, and for ease of searching for + the boundaries in some implementations. However, it should be + noted that multipart messages are NOT completely compatible with + RFC 934 encapsulations; in particular, they do not obey RFC 934 + quoting conventions for embedded lines that begin with hyphens. + This mechanism was chosen over the RFC 934 mechanism because the + latter causes lines to grow with each level of quoting. The + combination of this growth with the fact that SMTP implementations + sometimes wrap long lines made the RFC 934 mechanism unsuitable + for use in the event that deeply-nested multipart structuring is + ever desired. + + WARNING TO IMPLEMENTORS: The grammar for parameters on the Content- + type field is such that it is often necessary to enclose the + boundaries in quotes on the Content-type line. This is not always + necessary, but never hurts. Implementors should be sure to study the + grammar carefully in order to avoid producing illegal Content-type + fields. Thus, a typical multipart Content-Type header field might + look like this: + + Content-Type: multipart/mixed; + boundary=gc0p4Jq0M2Yt08jU534c0p + + But the following is illegal: + + Content-Type: multipart/mixed; + boundary=gc0p4Jq0M:2Yt08jU534c0p + + (because of the colon) and must instead be represented as + + Content-Type: multipart/mixed; + boundary="gc0p4Jq0M:2Yt08jU534c0p" + + This indicates that the entity consists of several parts, each itself + with a structure that is syntactically identical to an RFC 822 + message, except that the header area might be completely empty, and + that the parts are each preceded by the line + + --gc0p4Jq0M:2Yt08jU534c0p + + + +Borenstein & Freed [Page 30] + +RFC 1521 MIME September 1993 + + + Note that the encapsulation boundary must occur at the beginning of a + line, i.e., following a CRLF, and that the initial CRLF is considered + to be attached to the encapsulation boundary rather than part of the + preceding part. The boundary must be followed immediately either by + another CRLF and the header fields for the next part, or by two + CRLFs, in which case there are no header fields for the next part + (and it is therefore assumed to be of Content-Type text/plain). + + NOTE: The CRLF preceding the encapsulation line is conceptually + attached to the boundary so that it is possible to have a part + that does not end with a CRLF (line break). Body parts that must + be considered to end with line breaks, therefore, must have two + CRLFs preceding the encapsulation line, the first of which is part + of the preceding body part, and the second of which is part of the + encapsulation boundary. + + Encapsulation boundaries must not appear within the encapsulations, + and must be no longer than 70 characters, not counting the two + leading hyphens. + + The encapsulation boundary following the last body part is a + distinguished delimiter that indicates that no further body parts + will follow. Such a delimiter is identical to the previous + delimiters, with the addition of two more hyphens at the end of the + line: + + --gc0p4Jq0M2Yt08jU534c0p-- + + There appears to be room for additional information prior to the + first encapsulation boundary and following the final boundary. These + areas should generally be left blank, and implementations must ignore + anything that appears before the first boundary or after the last + one. + + NOTE: These "preamble" and "epilogue" areas are generally not used + because of the lack of proper typing of these parts and the lack + of clear semantics for handling these areas at gateways, + particularly X.400 gateways. However, rather than leaving the + preamble area blank, many MIME implementations have found this to + be a convenient place to insert an explanatory note for recipients + who read the message with pre-MIME software, since such notes will + be ignored by MIME-compliant software. + + NOTE: Because encapsulation boundaries must not appear in the body + parts being encapsulated, a user agent must exercise care to + choose a unique boundary. The boundary in the example above could + have been the result of an algorithm designed to produce + boundaries with a very low probability of already existing in the + + + +Borenstein & Freed [Page 31] + +RFC 1521 MIME September 1993 + + + data to be encapsulated without having to prescan the data. + Alternate algorithms might result in more 'readable' boundaries + for a recipient with an old user agent, but would require more + attention to the possibility that the boundary might appear in the + encapsulated part. The simplest boundary possible is something + like "---", with a closing boundary of "-----". + + As a very simple example, the following multipart message has two + parts, both of them plain text, one of them explicitly typed and one + of them implicitly typed: + + From: Nathaniel Borenstein + To: Ned Freed + Subject: Sample message + MIME-Version: 1.0 + Content-type: multipart/mixed; boundary="simple + boundary" + + This is the preamble. It is to be ignored, though it + is a handy place for mail composers to include an + explanatory note to non-MIME conformant readers. + --simple boundary + + This is implicitly typed plain ASCII text. + It does NOT end with a linebreak. + --simple boundary + Content-type: text/plain; charset=us-ascii + + This is explicitly typed plain ASCII text. + It DOES end with a linebreak. + + --simple boundary-- + This is the epilogue. It is also to be ignored. + + The use of a Content-Type of multipart in a body part within another + multipart entity is explicitly allowed. In such cases, for obvious + reasons, care must be taken to ensure that each nested multipart + entity must use a different boundary delimiter. See Appendix C for an + example of nested multipart entities. + + The use of the multipart Content-Type with only a single body part + may be useful in certain contexts, and is explicitly permitted. + + The only mandatory parameter for the multipart Content-Type is the + boundary parameter, which consists of 1 to 70 characters from a set + of characters known to be very robust through email gateways, and NOT + ending with white space. (If a boundary appears to end with white + space, the white space must be presumed to have been added by a + + + +Borenstein & Freed [Page 32] + +RFC 1521 MIME September 1993 + + + gateway, and must be deleted.) It is formally specified by the + following BNF: + + boundary := 0*69 bcharsnospace + + bchars := bcharsnospace / " " + + bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /"_" + / "," / "-" / "." / "/" / ":" / "=" / "?" + + Overall, the body of a multipart entity may be specified as + follows: + + multipart-body := preamble 1*encapsulation + close-delimiter epilogue + + encapsulation := delimiter body-part CRLF + + delimiter := "--" boundary CRLF ; taken from Content-Type field. + ; There must be no space + ; between "--" and boundary. + + close-delimiter := "--" boundary "--" CRLF ; Again, no space + by "--", + + preamble := discard-text ; to be ignored upon receipt. + + epilogue := discard-text ; to be ignored upon receipt. + + discard-text := *(*text CRLF) + + body-part := <"message" as defined in RFC 822, + with all header fields optional, and with the + specified delimiter not occurring anywhere in + the message body, either on a line by itself + or as a substring anywhere. Note that the + semantics of a part differ from the semantics + of a message, as described in the text.> + + NOTE: In certain transport enclaves, RFC 822 restrictions such as + the one that limits bodies to printable ASCII characters may not + be in force. (That is, the transport domains may resemble + standard Internet mail transport as specified in RFC821 and + assumed by RFC822, but without certain restrictions.) The + relaxation of these restrictions should be construed as locally + extending the definition of bodies, for example to include octets + outside of the ASCII range, as long as these extensions are + supported by the transport and adequately documented in the + + + +Borenstein & Freed [Page 33] + +RFC 1521 MIME September 1993 + + + Content-Transfer-Encoding header field. However, in no event are + headers (either message headers or body-part headers) allowed to + contain anything other than ASCII characters. + + NOTE: Conspicuously missing from the multipart type is a notion of + structured, related body parts. In general, it seems premature to + try to standardize interpart structure yet. It is recommended + that those wishing to provide a more structured or integrated + multipart messaging facility should define a subtype of multipart + that is syntactically identical, but that always expects the + inclusion of a distinguished part that can be used to specify the + structure and integration of the other parts, probably referring + to them by their Content-ID field. If this approach is used, + other implementations will not recognize the new subtype, but will + treat it as the primary subtype (multipart/mixed) and will thus be + able to show the user the parts that are recognized. + +7.2.2. The Multipart/mixed (primary) subtype + + The primary subtype for multipart, "mixed", is intended for use when + the body parts are independent and need to be bundled in a particular + order. Any multipart subtypes that an implementation does not + recognize must be treated as being of subtype "mixed". + +7.2.3. The Multipart/alternative subtype + + The multipart/alternative type is syntactically identical to + multipart/mixed, but the semantics are different. In particular, + each of the parts is an "alternative" version of the same + information. + + Systems should recognize that the content of the various parts are + interchangeable. Systems should choose the "best" type based on the + local environment and preferences, in some cases even through user + interaction. As with multipart/mixed, the order of body parts is + significant. In this case, the alternatives appear in an order of + increasing faithfulness to the original content. In general, the best + choice is the LAST part of a type supported by the recipient system's + local environment. + + Multipart/alternative may be used, for example, to send mail in a + fancy text format in such a way that it can easily be displayed + anywhere: + + + + + + + + +Borenstein & Freed [Page 34] + +RFC 1521 MIME September 1993 + + + From: Nathaniel Borenstein + To: Ned Freed + Subject: Formatted text mail + MIME-Version: 1.0 + Content-Type: multipart/alternative; boundary=boundary42 + + --boundary42 + + Content-Type: text/plain; charset=us-ascii + + ...plain text version of message goes here.... + --boundary42 + Content-Type: text/richtext + + .... RFC 1341 richtext version of same message goes here ... + --boundary42 + Content-Type: text/x-whatever + + .... fanciest formatted version of same message goes here + ... + --boundary42-- + + In this example, users whose mail system understood the "text/x- + whatever" format would see only the fancy version, while other users + would see only the richtext or plain text version, depending on the + capabilities of their system. + + In general, user agents that compose multipart/alternative entities + must place the body parts in increasing order of preference, that is, + with the preferred format last. For fancy text, the sending user + agent should put the plainest format first and the richest format + last. Receiving user agents should pick and display the last format + they are capable of displaying. In the case where one of the + alternatives is itself of type "multipart" and contains unrecognized + sub-parts, the user agent may choose either to show that alternative, + an earlier alternative, or both. + + NOTE: From an implementor's perspective, it might seem more + sensible to reverse this ordering, and have the plainest + alternative last. However, placing the plainest alternative first + is the friendliest possible option when multipart/alternative + entities are viewed using a non-MIME-conformant mail reader. + While this approach does impose some burden on conformant mail + readers, interoperability with older mail readers was deemed to be + more important in this case. + + It may be the case that some user agents, if they can recognize more + than one of the formats, will prefer to offer the user the choice of + + + +Borenstein & Freed [Page 35] + +RFC 1521 MIME September 1993 + + + which format to view. This makes sense, for example, if mail + includes both a nicely-formatted image version and an easily-edited + text version. What is most critical, however, is that the user not + automatically be shown multiple versions of the same data. Either + the user should be shown the last recognized version or should be + given the choice. + + NOTE ON THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each + part of a multipart/alternative entity represents the same data, but + the mappings between the two are not necessarily without information + loss. For example, information is lost when translating ODA to + PostScript or plain text. It is recommended that each part should + have a different Content-ID value in the case where the information + content of the two parts is not identical. However, where the + information content is identical -- for example, where several parts + of type "application/external- body" specify alternate ways to access + the identical data -- the same Content-ID field value should be used, + to optimize any cacheing mechanisms that might be present on the + recipient's end. However, it is recommended that the Content-ID + values used by the parts should not be the same Content-ID value that + describes the multipart/alternative as a whole, if there is any such + Content-ID field. That is, one Content-ID value will refer to the + multipart/alternative entity, while one or more other Content-ID + values will refer to the parts inside it. + +7.2.4. The Multipart/digest subtype + + This document defines a "digest" subtype of the multipart Content- + Type. This type is syntactically identical to multipart/mixed, but + the semantics are different. In particular, in a digest, the default + Content-Type value for a body part is changed from "text/plain" to + "message/rfc822". This is done to allow a more readable digest + format that is largely compatible (except for the quoting convention) + with RFC 934. + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 36] + +RFC 1521 MIME September 1993 + + + A digest in this format might, then, look something like this: + + From: Moderator-Address + To: Recipient-List + MIME-Version: 1.0 + Subject: Internet Digest, volume 42 + Content-Type: multipart/digest; + boundary="---- next message ----" + + ------ next message ---- + + From: someone-else + Subject: my opinion + + ...body goes here ... + + ------ next message ---- + + From: someone-else-again + Subject: my different opinion + + ... another body goes here... + + ------ next message ------ + +7.2.5. The Multipart/parallel subtype + + This document defines a "parallel" subtype of the multipart Content- + Type. This type is syntactically identical to multipart/mixed, but + the semantics are different. In particular, in a parallel entity, + the order of body parts is not significant. + + A common presentation of this type is to display all of the parts + simultaneously on hardware and software that are capable of doing so. + However, composing agents should be aware that many mail readers will + lack this capability and will show the parts serially in any event. + +7.2.6. Other Multipart subtypes + + Other multipart subtypes are expected in the future. MIME + implementations must in general treat unrecognized subtypes of + multipart as being equivalent to "multipart/mixed". + + The formal grammar for content-type header fields for multipart data + is given by: + + multipart-type := "multipart" "/" multipart-subtype + ";" "boundary" "=" boundary + + + +Borenstein & Freed [Page 37] + +RFC 1521 MIME September 1993 + + + multipart-subtype := "mixed" / "parallel" / "digest" + / "alternative" / extension-token + +7.3. The Message Content-Type + + It is frequently desirable, in sending mail, to encapsulate another + mail message. For this common operation, a special Content-Type, + "message", is defined. The primary subtype, message/rfc822, has no + required parameters in the Content-Type field. Additional subtypes, + "partial" and "External-body", do have required parameters. These + subtypes are explained below. + + NOTE: It has been suggested that subtypes of message might be + defined for forwarded or rejected messages. However, forwarded + and rejected messages can be handled as multipart messages in + which the first part contains any control or descriptive + information, and a second part, of type message/rfc822, is the + forwarded or rejected message. Composing rejection and forwarding + messages in this manner will preserve the type information on the + original message and allow it to be correctly presented to the + recipient, and hence is strongly encouraged. + + As stated in the definition of the Content-Transfer-Encoding field, + no encoding other than "7bit", "8bit", or "binary" is permitted for + messages or parts of type "message". Even stronger restrictions + apply to the subtypes "message/partial" and "message/external-body", + as specified below. The message header fields are always US-ASCII in + any case, and data within the body can still be encoded, in which + case the Content-Transfer-Encoding header field in the encapsulated + message will reflect this. Non-ASCII text in the headers of an + encapsulated message can be specified using the mechanisms described + in [RFC-1522]. + + Mail gateways, relays, and other mail handling agents are commonly + known to alter the top-level header of an RFC 822 message. In + particular, they frequently add, remove, or reorder header fields. + Such alterations are explicitly forbidden for the encapsulated + headers embedded in the bodies of messages of type "message." + +7.3.1. The Message/rfc822 (primary) subtype + + A Content-Type of "message/rfc822" indicates that the body contains + an encapsulated message, with the syntax of an RFC 822 message. + However, unlike top-level RFC 822 messages, it is not required that + each message/rfc822 body must include a "From", "Subject", and at + least one destination header. + + It should be noted that, despite the use of the numbers "822", a + + + +Borenstein & Freed [Page 38] + +RFC 1521 MIME September 1993 + + + message/rfc822 entity can include enhanced information as defined in + this document. In other words, a message/rfc822 message may be a + MIME message. + +7.3.2. The Message/Partial subtype + + A subtype of message, "partial", is defined in order to allow large + objects to be delivered as several separate pieces of mail and + automatically reassembled by the receiving user agent. (The concept + is similar to IP fragmentation/reassembly in the basic Internet + Protocols.) This mechanism can be used when intermediate transport + agents limit the size of individual messages that can be sent. + Content-Type "message/partial" thus indicates that the body contains + a fragment of a larger message. + + Three parameters must be specified in the Content-Type field of type + message/partial: The first, "id", is a unique identifier, as close to + a world-unique identifier as possible, to be used to match the parts + together. (In general, the identifier is essentially a message-id; + if placed in double quotes, it can be any message-id, in accordance + with the BNF for "parameter" given earlier in this specification.) + The second, "number", an integer, is the part number, which indicates + where this part fits into the sequence of fragments. The third, + "total", another integer, is the total number of parts. This third + subfield is required on the final part, and is optional (though + encouraged) on the earlier parts. Note also that these parameters + may be given in any order. + + Thus, part 2 of a 3-part message may have either of the following + header fields: + + Content-Type: Message/Partial; + number=2; total=3; + id="oc=jpbe0M2Yt4s@thumper.bellcore.com" + + Content-Type: Message/Partial; + id="oc=jpbe0M2Yt4s@thumper.bellcore.com"; + number=2 + + But part 3 MUST specify the total number of parts: + + Content-Type: Message/Partial; + number=3; total=3; + id="oc=jpbe0M2Yt4s@thumper.bellcore.com" + + Note that part numbering begins with 1, not 0. + + When the parts of a message broken up in this manner are put + + + +Borenstein & Freed [Page 39] + +RFC 1521 MIME September 1993 + + + together, the result is a complete MIME entity, which may have its + own Content-Type header field, and thus may contain any other data + type. + + Message fragmentation and reassembly: The semantics of a reassembled + partial message must be those of the "inner" message, rather than of + a message containing the inner message. This makes it possible, for + example, to send a large audio message as several partial messages, + and still have it appear to the recipient as a simple audio message + rather than as an encapsulated message containing an audio message. + That is, the encapsulation of the message is considered to be + "transparent". + + When generating and reassembling the parts of a message/partial + message, the headers of the encapsulated message must be merged with + the headers of the enclosing entities. In this process the following + rules must be observed: + + (1) All of the header fields from the initial enclosing entity + (part one), except those that start with "Content-" and the + specific header fields "Message-ID", "Encrypted", and "MIME- + Version", must be copied, in order, to the new message. + + (2) Only those header fields in the enclosed message which start + with "Content-" and "Message-ID", "Encrypted", and "MIME-Version" + must be appended, in order, to the header fields of the new + message. Any header fields in the enclosed message which do not + start with "Content-" (except for "Message-ID", "Encrypted", and + "MIME-Version") will be ignored. + + (3) All of the header fields from the second and any subsequent + messages will be ignored. + + For example, if an audio message is broken into two parts, the first + part might look something like this: + + X-Weird-Header-1: Foo + From: Bill@host.com + To: joe@otherhost.com + Subject: Audio mail + Message-ID: + MIME-Version: 1.0 + Content-type: message/partial; + id="ABC@host.com"; + number=1; total=2 + + X-Weird-Header-1: Bar + X-Weird-Header-2: Hello + + + +Borenstein & Freed [Page 40] + +RFC 1521 MIME September 1993 + + + Message-ID: + MIME-Version: 1.0 + Content-type: audio/basic + Content-transfer-encoding: base64 + + ... first half of encoded audio data goes here... + + and the second half might look something like this: + + From: Bill@host.com + To: joe@otherhost.com + Subject: Audio mail + MIME-Version: 1.0 + Message-ID: + Content-type: message/partial; + id="ABC@host.com"; number=2; total=2 + + ... second half of encoded audio data goes here... + + Then, when the fragmented message is reassembled, the resulting + message to be displayed to the user should look something like this: + + X-Weird-Header-1: Foo + From: Bill@host.com + To: joe@otherhost.com + Subject: Audio mail + Message-ID: + MIME-Version: 1.0 + Content-type: audio/basic + Content-transfer-encoding: base64 + + ... first half of encoded audio data goes here... + ... second half of encoded audio data goes here... + + Note on encoding of MIME entities encapsulated inside message/partial + entities: Because data of type "message" may never be encoded in + base64 or quoted-printable, a problem might arise if message/partial + entities are constructed in an environment that supports binary or + 8-bit transport. The problem is that the binary data would be split + into multiple message/partial objects, each of them requiring binary + transport. If such objects were encountered at a gateway into a 7- + bit transport environment, there would be no way to properly encode + them for the 7-bit world, aside from waiting for all of the parts, + reassembling the message, and then encoding the reassembled data in + base64 or quoted-printable. Since it is possible that different + parts might go through different gateways, even this is not an + acceptable solution. For this reason, it is specified that MIME + entities of type message/partial must always have a content- + + + +Borenstein & Freed [Page 41] + +RFC 1521 MIME September 1993 + + + transfer-encoding of 7-bit (the default). In particular, even in + environments that support binary or 8-bit transport, the use of a + content-transfer-encoding of "8bit" or "binary" is explicitly + prohibited for entities of type message/partial. + + It should be noted that, because some message transfer agents may + choose to automatically fragment large messages, and because such + agents may use different fragmentation thresholds, it is possible + that the pieces of a partial message, upon reassembly, may prove + themselves to comprise a partial message. This is explicitly + permitted. + + It should also be noted that the inclusion of a "References" field in + the headers of the second and subsequent pieces of a fragmented + message that references the Message-Id on the previous piece may be + of benefit to mail readers that understand and track references. + However, the generation of such "References" fields is entirely + optional. + + Finally, it should be noted that the "Encrypted" header field has + been made obsolete by Privacy Enhanced Messaging (PEM), but the rules + above are believed to describe the correct way to treat it if it is + encountered in the context of conversion to and from message/partial + fragments. + +7.3.3. The Message/External-Body subtype + + The external-body subtype indicates that the actual body data are not + included, but merely referenced. In this case, the parameters + describe a mechanism for accessing the external data. + + When an entity is of type "message/external-body", it consists of a + header, two consecutive CRLFs, and the message header for the + encapsulated message. If another pair of consecutive CRLFs appears, + this of course ends the message header for the encapsulated message. + However, since the encapsulated message's body is itself external, it + does NOT appear in the area that follows. For example, consider the + following message: + + Content-type: message/external-body; access- + type=local-file; + + name="/u/nsb/Me.gif" + + Content-type: image/gif + Content-ID: + Content-Transfer-Encoding: binary + + + + +Borenstein & Freed [Page 42] + +RFC 1521 MIME September 1993 + + + THIS IS NOT REALLY THE BODY! + + The area at the end, which might be called the "phantom body", is + ignored for most external-body messages. However, it may be used to + contain auxiliary information for some such messages, as indeed it is + when the access-type is "mail-server". Of the access-types defined + by this document, the phantom body is used only when the access-type + is "mail-server". In all other cases, the phantom body is ignored. + + The only always-mandatory parameter for message/external-body is + "access-type"; all of the other parameters may be mandatory or + optional depending on the value of access-type. + + ACCESS-TYPE -- A case-insensitive word, indicating the supported + access mechanism by which the file or data may be obtained. + Values include, but are not limited to, "FTP", "ANON-FTP", "TFTP", + "AFS", "LOCAL-FILE", and "MAIL-SERVER". Future values, except for + experimental values beginning with "X-" must be registered with + IANA, as described in Appendix E . + + In addition, the following three parameters are optional for ALL + access-types: + + EXPIRATION -- The date (in the RFC 822 "date-time" syntax, as + extended by RFC 1123 to permit 4 digits in the year field) after + which the existence of the external data is not guaranteed. + + SIZE -- The size (in octets) of the data. The intent of this + parameter is to help the recipient decide whether or not to expend + the necessary resources to retrieve the external data. Note that + this describes the size of the data in its canonical form, that + is, before any Content- Transfer-Encoding has been applied or + after the data have been decoded. + + PERMISSION -- A case-insensitive field that indicates whether or + not it is expected that clients might also attempt to overwrite + the data. By default, or if permission is "read", the assumption + is that they are not, and that if the data is retrieved once, it + is never needed again. If PERMISSION is "read-write", this + assumption is invalid, and any local copy must be considered no + more than a cache. "Read" and "Read-write" are the only defined + values of permission. + + The precise semantics of the access-types defined here are described + in the sections that follow. + + The encapsulated headers in ALL message/external-body entities MUST + include a Content-ID header field to give a unique identifier by + + + +Borenstein & Freed [Page 43] + +RFC 1521 MIME September 1993 + + + which to reference the data. This identifier may be used for + cacheing mechanisms, and for recognizing the receipt of the data when + the access-type is "mail-server". + + Note that, as specified here, the tokens that describe external-body + data, such as file names and mail server commands, are required to be + in the US-ASCII character set. If this proves problematic in + practice, a new mechanism may be required as a future extension to + MIME, either as newly defined access-types for message/external-body + or by some other mechanism. + + As with message/partial, it is specified that MIME entities of type + message/external-body must always have a content-transfer-encoding of + 7-bit (the default). In particular, even in environments that + support binary or 8-bit transport, the use of a content-transfer- + encoding of "8bit" or "binary" is explicitly prohibited for entities + of type message/external-body. + +7.3.3.1. The "ftp" and "tftp" access-types + + An access-type of FTP or TFTP indicates that the message body is + accessible as a file using the FTP [RFC-959] or TFTP [RFC-783] + protocols, respectively. For these access-types, the following + additional parameters are mandatory: + + NAME -- The name of the file that contains the actual body data. + + SITE -- A machine from which the file may be obtained, using the + given protocol. This must be a fully qualified domain name, not a + nickname. + + Before any data are retrieved, using FTP, the user will generally + need to be asked to provide a login id and a password for the machine + named by the site parameter. For security reasons, such an id and + password are not specified as content-type parameters, but must be + obtained from the user. + + In addition, the following parameters are optional: + + DIRECTORY -- A directory from which the data named by NAME should + be retrieved. + + MODE -- A case-insensitive string indicating the mode to be used + when retrieving the information. The legal values for access-type + "TFTP" are "NETASCII", "OCTET", and "MAIL", as specified by the + TFTP protocol [RFC-783]. The legal values for access-type "FTP" + are "ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a + decimal integer, typically 8. These correspond to the + + + +Borenstein & Freed [Page 44] + +RFC 1521 MIME September 1993 + + + representation types "A" "E" "I" and "L n" as specified by the FTP + protocol [RFC-959]. Note that "BINARY" and "TENEX" are not valid + values for MODE, but that "OCTET" or "IMAGE" or "LOCAL8" should be + used instead. IF MODE is not specified, the default value is + "NETASCII" for TFTP and "ASCII" otherwise. + +7.3.3.2. The "anon-ftp" access-type + + The "anon-ftp" access-type is identical to the "ftp" access type, + except that the user need not be asked to provide a name and password + for the specified site. Instead, the ftp protocol will be used with + login "anonymous" and a password that corresponds to the user's email + address. + +7.3.3.3. The "local-file" and "afs" access-types + + An access-type of "local-file" indicates that the actual body is + accessible as a file on the local machine. An access-type of "afs" + indicates that the file is accessible via the global AFS file system. + In both cases, only a single parameter is required: + + NAME -- The name of the file that contains the actual body data. + + The following optional parameter may be used to describe the locality + of reference for the data, that is, the site or sites at which the + file is expected to be visible: + + SITE -- A domain specifier for a machine or set of machines that + are known to have access to the data file. Asterisks may be used + for wildcard matching to a part of a domain name, such as + "*.bellcore.com", to indicate a set of machines on which the data + should be directly visible, while a single asterisk may be used to + indicate a file that is expected to be universally available, + e.g., via a global file system. + +7.3.3.4. The "mail-server" access-type + + The "mail-server" access-type indicates that the actual body is + available from a mail server. The mandatory parameter for this + access-type is: + + SERVER -- The email address of the mail server from which the + actual body data can be obtained. + + Because mail servers accept a variety of syntaxes, some of which is + multiline, the full command to be sent to a mail server is not + included as a parameter on the content-type line. Instead, it is + provided as the "phantom body" when the content-type is + + + +Borenstein & Freed [Page 45] + +RFC 1521 MIME September 1993 + + + message/external-body and the access- type is mail-server. + + An optional parameter for this access-type is: + + SUBJECT -- The subject that is to be used in the mail that is sent + to obtain the data. Note that keying mail servers on Subject lines + is NOT recommended, but such mail servers are known to exist. + + Note that MIME does not define a mail server syntax. Rather, it + allows the inclusion of arbitrary mail server commands in the phantom + body. Implementations must include the phantom body in the body of + the message it sends to the mail server address to retrieve the + relevant data. + + It is worth noting that, unlike other access-types, mail-server + access is asynchronous and will happen at an unpredictable time in + the future. For this reason, it is important that there be a + mechanism by which the returned data can be matched up with the + original message/external-body entity. MIME mailservers must use the + same Content-ID field on the returned message that was used in the + original message/external-body entity, to facilitate such matching. + +7.3.3.5. Examples and Further Explanations + + With the emerging possibility of very wide-area file systems, it + becomes very hard to know in advance the set of machines where a file + will and will not be accessible directly from the file system. + Therefore it may make sense to provide both a file name, to be tried + directly, and the name of one or more sites from which the file is + known to be accessible. An implementation can try to retrieve remote + files using FTP or any other protocol, using anonymous file retrieval + or prompting the user for the necessary name and password. If an + external body is accessible via multiple mechanisms, the sender may + include multiple parts of type message/external-body within an entity + of type multipart/alternative. + + However, the external-body mechanism is not intended to be limited to + file retrieval, as shown by the mail-server access-type. Beyond + this, one can imagine, for example, using a video server for external + references to video clips. + + If an entity is of type "message/external-body", then the body of the + entity will contain the header fields of the encapsulated message. + The body itself is to be found in the external location. This means + that if the body of the "message/external-body" message contains two + consecutive CRLFs, everything after those pairs is NOT part of the + message itself. For most message/external-body messages, this + trailing area must simply be ignored. However, it is a convenient + + + +Borenstein & Freed [Page 46] + +RFC 1521 MIME September 1993 + + + place for additional data that cannot be included in the content-type + header field. In particular, if the "access-type" value is "mail- + server", then the trailing area must contain commands to be sent to + the mail server at the address given by the value of the SERVER + parameter. + + The embedded message header fields which appear in the body of the + message/external-body data must be used to declare the Content-type + of the external body if it is anything other than plain ASCII text, + since the external body does not have a header section to declare its + type. Similarly, any Content-transfer-encoding other than "7bit" + must also be declared here. Thus a complete message/external-body + message, referring to a document in PostScript format, might look + like this: + + From: Whomever + To: Someone + Subject: whatever + MIME-Version: 1.0 + Message-ID: + Content-Type: multipart/alternative; boundary=42 + Content-ID: + + --42 + Content-Type: message/external-body; + name="BodyFormats.ps"; + site="thumper.bellcore.com"; + access-type=ANON-FTP; + directory="pub"; + mode="image"; + expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" + + Content-type: application/postscript + Content-ID: + + --42 + Content-Type: message/external-body; + name="/u/nsb/writing/rfcs/RFC-MIME.ps"; + site="thumper.bellcore.com"; + access-type=AFS + expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" + + Content-type: application/postscript + Content-ID: + + --42 + Content-Type: message/external-body; + access-type=mail-server + + + +Borenstein & Freed [Page 47] + +RFC 1521 MIME September 1993 + + + server="listserv@bogus.bitnet"; + expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" + + Content-type: application/postscript + Content-ID: + + get RFC-MIME.DOC + + --42-- + + Note that in the above examples, the default Content-transfer- + encoding of "7bit" is assumed for the external postscript data. + + Like the message/partial type, the message/external-body type is + intended to be transparent, that is, to convey the data type in the + external body rather than to convey a message with a body of that + type. Thus the headers on the outer and inner parts must be merged + using the same rules as for message/partial. In particular, this + means that the Content-type header is overridden, but the From and + Subject headers are preserved. + + Note that since the external bodies are not transported as mail, they + need not conform to the 7-bit and line length requirements, but might + in fact be binary files. Thus a Content-Transfer-Encoding is not + generally necessary, though it is permitted. + + Note that the body of a message of type "message/external-body" is + governed by the basic syntax for an RFC 822 message. In particular, + anything before the first consecutive pair of CRLFs is header + information, while anything after it is body information, which is + ignored for most access-types. + + The formal grammar for content-type header fields for data of type + message is given by: + + message-type := "message" "/" message-subtype + + message-subtype := "rfc822" + / "partial" 2#3partial-param + / "external-body" 1*external-param + / extension-token + + partial-param := (";" "id" "=" value) + / (";" "number" "=" 1*DIGIT) + / (";" "total" "=" 1*DIGIT) + ; id & number required; total required for last part + + external-param := (";" "access-type" "=" atype) + + + +Borenstein & Freed [Page 48] + +RFC 1521 MIME September 1993 + + + / (";" "expiration" "=" date-time) + ; Note that date-time is quoted + / (";" "size" "=" 1*DIGIT) + / (";" "permission" "=" ("read" / "read-write")) + ; Permission is case-insensitive + / (";" "name" "=" value) + / (";" "site" "=" value) + / (";" "dir" "=" value) + / (";" "mode" "=" value) + / (";" "server" "=" value) + / (";" "subject" "=" value) + ; access-type required;others required based on access-type + + atype := "ftp" / "anon-ftp" / "tftp" / "local-file" + / "afs" / "mail-server" / extension-token + ; Case-insensitive + +7.4. The Application Content-Type + + The "application" Content-Type is to be used for data which do not + fit in any of the other categories, and particularly for data to be + processed by mail-based uses of application programs. This is + information which must be processed by an application before it is + viewable or usable to a user. Expected uses for Content-Type + application include mail-based file transfer, spreadsheets, data for + mail-based scheduling systems, and languages for "active" + (computational) email. (The latter, in particular, can pose security + problems which must be understood by implementors, and are considered + in detail in the discussion of the application/PostScript content- + type.) + + For example, a meeting scheduler might define a standard + representation for information about proposed meeting dates. An + intelligent user agent would use this information to conduct a dialog + with the user, and might then send further mail based on that dialog. + More generally, there have been several "active" messaging languages + developed in which programs in a suitably specialized language are + sent through the mail and automatically run in the recipient's + environment. + + Such applications may be defined as subtypes of the "application" + Content-Type. This document defines two subtypes: octet-stream, and + PostScript. + + In general, the subtype of application will often be the name of the + application for which the data are intended. This does not mean, + however, that any application program name may be used freely as a + subtype of application. Such usages (other than subtypes beginning + + + +Borenstein & Freed [Page 49] + +RFC 1521 MIME September 1993 + + + with "x-") must be registered with IANA, as described in Appendix E. + +7.4.1. The Application/Octet-Stream (primary) subtype + + The primary subtype of application, "octet-stream", may be used to + indicate that a body contains binary data. The set of possible + parameters includes, but is not limited to: + + TYPE -- the general type or category of binary data. This is + intended as information for the human recipient rather than for + any automatic processing. + + PADDING -- the number of bits of padding that were appended to the + bit-stream comprising the actual contents to produce the enclosed + byte-oriented data. This is useful for enclosing a bit-stream in + a body when the total number of bits is not a multiple of the byte + size. + + An additional parameter, "conversions", was defined in [RFC-1341] but + has been removed. + + RFC 1341 also defined the use of a "NAME" parameter which gave a + suggested file name to be used if the data were to be written to a + file. This has been deprecated in anticipation of a separate + Content-Disposition header field, to be defined in a subsequent RFC. + + The recommended action for an implementation that receives + application/octet-stream mail is to simply offer to put the data in a + file, with any Content-Transfer-Encoding undone, or perhaps to use it + as input to a user-specified process. + + To reduce the danger of transmitting rogue programs through the mail, + it is strongly recommended that implementations NOT implement a + path-search mechanism whereby an arbitrary program named in the + Content-Type parameter (e.g., an "interpreter=" parameter) is found + and executed using the mail body as input. + +7.4.2. The Application/PostScript subtype + + A Content-Type of "application/postscript" indicates a PostScript + program. Currently two variants of the PostScript language are + allowed; the original level 1 variant is described in [POSTSCRIPT] + and the more recent level 2 variant is described in [POSTSCRIPT2]. + + PostScript is a registered trademark of Adobe Systems, Inc. Use of + the MIME content-type "application/postscript" implies recognition of + that trademark and all the rights it entails. + + + + +Borenstein & Freed [Page 50] + +RFC 1521 MIME September 1993 + + + The PostScript language definition provides facilities for internal + labeling of the specific language features a given program uses. This + labeling, called the PostScript document structuring conventions, is + very general and provides substantially more information than just + the language level. + + The use of document structuring conventions, while not required, is + strongly recommended as an aid to interoperability. Documents which + lack proper structuring conventions cannot be tested to see whether + or not they will work in a given environment. As such, some systems + may assume the worst and refuse to process unstructured documents. + + The execution of general-purpose PostScript interpreters entails + serious security risks, and implementors are discouraged from simply + sending PostScript email bodies to "off-the-shelf" interpreters. + While it is usually safe to send PostScript to a printer, where the + potential for harm is greatly constrained, implementors should + consider all of the following before they add interactive display of + PostScript bodies to their mail readers. + + The remainder of this section outlines some, though probably not all, + of the possible problems with sending PostScript through the mail. + + Dangerous operations in the PostScript language include, but may not + be limited to, the PostScript operators deletefile, renamefile, + filenameforall, and file. File is only dangerous when applied to + something other than standard input or output. Implementations may + also define additional nonstandard file operators; these may also + pose a threat to security. Filenameforall, the wildcard file search + operator, may appear at first glance to be harmless. Note, however, + that this operator has the potential to reveal information about what + files the recipient has access to, and this information may itself be + sensitive. Message senders should avoid the use of potentially + dangerous file operators, since these operators are quite likely to + be unavailable in secure PostScript implementations. Message- + receiving and -displaying software should either completely disable + all potentially dangerous file operators or take special care not to + delegate any special authority to their operation. These operators + should be viewed as being done by an outside agency when interpreting + PostScript documents. Such disabling and/or checking should be done + completely outside of the reach of the PostScript language itself; + care should be taken to insure that no method exists for re-enabling + full-function versions of these operators. + + The PostScript language provides facilities for exiting the normal + interpreter, or server, loop. Changes made in this "outer" + environment are customarily retained across documents, and may in + some cases be retained semipermanently in nonvolatile memory. The + + + +Borenstein & Freed [Page 51] + +RFC 1521 MIME September 1993 + + + operators associated with exiting the interpreter loop have the + potential to interfere with subsequent document processing. As such, + their unrestrained use constitutes a threat of service denial. + PostScript operators that exit the interpreter loop include, but may + not be limited to, the exitserver and startjob operators. Message- + sending software should not generate PostScript that depends on + exiting the interpreter loop to operate. The ability to exit will + probably be unavailable in secure PostScript implementations. + Message-receiving and -displaying software should, if possible, + disable the ability to make retained changes to the PostScript + environment, and eliminate the startjob and exitserver commands. If + these commands cannot be eliminated, the password associated with + them should at least be set to a hard-to-guess value. + + PostScript provides operators for setting system-wide and device- + specific parameters. These parameter settings may be retained across + jobs and may potentially pose a threat to the correct operation of + the interpreter. The PostScript operators that set system and device + parameters include, but may not be limited to, the setsystemparams + and setdevparams operators. Message-sending software should not + generate PostScript that depends on the setting of system or device + parameters to operate correctly. The ability to set these parameters + will probably be unavailable in secure PostScript implementations. + Message-receiving and -displaying software should, if possible, + disable the ability to change system and device parameters. If these + operators cannot be disabled, the password associated with them + should at least be set to a hard-to-guess value. + + Some PostScript implementations provide nonstandard facilities for + the direct loading and execution of machine code. Such facilities + are quite obviously open to substantial abuse. Message-sending + software should not make use of such features. Besides being totally + hardware- specific, they are also likely to be unavailable in secure + implementations of PostScript. Message-receiving and -displaying + software should not allow such operators to be used if they exist. + + PostScript is an extensible language, and many, if not most, + implementations of it provide a number of their own extensions. This + document does not deal with such extensions explicitly since they + constitute an unknown factor. Message-sending software should not + make use of nonstandard extensions; they are likely to be missing + from some implementations. Message-receiving and -displaying software + should make sure that any nonstandard PostScript operators are secure + and don't present any kind of threat. + + It is possible to write PostScript that consumes huge amounts of + various system resources. It is also possible to write PostScript + programs that loop infinitely. Both types of programs have the + + + +Borenstein & Freed [Page 52] + +RFC 1521 MIME September 1993 + + + potential to cause damage if sent to unsuspecting recipients. + Message-sending software should avoid the construction and + dissemination of such programs, which is antisocial. Message- + receiving and -displaying software should provide appropriate + mechanisms to abort processing of a document after a reasonable + amount of time has elapsed. In addition, PostScript interpreters + should be limited to the consumption of only a reasonable amount of + any given system resource. + + Finally, bugs may exist in some PostScript interpreters which could + possibly be exploited to gain unauthorized access to a recipient's + system. Apart from noting this possibility, there is no specific + action to take to prevent this, apart from the timely correction of + such bugs if any are found. + +7.4.3. Other Application subtypes + + It is expected that many other subtypes of application will be + defined in the future. MIME implementations must generally treat any + unrecognized subtypes as being equivalent to application/octet- + stream. + + The formal grammar for content-type header fields for application + data is given by: + + application-type := "application" "/" application-subtype + + application-subtype := ("octet-stream" *stream-param) + / "postscript" / extension-token + + stream-param := (";" "type" "=" value) + / (";" "padding" "=" padding) + + padding := "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" + +7.5. The Image Content-Type + + A Content-Type of "image" indicates that the body contains an image. + The subtype names the specific image format. These names are case + insensitive. Two initial subtypes are "jpeg" for the JPEG format, + JFIF encoding, and "gif" for GIF format [GIF]. + + The list of image subtypes given here is neither exclusive nor + exhaustive, and is expected to grow as more types are registered with + IANA, as described in Appendix E. + + The formal grammar for the content-type header field for data of type + image is given by: + + + +Borenstein & Freed [Page 53] + +RFC 1521 MIME September 1993 + + + image-type := "image" "/" ("gif" / "jpeg" / extension-token) + +7.6. The Audio Content-Type + + A Content-Type of "audio" indicates that the body contains audio + data. Although there is not yet a consensus on an "ideal" audio + format for use with computers, there is a pressing need for a format + capable of providing interoperable behavior. + + The initial subtype of "basic" is specified to meet this requirement + by providing an absolutely minimal lowest common denominator audio + format. It is expected that richer formats for higher quality and/or + lower bandwidth audio will be defined by a later document. + + The content of the "audio/basic" subtype is audio encoded using 8-bit + ISDN mu-law [PCM]. When this subtype is present, a sample rate of + 8000 Hz and a single channel is assumed. + + The formal grammar for the content-type header field for data of type + audio is given by: + + audio-type := "audio" "/" ("basic" / extension-token) + +7.7. The Video Content-Type + + A Content-Type of "video" indicates that the body contains a time- + varying-picture image, possibly with color and coordinated sound. + The term "video" is used extremely generically, rather than with + reference to any particular technology or format, and is not meant to + preclude subtypes such as animated drawings encoded compactly. The + subtype "mpeg" refers to video coded according to the MPEG standard + [MPEG]. + + Note that although in general this document strongly discourages the + mixing of multiple media in a single body, it is recognized that many + so-called "video" formats include a representation for synchronized + audio, and this is explicitly permitted for subtypes of "video". + + The formal grammar for the content-type header field for data of type + video is given by: + + video-type := "video" "/" ("mpeg" / extension-token) + +7.8. Experimental Content-Type Values + + A Content-Type value beginning with the characters "X-" is a private + value, to be used by consenting mail systems by mutual agreement. + Any format without a rigorous and public definition must be named + + + +Borenstein & Freed [Page 54] + +RFC 1521 MIME September 1993 + + + with an "X-" prefix, and publicly specified values shall never begin + with "X-". (Older versions of the widely-used Andrew system use the + "X-BE2" name, so new systems should probably choose a different + name.) + + In general, the use of "X-" top-level types is strongly discouraged. + Implementors should invent subtypes of the existing types whenever + possible. The invention of new types is intended to be restricted + primarily to the development of new media types for email, such as + digital odors or holography, and not for new data formats in general. + In many cases, a subtype of application will be more appropriate than + a new top-level type. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 55] + +RFC 1521 MIME September 1993 + + +8. Summary + + Using the MIME-Version, Content-Type, and Content-Transfer-Encoding + header fields, it is possible to include, in a standardized way, + arbitrary types of data objects with RFC 822 conformant mail + messages. No restrictions imposed by either RFC 821 or RFC 822 are + violated, and care has been taken to avoid problems caused by + additional restrictions imposed by the characteristics of some + Internet mail transport mechanisms (see Appendix B). The "multipart" + and "message" Content-Types allow mixing and hierarchical structuring + of objects of different types in a single message. Further Content- + Types provide a standardized mechanism for tagging messages or body + parts as audio, image, or several other kinds of data. A + distinguished parameter syntax allows further specification of data + format details, particularly the specification of alternate character + sets. Additional optional header fields provide mechanisms for + certain extensions deemed desirable by many implementors. Finally, a + number of useful Content-Types are defined for general use by + consenting user agents, notably message/partial, and + message/external-body. + +9. Security Considerations + + Security issues are discussed in Section 7.4.2 and in Appendix F. + Implementors should pay special attention to the security + implications of any mail content-types that can cause the remote + execution of any actions in the recipient's environment. In such + cases, the discussion of the application/postscript content-type in + Section 7.4.2 may serve as a model for considering other content- + types with remote execution capabilities. + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 56] + +RFC 1521 MIME September 1993 + + +10. Authors' Addresses + + For more information, the authors of this document may be contacted + via Internet mail: + + Nathaniel S. Borenstein + MRE 2D-296, Bellcore + 445 South St. + Morristown, NJ 07962-1910 + + Phone: +1 201 829 4270 + Fax: +1 201 829 7019 + Email: nsb@bellcore.com + + + Ned Freed + Innosoft International, Inc. + 250 West First Street + Suite 240 + Claremont, CA 91711 + + Phone: +1 909 624 7907 + Fax: +1 909 621 5319 + Email: ned@innosoft.com + + MIME is a result of the work of the Internet Engineering Task Force + Working Group on Email Extensions. The chairman of that group, Greg + Vaudreuil, may be reached at: + + Gregory M. Vaudreuil + Tigon Corporation + 17060 Dallas Parkway + Dallas Texas, 75248 + + Phone: +1 214-733-2722 + EMail: gvaudre@cnri.reston.va.us + + + + + + + + + + + + + + + +Borenstein & Freed [Page 57] + +RFC 1521 MIME September 1993 + + +11. Acknowledgements + + This document is the result of the collective effort of a large + number of people, at several IETF meetings, on the IETF-SMTP and + IETF-822 mailing lists, and elsewhere. Although any enumeration + seems doomed to suffer from egregious omissions, the following are + among the many contributors to this effort: + + Harald Tveit Alvestrand Timo Lehtinen + Randall Atkinson John R. MacMillan + Philippe Brandon Rick McGowan + Kevin Carosso Leo Mclaughlin + Uhhyung Choi Goli Montaser-Kohsari + Cristian Constantinof Keith Moore + Mark Crispin Tom Moore + Dave Crocker Erik Naggum + Terry Crowley Mark Needleman + Walt Daniels John Noerenberg + Frank Dawson Mats Ohrman + Hitoshi Doi Julian Onions + Kevin Donnelly Michael Patton + Keith Edwards David J. Pepper + Chris Eich Blake C. Ramsdell + Johnny Eriksson Luc Rooijakkers + Craig Everhart Marshall T. Rose + Patrik Faeltstroem Jonathan Rosenberg + Erik E. Fair Jan Rynning + Roger Fajman Harri Salminen + Alain Fontaine Michael Sanderson + James M. Galvin Masahiro Sekiguchi + Philip Gladstone Mark Sherman + Thomas Gordon Keld Simonsen + Phill Gross Bob Smart + James Hamilton Peter Speck + Steve Hardcastle-Kille Henry Spencer + David Herron Einar Stefferud + Bruce Howard Michael Stein + Bill Janssen Klaus Steinberger + Olle Jaernefors Peter Svanberg + Risto Kankkunen James Thompson + Phil Karn Steve Uhler + Alan Katz Stuart Vance + Tim Kehres Erik van der Poel + Neil Katin Guido van Rossum + Kyuho Kim Peter Vanderbilt + Anders Klemets Greg Vaudreuil + John Klensin Ed Vielmetti + Valdis Kletniek Ryan Waldron + + + +Borenstein & Freed [Page 58] + +RFC 1521 MIME September 1993 + + + Jim Knowles Wally Wedel + Stev Knowles Sven-Ove Westberg + Bob Kummerfeld Brian Wideen + Pekka Kytolaakso John Wobus + Stellan Lagerstrom Glenn Wright + Vincent Lau Rayan Zachariassen + Donald Lindsay David Zimmerman + Marc Andreessen Bob Braden + Brian Capouch Peter Clitherow + Dave Collier-Brown John Coonrod + Stephen Crocker Jim Davis + Axel Deininger Dana S Emery + Martin Forssen Stephen Gildea + Terry Gray Mark Horton + Warner Losh Carlyn Lowery + Laurence Lundblade Charles Lynn + Larry Masinter Michael J. McInerny + Jon Postel Christer Romson + Yutaka Sato Markku Savela + Richard Alan Schafer Larry W. Virden + Rhys Weatherly Jay Weber + Dave Wecker + +The authors apologize for any omissions from this list, which are +certainly unintentional. + + + + + + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 59] + +RFC 1521 MIME September 1993 + + +Appendix A -- Minimal MIME-Conformance + + The mechanisms described in this document are open-ended. It is + definitely not expected that all implementations will support all of + the Content-Types described, nor that they will all share the same + extensions. In order to promote interoperability, however, it is + useful to define the concept of "MIME-conformance" to define a + certain level of implementation that allows the useful interworking + of messages with content that differs from US ASCII text. In this + section, we specify the requirements for such conformance. + + A mail user agent that is MIME-conformant MUST: + + 1. Always generate a "MIME-Version: 1.0" header field. + + 2. Recognize the Content-Transfer-Encoding header field, and + decode all received data encoded with either the quoted-printable + or base64 implementations. Encode any data sent that is not in + seven-bit mail-ready representation using one of these + transformations and include the appropriate Content-Transfer- + Encoding header field, unless the underlying transport mechanism + supports non-seven-bit data, as SMTP does not. + + 3. Recognize and interpret the Content-Type header field, and + avoid showing users raw data with a Content-Type field other than + text. Be able to send at least text/plain messages, with the + character set specified as a parameter if it is not US-ASCII. + + 4. Explicitly handle the following Content-Type values, to at + least the following extents: + + Text: + + -- Recognize and display "text" mail + with the character set "US-ASCII." + + -- Recognize other character sets at + least to the extent of being able + to inform the user about what + character set the message uses. + + -- Recognize the "ISO-8859-*" character + sets to the extent of being able to + display those characters that are + common to ISO-8859-* and US-ASCII, + namely all characters represented + by octet values 0-127. + + + + +Borenstein & Freed [Page 60] + +RFC 1521 MIME September 1993 + + + -- For unrecognized subtypes, show or + offer to show the user the "raw" + version of the data after + conversion of the content from + canonical form to local form. + + Message: + + -- Recognize and display at least the + primary (822) encapsulation. + + Multipart: + + -- Recognize the primary (mixed) + subtype. Display all relevant + information on the message level + and the body part header level and + then display or offer to display + each of the body parts individually. + + -- Recognize the "alternative" subtype, + and avoid showing the user + redundant parts of + multipart/alternative mail. + + -- Treat any unrecognized subtypes as if + they were "mixed". + + Application: + + -- Offer the ability to remove either of + the two types of Content-Transfer- + Encoding defined in this document + and put the resulting information + in a user file. + + 5. Upon encountering any unrecognized Content- Type, an + implementation must treat it as if it had a Content-Type of + "application/octet-stream" with no parameter sub-arguments. How + such data are handled is up to an implementation, but likely + options for handling such unrecognized data include offering the + user to write it into a file (decoded from its mail transport + format) or offering the user to name a program to which the + decoded data should be passed as input. Unrecognized predefined + types, which in a MIME-conformant mailer might still include + audio, image, or video, should also be treated in this way. + + A user agent that meets the above conditions is said to be MIME- + + + +Borenstein & Freed [Page 61] + +RFC 1521 MIME September 1993 + + + conformant. The meaning of this phrase is that it is assumed to be + "safe" to send virtually any kind of properly-marked data to users of + such mail systems, because such systems will at least be able to + treat the data as undifferentiated binary, and will not simply splash + it onto the screen of unsuspecting users. There is another sense in + which it is always "safe" to send data in a format that is MIME- + conformant, which is that such data will not break or be broken by + any known systems that are conformant with RFC 821 and RFC 822. User + agents that are MIME-conformant have the additional guarantee that + the user will not be shown data that were never intended to be viewed + as text. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 62] + +RFC 1521 MIME September 1993 + + +Appendix B -- General Guidelines For Sending Email Data + + Internet email is not a perfect, homogeneous system. Mail may become + corrupted at several stages in its travel to a final destination. + Specifically, email sent throughout the Internet may travel across + many networking technologies. Many networking and mail technologies + do not support the full functionality possible in the SMTP transport + environment. Mail traversing these systems is likely to be modified + in such a way that it can be transported. + + There exist many widely-deployed non-conformant MTAs in the Internet. + These MTAs, speaking the SMTP protocol, alter messages on the fly to + take advantage of the internal data structure of the hosts they are + implemented on, or are just plain broken. + + The following guidelines may be useful to anyone devising a data + format (Content-Type) that will survive the widest range of + networking technologies and known broken MTAs unscathed. Note that + anything encoded in the base64 encoding will satisfy these rules, but + that some well-known mechanisms, notably the UNIX uuencode facility, + will not. Note also that anything encoded in the Quoted-Printable + encoding will survive most gateways intact, but possibly not some + gateways to systems that use the EBCDIC character set. + + (1) Under some circumstances the encoding used for data may change + as part of normal gateway or user agent operation. In particular, + conversion from base64 to quoted-printable and vice versa may be + necessary. This may result in the confusion of CRLF sequences with + line breaks in text bodies. As such, the persistence of CRLF as + something other than a line break must not be relied on. + + (2) Many systems may elect to represent and store text data using + local newline conventions. Local newline conventions may not match + the RFC822 CRLF convention -- systems are known that use plain CR, + plain LF, CRLF, or counted records. The result is that isolated + CR and LF characters are not well tolerated in general; they may + be lost or converted to delimiters on some systems, and hence must + not be relied on. + + (3) TAB (HT) characters may be misinterpreted or may be + automatically converted to variable numbers of spaces. This is + unavoidable in some environments, notably those not based on the + ASCII character set. Such conversion is STRONGLY DISCOURAGED, but + it may occur, and mail formats must not rely on the persistence of + TAB (HT) characters. + + (4) Lines longer than 76 characters may be wrapped or truncated in + some environments. Line wrapping and line truncation are STRONGLY + + + +Borenstein & Freed [Page 63] + +RFC 1521 MIME September 1993 + + + DISCOURAGED, but unavoidable in some cases. Applications which + require long lines must somehow differentiate between soft and + hard line breaks. (A simple way to do this is to use the quoted- + printable encoding.) + + (5) Trailing "white space" characters (SPACE, TAB (HT)) on a line + may be discarded by some transport agents, while other transport + agents may pad lines with these characters so that all lines in a + mail file are of equal length. The persistence of trailing white + space, therefore, must not be relied on. + + (6) Many mail domains use variations on the ASCII character set, + or use character sets such as EBCDIC which contain most but not + all of the US-ASCII characters. The correct translation of + characters not in the "invariant" set cannot be depended on across + character converting gateways. For example, this situation is a + problem when sending uuencoded information across BITNET, an + EBCDIC system. Similar problems can occur without crossing a + gateway, since many Internet hosts use character sets other than + ASCII internally. The definition of Printable Strings in X.400 + adds further restrictions in certain special cases. In + particular, the only characters that are known to be consistent + across all gateways are the 73 characters that correspond to the + upper and lower case letters A-Z and a-z, the 10 digits 0-9, and + the following eleven special characters: + + "'" (ASCII code 39) + "(" (ASCII code 40) + ")" (ASCII code 41) + "+" (ASCII code 43) + "," (ASCII code 44) + "-" (ASCII code 45) + "." (ASCII code 46) + "/" (ASCII code 47) + ":" (ASCII code 58) + "=" (ASCII code 61) + "?" (ASCII code 63) + + A maximally portable mail representation, such as the base64 + encoding, will confine itself to relatively short lines of text in + which the only meaningful characters are taken from this set of 73 + characters. + + (7) Some mail transport agents will corrupt data that includes + certain literal strings. In particular, a period (".") alone on a + line is known to be corrupted by some (incorrect) SMTP + implementations, and a line that starts with the five characters + "From " (the fifth character is a SPACE) are commonly corrupted as + + + +Borenstein & Freed [Page 64] + +RFC 1521 MIME September 1993 + + + well. A careful composition agent can prevent these corruptions + by encoding the data (e.g., in the quoted-printable encoding, + "=46rom " in place of "From " at the start of a line, and "=2E" in + place of "." alone on a line. + + Please note that the above list is NOT a list of recommended + practices for MTAs. RFC 821 MTAs are prohibited from altering the + character of white space or wrapping long lines. These BAD and + illegal practices are known to occur on established networks, and + implementations should be robust in dealing with the bad effects they + can cause. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 65] + +RFC 1521 MIME September 1993 + + +Appendix C -- A Complex Multipart Example + + What follows is the outline of a complex multipart message. This + message has five parts to be displayed serially: two introductory + plain text parts, an embedded multipart message, a richtext part, and + a closing encapsulated text message in a non-ASCII character set. + The embedded multipart message has two parts to be displayed in + parallel, a picture and an audio fragment. + + MIME-Version: 1.0 + From: Nathaniel Borenstein + To: Ned Freed + Subject: A multipart example + Content-Type: multipart/mixed; + boundary=unique-boundary-1 + + This is the preamble area of a multipart message. + Mail readers that understand multipart format + should ignore this preamble. + If you are reading this text, you might want to + consider changing to a mail reader that understands + how to properly display multipart messages. + --unique-boundary-1 + + ...Some text appears here... + [Note that the preceding blank line means + no header fields were given and this is text, + with charset US ASCII. It could have been + done with explicit typing as in the next part.] + + --unique-boundary-1 + Content-type: text/plain; charset=US-ASCII + + This could have been part of the previous part, + but illustrates explicit versus implicit + typing of body parts. + + --unique-boundary-1 + Content-Type: multipart/parallel; + boundary=unique-boundary-2 + + + --unique-boundary-2 + Content-Type: audio/basic + Content-Transfer-Encoding: base64 + + ... base64-encoded 8000 Hz single-channel + mu-law-format audio data goes here.... + + + +Borenstein & Freed [Page 66] + +RFC 1521 MIME September 1993 + + + --unique-boundary-2 + Content-Type: image/gif + Content-Transfer-Encoding: base64 + + ... base64-encoded image data goes here.... + + --unique-boundary-2-- + + --unique-boundary-1 + Content-type: text/richtext + + This is richtext. + as defined in RFC 1341 + Isn't it + cool? + + --unique-boundary-1 + Content-Type: message/rfc822 + + From: (mailbox in US-ASCII) + To: (address in US-ASCII) + Subject: (subject in US-ASCII) + Content-Type: Text/plain; charset=ISO-8859-1 + Content-Transfer-Encoding: Quoted-printable + + ... Additional text in ISO-8859-1 goes here ... + + --unique-boundary-1-- + + + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 67] + +RFC 1521 MIME September 1993 + + +Appendix D -- Collected Grammar + + This appendix contains the complete BNF grammar for all the syntax + specified by this document. + + By itself, however, this grammar is incomplete. It refers to several + entities that are defined by RFC 822. Rather than reproduce those + definitions here, and risk unintentional differences between the two, + this document simply refers the reader to RFC 822 for the remaining + definitions. Wherever a term is undefined, it refers to the RFC 822 + definition. + + application-subtype := ("octet-stream" *stream-param) + / "postscript" / extension-token + + application-type := "application" "/" application-subtype + + attribute := token ; case-insensitive + + atype := "ftp" / "anon-ftp" / "tftp" / "local-file" + / "afs" / "mail-server" / extension-token + ; Case-insensitive + + audio-type := "audio" "/" ("basic" / extension-token) + + body-part := <"message" as defined in RFC 822, + with all header fields optional, and with the + specified delimiter not occurring anywhere in + the message body, either on a line by itself + or as a substring anywhere.> + + NOTE: In certain transport enclaves, RFC 822 restrictions such as + the one that limits bodies to printable ASCII characters may not + be in force. (That is, the transport domains may resemble + standard Internet mail transport as specified in RFC821 and + assumed by RFC822, but without certain restrictions.) The + relaxation of these restrictions should be construed as locally + extending the definition of bodies, for example to include octets + outside of the ASCII range, as long as these extensions are + supported by the transport and adequately documented in the + Content-Transfer-Encoding header field. However, in no event are + headers (either message headers or body-part headers) allowed to + contain anything other than ASCII characters. + + + + + + + + +Borenstein & Freed [Page 68] + +RFC 1521 MIME September 1993 + + + boundary := 0*69 bcharsnospace + + bchars := bcharsnospace / " " + + bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" + / "," / "-" / "." / "/" / ":" / "=" / "?" + + charset := "us-ascii" / "iso-8859-1" / "iso-8859-2"/ "iso-8859-3" + / "iso-8859-4" / "iso-8859-5" / "iso-8859-6" / "iso-8859-7" + / "iso-8859-8" / "iso-8859-9" / extension-token + ; case insensitive + + close-delimiter := "--" boundary "--" CRLF;Again,no space by "--", + + content := "Content-Type" ":" type "/" subtype *(";" parameter) + ; case-insensitive matching of type and subtype + + delimiter := "--" boundary CRLF ;taken from Content-Type field. + ; There must be no space + ; between "--" and boundary. + + description := "Content-Description" ":" *text + + discard-text := *(*text CRLF) + + encapsulation := delimiter body-part CRLF + + encoding := "Content-Transfer-Encoding" ":" mechanism + + epilogue := discard-text ; to be ignored upon receipt. + + extension-token := x-token / iana-token + + external-param := (";" "access-type" "=" atype) + / (";" "expiration" "=" date-time) + + ; Note that date-time is quoted + / (";" "size" "=" 1*DIGIT) + / (";" "permission" "=" ("read" / "read-write")) + ; Permission is case-insensitive + / (";" "name" "=" value) + / (";" "site" "=" value) + / (";" "dir" "=" value) + / (";" "mode" "=" value) + / (";" "server" "=" value) + / (";" "subject" "=" value) + ;access-type required; others required based on access-type + + + + +Borenstein & Freed [Page 69] + +RFC 1521 MIME September 1993 + + + iana-token := + + id := "Content-ID" ":" msg-id + + image-type := "image" "/" ("gif" / "jpeg" / extension-token) + + mechanism := "7bit" ; case-insensitive + / "quoted-printable" + / "base64" + / "8bit" + / "binary" + / x-token + + message-subtype := "rfc822" + / "partial" 2#3partial-param + / "external-body" 1*external-param + / extension-token + + message-type := "message" "/" message-subtype + + multipart-body :=preamble 1*encapsulation close-delimiter epilogue + + multipart-subtype := "mixed" / "parallel" / "digest" + / "alternative" / extension-token + + multipart-type := "multipart" "/" multipart-subtype + ";" "boundary" "=" boundary + + octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") + ; octet must be used for characters > 127, =, SPACE, or + TAB, + ; and is recommended for any characters not listed in + ; Appendix B as "mail-safe". + + padding := "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" + + parameter := attribute "=" value + + partial-param := (";" "id" "=" value) + / (";" "number" "=" 1*DIGIT) + / (";" "total" "=" 1*DIGIT) + ; id & number required;total required for last part + + preamble := discard-text ; to be ignored upon receipt. + + ptext := octet / " / "@" + / "," / ";" / ":" / "\" / <"> + / "/" / "[" / "]" / "?" / "=" + ; Must be in quoted-string, + ; to use within parameter values + + + type := "application" / "audio" ; case-insensitive + / "image" / "message" + / "multipart" / "text" + / "video" / extension-token + ; All values case-insensitive + + value := token / quoted-string + + version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT + + video-type := "video" "/" ("mpeg" / extension-token) + + x-token := + + + + + + + + + + + + + +Borenstein & Freed [Page 71] + +RFC 1521 MIME September 1993 + + +Appendix E -- IANA Registration Procedures + + MIME has been carefully designed to have extensible mechanisms, and + it is expected that the set of content-type/subtype pairs and their + associated parameters will grow significantly with time. Several + other MIME fields, notably character set names, access-type + parameters for the message/external-body type, and possibly even + Content-Transfer-Encoding values, are likely to have new values + defined over time. In order to ensure that the set of such values is + developed in an orderly, well-specified, and public manner, MIME + defines a registration process which uses the Internet Assigned + Numbers Authority (IANA) as a central registry for such values. + + In general, parameters in the content-type header field are used to + convey supplemental information for various content types, and their + use is defined when the content-type and subtype are defined. New + parameters should not be defined as a way to introduce new + functionality. + + In order to simplify and standardize the registration process, this + appendix gives templates for the registration of new values with + IANA. Each of these is given in the form of an email message + template, to be filled in by the registering party. + + E.1 Registration of New Content-type/subtype Values + + Note that MIME is generally expected to be extended by subtypes. If + a new fundamental top-level type is needed, its specification must be + published as an RFC or submitted in a form suitable to become an RFC, + and be subject to the Internet standards process. + + To: IANA@isi.edu + Subject: Registration of new MIME + content-type/subtype + + MIME type name: + + (If the above is not an existing top-level MIME type, + please explain why an existing type cannot be used.) + + MIME subtype name: + + Required parameters: + + Optional parameters: + + Encoding considerations: + + + + +Borenstein & Freed [Page 72] + +RFC 1521 MIME September 1993 + + + Security considerations: + + Published specification: + + (The published specification must be an Internet RFC or + RFC-to-be if a new top-level type is being defined, and + must be a publicly available specification in any + case.) + + Person & email address to contact for further information: + + E.2 Registration of New Access-type Values + for Message/external-body + + To: IANA@isi.edu + Subject: Registration of new MIME Access-type for + Message/external-body content-type + + MIME access-type name: + + Required parameters: + + Optional parameters: + + Published specification: + + (The published specification must be an Internet RFC or + RFC-to-be.) + + Person & email address to contact for further information: + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 73] + +RFC 1521 MIME September 1993 + + +Appendix F -- Summary of the Seven Content-types + + Content-type: text + + Subtypes defined by this document: plain + + Important Parameters: charset + + Encoding notes: quoted-printable generally preferred if an encoding + is needed and the character set is mostly an ASCII superset. + + Security considerations: Rich text formats such as TeX and Troff + often contain mechanisms for executing arbitrary commands or file + system operations, and should not be used automatically unless + these security problems have been addressed. Even plain text may + contain control characters that can be used to exploit the + capabilities of "intelligent" terminals and cause security + violations. User interfaces designed to run on such terminals + should be aware of and try to prevent such problems. + + ________________________________________________________ + Content-type: multipart + + Subtypes defined by this document: mixed, alternative, + digest, parallel. + + Important Parameters: boundary + + Encoding notes: No content-transfer-encoding is permitted. + + ________________________________________________________ + Content-type: message + + Subtypes defined by this document: rfc822, partial, external-body + + Important Parameters: id, number, total, access-type, expiration, + size, permission, name, site, directory, mode, server, subject + + Encoding notes: No content-transfer-encoding is permitted. + Specifically, only "7bit" is permitted for "message/partial" or + "message/external-body", and only "7bit", "8bit", or "binary" are + permitted for other subtypes of "message". + ______________________________________________________________ + Content-type: application + + Subtypes defined by this document: octet-stream, postscript + + Important Parameters: type, padding + + + +Borenstein & Freed [Page 74] + +RFC 1521 MIME September 1993 + + + Deprecated Parameters: name and conversions were + defined in RFC 1341. + + Encoding notes: base64 preferred for unreadable subtypes. + + Security considerations: This type is intended for the + transmission of data to be interpreted by locally-installed + programs. If used, for example, to transmit executable + binary programs or programs in general-purpose interpreted + languages, such as LISP programs or shell scripts, severe + security problems could result. Authors of mail-reading + agents are cautioned against giving their systems the power + to execute mail-based application data without carefully + considering the security implications. While it is + certainly possible to define safe application formats and + even safe interpreters for unsafe formats, each interpreter + should be evaluated separately for possible security + problems. + ________________________________________________________________ + Content-type: image + + Subtypes defined by this document: jpeg, gif + + Important Parameters: none + + Encoding notes: base64 generally preferred + ________________________________________________________________ + Content-type: audio + + Subtypes defined by this document: basic + + Important Parameters: none + + Encoding notes: base64 generally preferred + ________________________________________________________________ + Content-type: video + + Subtypes defined by this document: mpeg + + Important Parameters: none + + Encoding notes: base64 generally preferred + + + + + + + + + +Borenstein & Freed [Page 75] + +RFC 1521 MIME September 1993 + + +Appendix G -- Canonical Encoding Model + + There was some confusion, in earlier drafts of this memo, regarding + the model for when email data was to be converted to canonical form + and encoded, and in particular how this process would affect the + treatment of CRLFs, given that the representation of newlines varies + greatly from system to system. For this reason, a canonical model + for encoding is presented below. + + The process of composing a MIME entity can be modeled as being done + in a number of steps. Note that these steps are roughly similar to + those steps used in RFC 1421 and are performed for each 'innermost + level' body: + + Step 1. Creation of local form. + + The body to be transmitted is created in the system's native format. + The native character set is used, and where appropriate local end of + line conventions are used as well. The body may be a UNIX-style text + file, or a Sun raster image, or a VMS indexed file, or audio data in + a system-dependent format stored only in memory, or anything else + that corresponds to the local model for the representation of some + form of information. Fundamentally, the data is created in the + "native" form specified by the type/subtype information. + + Step 2. Conversion to canonical form. + + The entire body, including "out-of-band" information such as record + lengths and possibly file attribute information, is converted to a + universal canonical form. The specific content type of the body as + well as its associated attributes dictate the nature of the canonical + form that is used. Conversion to the proper canonical form may + involve character set conversion, transformation of audio data, + compression, or various other operations specific to the various + content types. If character set conversion is involved, however, + care must be taken to understand the semantics of the content-type, + which may have strong implications for any character set conversion, + e.g. with regard to syntactically meaningful characters in a text + subtype other than "plain". + + For example, in the case of text/plain data, the text must be + converted to a supported character set and lines must be delimited + with CRLF delimiters in accordance with RFC822. Note that the + restriction on line lengths implied by RFC822 is eliminated if the + next step employs either quoted-printable or base64 encoding. + + + + + + +Borenstein & Freed [Page 76] + +RFC 1521 MIME September 1993 + + + Step 3. Apply transfer encoding. + + A Content-Transfer-Encoding appropriate for this body is applied. + Note that there is no fixed relationship between the content type and + the transfer encoding. In particular, it may be appropriate to base + the choice of base64 or quoted-printable on character frequency + counts which are specific to a given instance of a body. + + Step 4. Insertion into entity. + + The encoded object is inserted into a MIME entity with appropriate + headers. The entity is then inserted into the body of a higher-level + entity (message or multipart) if needed. + + It is vital to note that these steps are only a model; they are + specifically NOT a blueprint for how an actual system would be built. + In particular, the model fails to account for two common designs: + + 1. In many cases the conversion to a canonical form prior to + encoding will be subsumed into the encoder itself, which + understands local formats directly. For example, the local + newline convention for text bodies might be carried through to the + encoder itself along with knowledge of what that format is. + + 2. The output of the encoders may have to pass through one or + more additional steps prior to being transmitted as a message. As + such, the output of the encoder may not be conformant with the + formats specified by RFC822. In particular, once again it may be + appropriate for the converter's output to be expressed using local + newline conventions rather than using the standard RFC822 CRLF + delimiters. + + Other implementation variations are conceivable as well. The vital + aspect of this discussion is that, in spite of any optimizations, + collapsings of required steps, or insertion of additional processing, + the resulting messages must be consistent with those produced by the + model described here. For example, a message with the following + header fields: + + Content-type: text/foo; charset=bar + Content-Transfer-Encoding: base64 + + must be first represented in the text/foo form, then (if necessary) + represented in the "bar" character set, and finally transformed via + the base64 algorithm into a mail-safe form. + + + + + + +Borenstein & Freed [Page 77] + +RFC 1521 MIME September 1993 + + +Appendix H -- Changes from RFC 1341 + + This document is a relatively minor revision of RFC 1341. For + the convenience of those familiar with RFC 1341, the technical + changes from that document are summarized in this appendix. + + 1. The definition of "tspecials" has been changed to no longer + include ".". + + 2. The Content-ID field is now mandatory for message/external-body + parts. + + 3. The text/richtext type (including the old Section 7.1.3 and + Appendix D) has been moved to a separate document. + + 4. The rules on header merging for message/partial data have been + changed to treat the Encrypted and MIME-Version headers as special + cases. + + 5. The definition of the external-body access-type parameter has + been changed so that it can only indicate a single access method + (which was all that made sense). + + 6. There is a new "Subject" parameter for message/external-body, + access-type mail-server, to permit MIME-based use of mail servers + that rely on Subject field information. + + 7. The "conversions" parameter for application/octet-stream has been + removed. + + 8. Section 7.4.1 now deprecates the use of the "name" parameter for + application/octet-stream, as this will be superseded in the future by + a Content-Disposition header. + + 9. The formal grammar for multipart bodies has been changed so that + a CRLF is no longer required before the first boundary line. + + 10. MIME entities of type "message/partial" and "message/external- + body" are now required to use only the "7bit" transfer-encoding. + (Specifically, "binary" and "8bit" are not permitted.) + + 11. The "application/oda" content-type has been removed. + + 12. A note has been added to the end of section 7.2.3, explaining + the semantics of Content-ID in a multipart/alternative MIME entity. + + 13. The formal syntax for the "MIME-Version" field has been + tightened, but in a way that is completely compatible with the only + + + +Borenstein & Freed [Page 78] + +RFC 1521 MIME September 1993 + + + version number defined in RFC 1341. + + 14. In Section 7.3.1, the definition of message/rfc822 has been + relaxed regarding mandatory fields. + + All other changes from RFC 1341 were editorial changes and do not + affect the technical content of MIME. Considerable formal grammar + has been added, but this reflects the prose specification that was + already in place. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 79] + +RFC 1521 MIME September 1993 + + +References + + [US-ASCII] Coded Character Set--7-Bit American Standard Code for + Information Interchange, ANSI X3.4-1986. + + [ATK] Borenstein, Nathaniel S., Multimedia Applications Development + with the Andrew Toolkit, Prentice-Hall, 1990. + + [GIF] Graphics Interchange Format (Version 89a), Compuserve, Inc., + Columbus, Ohio, 1990. + + [ISO-2022] International Standard--Information Processing--ISO 7-bit + and 8-bit coded character sets--Code extension techniques, ISO + 2022:1986. + + [ISO-8859] Information Processing -- 8-bit Single-Byte Coded Graphic + Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987. Part + 2: Latin alphabet No. 2, ISO 8859-2, 1987. Part 3: Latin alphabet + No. 3, ISO 8859-3, 1988. Part 4: Latin alphabet No. 4, ISO 8859-4, + 1988. Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6: + Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7: Latin/Greek + alphabet, ISO 8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO + 8859-8, 1988. Part 9: Latin alphabet No. 5, ISO 8859-9, 1990. + + [ISO-646] International Standard--Information Processing--ISO 7-bit + coded character set for information interchange, ISO 646:1983. + + [MPEG] Video Coding Draft Standard ISO 11172 CD, ISO IEC/TJC1/SC2/WG11 + (Motion Picture Experts Group), May, 1991. + + [PCM] CCITT, Fascicle III.4 - Recommendation G.711, Geneva, 1972, + "Pulse Code Modulation (PCM) of Voice Frequencies". + + [POSTSCRIPT] Adobe Systems, Inc., PostScript Language Reference + Manual, Addison-Wesley, 1985. + + [POSTSCRIPT2] Adobe Systems, Inc., PostScript Language Reference + Manual, Addison-Wesley, Second Edition, 1990. + + [X400] Schicker, Pietro, "Message Handling Systems, X.400", Message + Handling Systems and Distributed Applications, E. Stefferud, O-j. + Jacobsen, and P. Schicker, eds., North-Holland, 1989, pp. 3-41. + + [RFC-783] Sollins, K., "TFTP Protocol (revision 2)", RFC 783, MIT, + June 1981. + + [RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC + 821, USC/Information Sciences Institute, August 1982. + + + +Borenstein & Freed [Page 80] + +RFC 1521 MIME September 1993 + + + [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + [RFC-934] Rose, M., and E. Stefferud, "Proposed Standard for Message + Encapsulation", RFC 934, Delaware and NMA, January 1985. + + [RFC-959] Postel, J. and J. Reynolds, "File Transfer Protocol", + STD 9, RFC 959, USC/Information Sciences Institute, October 1985. + + [RFC-1049] Sirbu, M., "Content-Type Header Field for Internet + Messages", STD 11, RFC 1049, CMU, March 1988. + + [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: + Part I - Message Encryption and Authentication Procedures", RFC + 1421, IAB IRTF PSRG, IETF PEM WG, February 1993. + + [RFC-1154] Robinson, D. and R. Ullmann, "Encoding Header Field for + Internet Messages", RFC 1154, Prime Computer, Inc., April 1990. + + [RFC-1341] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet + Mail Extensions): Mechanisms for Specifying and Describing the Format + of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June 1992. + + [RFC-1342] Moore, K., "Representation of Non-Ascii Text in Internet + Message Headers", RFC 1342, University of Tennessee, June 1992. + + [RFC-1343] Borenstein, N., "A User Agent Configuration Mechanism + for Multimedia Mail Format Information", RFC 1343, Bellcore, June + 1992. + + [RFC-1344] Borenstein, N., "Implications of MIME for Internet + Mail Gateways", RFC 1344, Bellcore, June 1992. + + [RFC-1345] Simonsen, K., "Character Mnemonics & Character Sets", + RFC 1345, Rationel Almen Planlaegning, June 1992. + + [RFC-1426] Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M., + Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIME + transport", RFC 1426, United Nations Universit, Innosoft, Dover Beach + Consulting, Inc., Network Management Associates, Inc., The Branch + Office, February 1993. + + [RFC-1522] Moore, K., "Representation of Non-Ascii Text in Internet + Message Headers" RFC 1522, University of Tennessee, September 1993. + + [RFC-1340] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC + 1340, USC/Information Sciences Institute, July 1992. + + + + +Borenstein & Freed [Page 81] + \ No newline at end of file diff --git a/RFC/rfc1725.txt b/RFC/rfc1725.txt new file mode 100644 index 00000000..43fcc518 --- /dev/null +++ b/RFC/rfc1725.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group J. Myers +Request for Comments: 1725 Carnegie Mellon +Obsoletes: 1460 M. Rose +Category: Standards Track Dover Beach Consulting, Inc. + November 1994 + + + 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. + +Overview + + This memo is a revision to RFC 1460, a Draft Standard. It makes the + following changes from that document: + + - removed text regarding "split-UA model", which didn't add + anything to the understanding of POP + + - clarified syntax of commands, keywords, and arguments + + - clarified behavior on broken connection + + - explicitly permitted an inactivity autologout timer + + - clarified the requirements of the "exclusive-access lock" + + - removed implementation-specific wording regarding the parsing of + the maildrop + + - allowed servers to close the connection after a failed + authentication command + + - removed the LAST command + + - fixed typo in example of TOP command + + - clarified that the second argument to the TOP command is non- + negative + + - added the optional UIDL command + + + + +Myers & Rose [Page 1] + +RFC 1725 POP3 November 1994 + + + - added warning regarding length of shared secrets with APOP + + - added additional warnings to the security considerations section + +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 is used + to allow a workstation to retrieve mail that the server is holding + for it. + + 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 (this relay host could be, but need not be, the + POP3 server host for the client host). + +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 + + + +Myers & Rose [Page 2] + +RFC 1725 POP3 November 1994 + + + (respectively) until the connection is closed or aborted. + + Commands in the POP3 consist of a 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. There are currently two status + indicators: positive ("+OK") and negative ("-ERR"). + + 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 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 + 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 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 + + + +Myers & Rose [Page 3] + +RFC 1725 POP3 November 1994 + + + 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 string terminated + by CRLF. An example might be: + + S: +OK POP3 server ready + + Note that this greeting is a POP3 reply. The POP3 server should + always give a positive response as the greeting. + + 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. The APOP + command is described later in this document. + + 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. + + 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. + + 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 the + maildrop cannot be opened for some reason (for example, a lock can + not be acquired, the client is denied access to the appropriate + 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 + + + +Myers & Rose [Page 4] + +RFC 1725 POP3 November 1994 + + + 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 n'th message + in a maildrop is assigned a message-number of "n". In POP3 commands + and responses, all message-number's and message sizes are expressed + in base-10 (i.e., decimal). + + Here are summaries for the three POP3 commands discussed thus far: + + 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 + + Possible Responses: + +OK name is a valid mailbox + -ERR never heard of mailbox name + + Examples: + C: USER mrose + S: +OK mrose is a real hoopy frood + ... + C: USER frated + S: -ERR sorry, no mailbox for frated here + + PASS string + + Arguments: + a server/mailbox-specific password (required) + + Restrictions: + may only be given in the AUTHORIZATION state after a + successful USER command + + Discussion: + 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. + + + +Myers & Rose [Page 5] + +RFC 1725 POP3 November 1994 + + + 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: +OK mrose's maildrop has 2 messages (320 octets) + ... + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + S: -ERR maildrop already locked + + 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. + + Here are the POP3 commands valid in the TRANSACTION state: + + STAT + + Arguments: none + + Restrictions: + may only be given in the TRANSACTION state + + + + + +Myers & Rose [Page 6] + +RFC 1725 POP3 November 1994 + + + 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 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 + + 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. + + + +Myers & Rose [Page 7] + +RFC 1725 POP3 November 1994 + + + 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. + + 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. + 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 + 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 + + + +Myers & Rose [Page 8] + +RFC 1725 POP3 November 1994 + + + 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: + 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 + + 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 + + + + +Myers & Rose [Page 9] + +RFC 1725 POP3 November 1994 + + + 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 + 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 + + + + +Myers & Rose [Page 10] + +RFC 1725 POP3 November 1994 + + + Restrictions: none + + Discussion: + The POP3 server removes all messages marked as deleted from + the maildrop. It then releases any exclusive-access lock + on the maildrop and replies as to the status of these + operations. The TCP connection is then closed. + + Possible Responses: + +OK + + Examples: + C: QUIT + S: +OK dewey POP3 server signing off (maildrop empty) + ... + C: QUIT + 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 + (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 + + + +Myers & Rose [Page 11] + +RFC 1725 POP3 November 1994 + + + line separating the headers from the body, and then the + number of lines 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 + S: + S: . + ... + C: TOP 100 3 + S: -ERR no such message + + UIDL [msg] + + Arguments: + a message-number (optionally) If a message-number is given, + it 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. + + + +Myers & Rose [Page 12] + +RFC 1725 POP3 November 1994 + + + 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 characters in the range 0x21 to 0x7E, + which uniquely identifies a message within a maildrop and + which persists across sessions. 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. + + 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 + + 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 + + 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. + + + +Myers & Rose [Page 13] + +RFC 1725 POP3 November 1994 + + + 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: + + + + 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 + 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). + + + + + +Myers & Rose [Page 14] + +RFC 1725 POP3 November 1994 + + + 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. 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 valid in the UPDATE state + + 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 + + + + + +Myers & Rose [Page 15] + +RFC 1725 POP3 November 1994 + + + 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. + +9. Example POP3 Session + + S: + C: + 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: + S: . + C: DELE 1 + S: +OK message 1 deleted + C: RETR 2 + S: +OK 200 octets + S: + S: . + C: DELE 2 + S: +OK message 2 deleted + C: QUIT + S: +OK dewey POP3 server signing off (maildrop empty) + C: + S: + +10. 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 + + + +Myers & Rose [Page 16] + +RFC 1725 POP3 November 1994 + + + 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 be counted twice, since the POP3 client will remove all byte- + stuffed termination characters when it receives a multi-line + response. + +11. 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. + +12. 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 must not allow both methods of access for a given user; that + is, for a given "USER name" either the PASS or 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. + +13. 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 [Page 17] + +RFC 1725 POP3 November 1994 + + +14. 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 [Page 18] + diff --git a/RFC/rfc1730.txt b/RFC/rfc1730.txt new file mode 100644 index 00000000..fcf72ad7 --- /dev/null +++ b/RFC/rfc1730.txt @@ -0,0 +1,4318 @@ + + + + + + +Network Working Group M. Crispin +Request for Comments: 1730 University of Washington +Category: Standards Track December 1994 + + + INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4 + + + +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 + + The Internet Message Access Protocol, Version 4 (IMAP4) allows a + client to access and manipulate electronic mail messages on a server. + IMAP4 permits manipulation of remote message folders, called + "mailboxes", in a way that is functionally equivalent to local + mailboxes. IMAP4 also provides the capability for an offline client + to resynchronize with the server (see also [IMAP-DISC]). + + IMAP4 includes operations for creating, deleting, and renaming + mailboxes; checking for new messages; permanently removing messages; + setting and clearing flags; RFC 822 and MIME parsing; searching; and + selective fetching of message attributes, texts, and portions + thereof. Messages in IMAP4 are accessed by the use of numbers. + These numbers are either message sequence numbers (relative position + from 1 to the number of messages in the mailbox) or unique + identifiers (immutable, strictly ascending values assigned to each + message, but which are not necessarily contiguous). + + IMAP4 supports a single server. A mechanism for supporting multiple + IMAP4 servers is discussed in [IMSP]. + + IMAP4 does not specify a means of posting mail; this function is + handled by a mail transfer protocol such as [SMTP]. + + IMAP4 is designed to be upwards compatible from the [IMAP2] protocol. + Compatibility issues are discussed in [IMAP-COMPAT]. + + + + + + +Crispin [Page i] + +RFC 1730 IMAP4 December 1994 + + + + + +Table of Contents + + + +IMAP4 Protocol Specification ...................................... 1 +1. Organization of this Document ............................. 1 +1.1. How to Read This Document ................................. 1 +1.2. Conventions Used in this Document ......................... 1 +2. Protocol Overview ......................................... 1 +2.1. Link Level ................................................ 1 +2.2. Commands and Responses .................................... 1 +2.2.1. Client Protocol Sender and Server Protocol Receiver ....... 2 +2.2.2. Server Protocol Sender and Client Protocol Receiver ....... 2 +3. State and Flow Diagram .................................... 4 +3.1. Non-Authenticated State ................................... 4 +3.2. Authenticated State ....................................... 4 +3.3. Selected State ............................................ 4 +3.4. Logout State .............................................. 4 +4. Data Formats .............................................. 6 +4.1. Atom ...................................................... 6 +4.2. Number .................................................... 6 +4.3. String .................................................... 6 +4.3.1. 8-bit and Binary Strings .................................. 7 +4.4. Parenthesized List ........................................ 7 +4.5. NIL ....................................................... 7 +5. Operational Considerations ................................ 8 +5.1. Mailbox Naming ............................................ 8 +5.2. Mailbox Size and Message Status Updates ................... 8 +5.3. Response when no Command in Progress ...................... 8 +5.4. Autologout Timer .......................................... 9 +5.5. Multiple Commands in Progress ............................. 9 +6. Client Commands ........................................... 10 +6.1. Client Commands - Any State ............................... 10 +6.1.1. CAPABILITY Command ........................................ 10 +6.1.2. NOOP Command .............................................. 11 +6.1.3. LOGOUT Command ............................................ 11 +6.2. Client Commands - Non-Authenticated State ................. 12 +6.2.1. AUTHENTICATE Command ...................................... 12 +6.2.2. LOGIN Command ............................................. 14 +6.3. Client Commands - Authenticated State ..................... 14 +6.3.1. SELECT Command ............................................ 15 +6.3.2. EXAMINE Command ........................................... 16 +6.3.3. CREATE Command ............................................ 17 +6.3.4. DELETE Command ............................................ 18 +6.3.5. RENAME Command ............................................ 18 + + + +Crispin [Page ii] + +RFC 1730 IMAP4 December 1994 + + +6.3.6. SUBSCRIBE Command ......................................... 19 +6.3.7. UNSUBSCRIBE Command ....................................... 19 +6.3.8. LIST Command .............................................. 20 +6.3.9. LSUB Command .............................................. 22 +6.3.10. APPEND Command ............................................ 22 +6.4. Client Commands - Selected State .......................... 23 +6.4.1. CHECK Command ............................................. 23 +6.4.2. CLOSE Command ............................................. 24 +6.4.3. EXPUNGE Command ........................................... 25 +6.4.4. SEARCH Command ............................................ 25 +6.4.5. FETCH Command ............................................. 29 +6.4.6. PARTIAL Command ........................................... 32 +6.4.7. STORE Command ............................................. 33 +6.4.8. COPY Command .............................................. 34 +6.4.9. UID Command ............................................... 35 +6.5. Client Commands - Experimental/Expansion .................. 37 +6.5.1. X Command ........................................... 37 +7. Server Responses .......................................... 38 +7.1. Server Responses - Status Responses ....................... 39 +7.1.1. OK Response ............................................... 40 +7.1.2. NO Response ............................................... 40 +7.1.3. BAD Response .............................................. 41 +7.1.4. PREAUTH Response .......................................... 41 +7.1.5. BYE Response .............................................. 41 +7.2. Server Responses - Server and Mailbox Status .............. 42 +7.2.1. CAPABILITY Response ....................................... 42 +7.2.2. LIST Response ............................................. 43 +7.2.3. LSUB Response ............................................. 44 +7.2.4. SEARCH Response ........................................... 44 +7.2.5. FLAGS Response ............................................ 44 +7.3. Server Responses - Message Status ......................... 45 +7.3.1. EXISTS Response ........................................... 45 +7.3.2. RECENT Response ........................................... 45 +7.3.3. EXPUNGE Response .......................................... 45 +7.3.4. FETCH Response ............................................ 46 +7.3.5. Obsolete Responses ........................................ 51 +7.4. Server Responses - Command Continuation Request ........... 51 +8. Sample IMAP4 session ...................................... 52 +9. Formal Syntax ............................................. 53 +10. Author's Note ............................................. 64 +11. Security Considerations ................................... 64 +12. Author's Address .......................................... 64 +Appendices ........................................................ 65 +A. Obsolete Commands ......................................... 65 +A.6.3.OBS.1. FIND ALL.MAILBOXES Command ........................ 65 +A.6.3.OBS.2. FIND MAILBOXES Command ............................ 65 +A.6.3.OBS.3. SUBSCRIBE MAILBOX Command ......................... 66 +A.6.3.OBS.4. UNSUBSCRIBE MAILBOX Command ....................... 66 + + + +Crispin [Page iii] + +RFC 1730 IMAP4 December 1994 + + +B. Obsolete Responses ........................................ 68 +B.7.2.OBS.1. MAILBOX Response .................................. 68 +B.7.3.OBS.1. COPY Response ..................................... 68 +B.7.3.OBS.2. STORE Response .................................... 69 +C. References ................................................ 70 +E. IMAP4 Keyword Index ....................................... 71 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin [Page iv] + +RFC 1730 IMAP4 December 1994 + + +IMAP4 Protocol Specification + +1. Organization of this Document + +1.1. How to Read This Document + + This document is written from the point of view of the implementor of + an IMAP4 client or server. Beyond the protocol overview in section + 2, it is not optimized for someone trying to understand the operation + of the protocol. The material in sections 3 through 5 provides the + general context and definitions with which IMAP4 operates. + + Sections 6, 7, and 9 describe the IMAP commands, responses, and + syntax, respectively. The relationships among these are such that it + is almost impossible to understand any of them separately. In + particular, one should not attempt to deduce command syntax from the + command section alone; one should instead refer to the formal syntax + section. + + +1.2. Conventions Used in this Document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + +2. Protocol Overview + +2.1. Link Level + + The IMAP4 protocol assumes a reliable data stream such as provided by + TCP. When TCP is used, an IMAP4 server listens on port 143. + + +2.2. Commands and Responses + + An IMAP4 session consists of the establishment of a client/server + connection, an initial greeting from the server, and client/server + interactions. These client/server interactions consist of a client + command, server data, and a server completion result response. + + All interactions transmitted by client and server are in the form of + lines; that is, strings that end with a CRLF. The protocol receiver + of an IMAP4 client or server is either reading a line, or is reading + a sequence of octets with a known count followed by a line. + + + + + + +Crispin [Page 1] + +RFC 1730 IMAP4 December 1994 + + +2.2.1. Client Protocol Sender and Server Protocol Receiver + + The client command begins an operation. Each client command is + prefixed with a identifier (typically a short alphanumeric string, + e.g. A0001, A0002, etc.) called a "tag". A different tag is + generated by the client for each command. + + There are two cases in which a line from the client does not + represent a complete command. In one case, a command argument is + quoted with an octet count (see the description of literal in String + under Data Formats); in the other case, the command arguments require + server feedback (see the AUTHENTICATE command). In either case, the + server sends a command continuation request response if it is ready + for the octets (if appropriate) and the remainder of the command. + This response is prefixed with the token "+". + + Note: If, instead, the server detected an error in the + command, it sends a BAD completion response with tag + matching the command (as described below) to reject the + command and prevent the client from sending any more of the + command. + + It is also possible for the server to send a completion + response for some other command (if multiple commands are + in progress), or untagged data. In either case, the + command continuation request is still pending; the client + takes the appropriate action for the response, and reads + another response from the server. + + The protocol receiver of an IMAP4 server reads a command line from + the client, parses the command and its arguments, and transmits + server data and a server command completion result response. + + +2.2.2. Server Protocol Sender and Client Protocol Receiver + + Data transmitted by the server to the client and status responses + that do not indicate command completion are prefixed with the token + "*", and are called untagged responses. + + Server data may be sent as a result of a client command, or may be + sent unilaterally by the server. There is no syntactic difference + between server data that resulted from a specific command and server + data that were sent unilaterally. + + The server completion result response indicates the success or + failure of the operation. It is tagged with the same tag as the + client command which began the operation. Thus, if more than one + + + +Crispin [Page 2] + +RFC 1730 IMAP4 December 1994 + + + command is in progress, the tag in a server completion response + identifies the command to which the response applies. There are + three possible server completion responses: OK (indicating success), + NO (indicating failure), or BAD (indicating protocol error such as + unrecognized command or command syntax error). + + The protocol receiver of an IMAP4 client reads a response line from + the server. It then takes action on the response based upon the + first token of the response, which may be a tag, a "*", or a "+". As + described above. + + A client MUST be prepared to accept any server response at all times. + This includes server data that it may not have requested. Server + data SHOULD be recorded, so that the client can reference its + recorded copy rather than sending a command to the server to request + the data. In the case of certain server data, recording the data is + mandatory. + + This topic is discussed in greater detail in the Server Responses + section. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin [Page 3] + +RFC 1730 IMAP4 December 1994 + + +3. State and Flow Diagram + + An IMAP4 server is in one of four states. Most commands are valid in + only certain states. It is a protocol error for the client to + attempt a command while the command is in an inappropriate state. In + this case, a server will respond with a BAD or NO (depending upon + server implementation) command completion result. + + +3.1. Non-Authenticated State + + In non-authenticated state, the user must supply authentication + credentials before most commands will be permitted. This state is + entered when a connection starts unless the connection has been + pre-authenticated. + + +3.2. Authenticated State + + In authenticated state, the user is authenticated and must select a + mailbox to access before commands that affect messages will be + permitted. This state is entered when a pre-authenticated connection + starts, when acceptable authentication credentials have been + provided, or after an error in selecting a mailbox. + + +3.3. Selected State + + In selected state, a mailbox has been selected to access. This state + is entered when a mailbox has been successfully selected. + + +3.4. Logout State + + In logout state, the session is being terminated, and the server will + close the connection. This state can be entered as a result of a + client request or by unilateral server decision. + + + + + + + + + + + + + + +Crispin [Page 4] + +RFC 1730 IMAP4 December 1994 + + + +--------------------------------------+ + |initial connection and server greeting| + +--------------------------------------+ + || (1) || (2) || (3) + VV || || + +-----------------+ || || + |non-authenticated| || || + +-----------------+ || || + || (7) || (4) || || + || VV VV || + || +----------------+ || + || | authenticated |<=++ || + || +----------------+ || || + || || (7) || (5) || (6) || + || || VV || || + || || +--------+ || || + || || |selected|==++ || + || || +--------+ || + || || || (7) || + VV VV VV VV + +--------------------------------------+ + | logout and close connection | + +--------------------------------------+ + + (1) connection without pre-authentication (OK greeting) + (2) pre-authenticated connection (PREAUTH greeting) + (3) rejected connection (BYE greeting) + (4) successful LOGIN or AUTHENTICATE command + (5) successful SELECT or EXAMINE command + (6) CLOSE command, or failed SELECT or EXAMINE command + (7) LOGOUT command, server shutdown, or connection closed + + + + + + + + + + + + + + + + + + + + +Crispin [Page 5] + +RFC 1730 IMAP4 December 1994 + + +4. Data Formats + + IMAP4 uses textual commands and responses. Data in IMAP4 can be in + one of several forms: atom, number, string, parenthesized list, or + NIL. + + +4.1. Atom + + An atom consists of one or more non-special characters. + + +4.2. Number + + A number consists of one or more digit characters, and represents a + numeric value. + + +4.3. String + + A string is in one of two forms: literal and quoted string. The + literal form is the general form of string. The quoted string form + is an alternative that avoids the overhead of processing a literal at + the cost of restrictions of what may be in a quoted string. + + A literal is a sequence of zero or more octets (including CR and LF), + prefix-quoted with an octet count in the form of an open brace ("{"), + the number of octets, close brace ("}"), and CRLF. In the case of + literals transmitted from server to client, the CRLF is immediately + followed by the octet data. In the case of literals transmitted from + client to server, the client must wait to receive a command + continuation request (described later in this document) before + sending the octet data (and the remainder of the command). + + A quoted string is a sequence of zero or more 7-bit characters, + excluding CR and LF, with double quote (<">) characters at each end. + + The empty string is respresented as either "" (a quoted string with + zero characters between double quotes) or as {0} followed by CRLF (a + literal with an octet count of 0). + + Note: Even if the octet count is 0, a client transmitting a + literal must wait to receive a command continuation + request. + + + + + + + +Crispin [Page 6] + +RFC 1730 IMAP4 December 1994 + + +4.3.1. 8-bit and Binary Strings + + 8-bit textual and binary mail is supported through the use of + [MIME-1] encoding. IMAP4 implementations MAY transmit 8-bit or + multi-octet characters in literals, but should do so only when the + character set is identified. + + Although a BINARY body encoding is defined, unencoded binary strings + are not permitted. A "binary string" is any string with NUL + characters. Implementations MUST encode binary data into a textual + form such as BASE64 before transmitting the data. A string with an + excessive amount of CTL characters may also be considered to be + binary, although this is not required. + + +4.4. Parenthesized List + + Data structures are represented as a "parenthesized list"; a sequence + of data items, delimited by space, and bounded at each end by + parentheses. A parenthesized list may itself contain other + parenthesized lists, using multiple levels of parentheses to indicate + nesting. + + The empty list is represented as () -- a parenthesized list with no + members. + + +4.5. NIL + + The special atom "NIL" represents the non-existence of a particular + data item that is represented as a string or parenthesized list, as + distinct from the empty string "" or the empty parenthesized list (). + + + + + + + + + + + + + + + + + + + +Crispin [Page 7] + +RFC 1730 IMAP4 December 1994 + + +5. Operational Considerations + +5.1. Mailbox Naming + + The interpretation of mailbox names is implementation-dependent. + However, the mailbox name INBOX is a special name reserved to mean + "the primary mailbox for this user on this server". If it is desired + to export hierarchical mailbox names, mailbox names must be + left-to-right hierarchical using a single character to separate + levels of hierarchy. The same hierarchy separator character is used + for all levels of hierarchy within a single name. + +5.2. Mailbox Size and Message Status Updates + + At any time, a server can send data that the client did not request. + Sometimes, such behavior is required. For example, agents other than + the server may add messages to the mailbox (e.g. new mail delivery), + change the flags of message in the mailbox (e.g. simultaneous access + to the same mailbox by multiple agents), or even remove messages from + the mailbox. A server MUST send mailbox size updates automatically + if a mailbox size change is observed during the processing of a + command. A server SHOULD send message flag updates automatically, + without requiring the client to request such updates explicitly. + Special rules exist for server notification of a client about the + removal of messages to prevent synchronization errors; see the + description of the EXPUNGE response for more details. + + Regardless of what implementation decisions a client may take on + remembering data from the server, a client implementation MUST record + mailbox size updates. It MUST NOT assume that any command after + initial mailbox selection will return the size of the mailbox. + + +5.3. Response when no Command in Progress + + Server implementations are permitted to send an untagged response + (except for EXPUNGE) while there is no command in progress. Server + implementations that send such responses MUST deal with flow control + considerations. Specifically, they must either (1) verify that the + size of the data does not exceed the underlying transport's available + window size, or (2) use non-blocking writes. + + + + + + + + + + +Crispin [Page 8] + +RFC 1730 IMAP4 December 1994 + + +5.4. Autologout Timer + + If a server has an inactivity autologout timer, that timer MUST be of + at least 30 minutes' duration. The receipt of ANY command from the + client during that interval should suffice to reset the autologout + timer. + + +5.5. Multiple Commands in Progress + + The client is not required to wait for the completion result response + of a command before sending another command, subject to flow control + constraints on the underlying data stream. Similarly, a server is + not required to process a command to completion before beginning + processing of the next command, unless an ambiguity would result + because of a command that would affect the results of other commands. + If there is such an ambiguity, the server executes commands to + completion in the order given by the client. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin [Page 9] + +RFC 1730 IMAP4 December 1994 + + +6. Client Commands + + IMAP4 commands are described in this section. Commands are organized + by the state in which the command is permitted. Commands which are + permitted in multiple states are listed in the minimum permitted + state (for example, commands valid in authenticated and selected + state are listed in the authenticated state commands). + + Command arguments, identified by "Arguments:" in the command + descriptions below, are described by function, not by syntax. The + precise syntax of command arguments is described in the Formal Syntax + section. + + Some commands cause specific server data to be returned; these are + identified by "Data:" in the command descriptions below. See the + response descriptions in the Responses section for information on + these responses, and the Formal Syntax section for the precise syntax + of these responses. It is possible for server data to be transmitted + as a result of any command; thus, commands that do not specifically + require server data specify "no specific data for this command" + instead of "none". + + The "Result:" in the command description refers to the possible + tagged status responses to a command, and any special interpretation + of these status responses. + + +6.1. Client Commands - Any State + + The following commands are valid in any state: CAPABILITY, NOOP, and + LOGOUT. + +6.1.1. CAPABILITY Command + + Arguments: none + + Data: mandatory untagged response: CAPABILITY + + Result: OK - capability completed + BAD - command unknown or arguments invalid + + The CAPABILITY command requests a listing of capabilities that the + server supports. The server MUST send a single untagged + CAPABILITY response with "IMAP4" as the first listed capability + before the (tagged) OK response. This listing of capabilities is + not dependent upon connection state or user. It is therefore not + necessary to issue a CAPABILITY command more than once in a + session. + + + +Crispin [Page 10] + +RFC 1730 IMAP4 December 1994 + + + Capability names other than "IMAP4" refer to extensions, + revisions, or amendments to this specification. See the + documentation of the CAPABILITY response for additional + information. No capabilities are enabled without explicit client + action to invoke the capability. See the section entitled "Client + Commands - Experimental/Expansion" for information about the form + of site or implementation-specific capabilities. + + Example: C: abcd CAPABILITY + S: * CAPABILITY IMAP4 + S: abcd OK CAPABILITY completed + + +6.1.2. NOOP Command + + Arguments: none + + Data: no specific data for this command (but see below) + + Result: OK - noop completed + BAD - command unknown or arguments invalid + + The NOOP command always succeeds. It does nothing. + + Since any command can return a status update as untagged data, the + NOOP command can be used as a periodic poll for new messages or + message status updates during a period of inactivity. The NOOP + command can also be used to reset any inactivity autologout timer + on the server. + + Example: C: a002 NOOP + S: a002 OK NOOP completed + . . . + C: a047 NOOP + S: * 22 EXPUNGE + S: * 23 EXISTS + S: * 3 RECENT + S: * 14 FETCH (FLAGS (\Seen \Deleted)) + S: a047 OK NOOP completed + + + + + + + + + + + + +Crispin [Page 11] + +RFC 1730 IMAP4 December 1994 + + +6.1.3. LOGOUT Command + + Arguments: none + + Data: mandatory untagged response: BYE + + Result: OK - logout completed + BAD - command unknown or arguments invalid + + The LOGOUT command informs the server that the client is done with + the session. The server must send a BYE untagged response before + the (tagged) OK response, and then close the network connection. + + Example: C: A023 LOGOUT + S: * BYE IMAP4 Server logging out + S: A023 OK LOGOUT completed + (Server and client then close the connection) + + + +6.2. Client Commands - Non-Authenticated State + + In non-authenticated state, the AUTHENTICATE or LOGIN command + establishes authentication and enter authenticated state. The + AUTHENTICATE command provides a general mechanism for a variety of + authentication techniques, whereas the LOGIN command uses the + traditional user name and plaintext password pair. + + Server implementations may allow non-authenticated access to certain + mailboxes. The convention is to use a LOGIN command with the userid + "anonymous". A password is required. It is implementation-dependent + what requirements, if any, are placed on the password and what access + restrictions are placed on anonymous users. + + Once authenticated (including as anonymous), it is not possible to + re-enter non-authenticated state. + + In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), + the following commands are valid in non-authenticated state: + AUTHENTICATE and LOGIN. + + + + + + + + + + + +Crispin [Page 12] + +RFC 1730 IMAP4 December 1994 + + +6.2.1. AUTHENTICATE Command + + Arguments: authentication mechanism name + + Data: continuation data may be requested + + Result: OK - authenticate completed, now in authenticated state + NO - authenticate failure: unsupported authentication + mechanism, credentials rejected + BAD - command unknown or arguments invalid, + authentication exchange cancelled + + The AUTHENTICATE command indicates an authentication mechanism, + such as described in [IMAP-AUTH], to the server. If the server + supports the requested authentication mechanism, it performs an + authentication protocol exchange to authenticate and identify the + user. Optionally, it also negotiates a protection mechanism for + subsequent protocol interactions. If the requested authentication + mechanism is not supported, the server should reject the + AUTHENTICATE command by sending a tagged NO response. + + The authentication protocol exchange consists of a series of + server challenges and client answers that are specific to the + authentication mechanism. A server challenge consists of a + command continuation request response with the "+" token followed + by a BASE64 encoded string. The client answer consists of a line + consisting of a BASE64 encoded string. If the client wishes to + cancel an authentication exchange, it should issue a line with a + single "*". If the server receives such an answer, it must reject + the AUTHENTICATE command by sending a tagged BAD response. + + A protection mechanism provides integrity and privacy protection + to the protocol session. If a protection mechanism is negotiated, + it is applied to all subsequent data sent over the connection. + The protection mechanism takes effect immediately following the + CRLF that concludes the authentication exchange for the client, + and the CRLF of the tagged OK response for the server. Once the + protection mechanism is in effect, the stream of command and + response octets is processed into buffers of ciphertext. Each + buffer is transferred over the connection as a stream of octets + prepended with a four octet field in network byte order that + represents the length of the following data. The maximum + ciphertext buffer length is defined by the protection mechanism. + + The server is not required to support any particular + authentication mechanism, nor are authentication mechanisms + required to support any protection mechanisms. If an AUTHENTICATE + command fails with a NO response, the client may try another + + + +Crispin [Page 13] + +RFC 1730 IMAP4 December 1994 + + + authentication mechanism by issuing another AUTHENTICATE command, + or may attempt to authenticate by using the LOGIN command. In + other words, the client may request authentication types in + decreasing order of preference, with the LOGIN command as a last + resort. + + Example: S: * OK KerberosV4 IMAP4 Server + C: A001 AUTHENTICATE KERBEROS_V4 + S: + AmFYig== + C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT + +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd + WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh + S: + or//EoAADZI= + C: DiAF5A4gA+oOIALuBkAAmw== + S: A001 OK Kerberos V4 authentication successful + + Note: the line breaks in the first client answer are for + editorial clarity and are not in real authenticators. + + +6.2.2. LOGIN Command + + Arguments: user name + password + + Data: no specific data for this command + + Result: OK - login completed, now in authenticated state + NO - login failure: user name or password rejected + BAD - command unknown or arguments invalid + + The LOGIN command identifies the user to the server and carries + the plaintext password authenticating this user. + + Example: C: a001 LOGIN SMITH SESAME + S: a001 OK LOGIN completed + + + +6.3. Client Commands - Authenticated State + + In authenticated state, commands that manipulate mailboxes as atomic + entities are permitted. Of these commands, the SELECT and EXAMINE + commands will select a mailbox for access and enter selected state. + + + + + + + +Crispin [Page 14] + +RFC 1730 IMAP4 December 1994 + + + In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), + the following commands are valid in authenticated state: SELECT, + EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, + and APPEND. + +6.3.1. SELECT Command + + Arguments: mailbox name + + Data: mandatory untagged responses: FLAGS, EXISTS, RECENT + optional OK untagged responses: UNSEEN, PERMANENTFLAGS + + Result: OK - select completed, now in selected state + NO - select failure, now in authenticated state: no + such mailbox, can't access mailbox + BAD - command unknown or arguments invalid + + The SELECT command selects a mailbox so that messages in the + mailbox can be accessed. Before returning an OK to the client, + the server MUST send the following untagged data to the client: + + FLAGS Defined flags in the mailbox + + EXISTS The number of messages in the mailbox + + RECENT The number of messages added to the mailbox since + the previous time this mailbox was read + + OK [UIDVALIDITY ] + The unique identifier validity value. See the + description of the UID command for more detail. + + to define the initial state of the mailbox at the client. If it + is not possible to determine the messages that were added since + the previous time a mailbox was read, then all messages SHOULD be + considered recent. + + The server SHOULD also send an UNSEEN response code in an OK + untagged response, indicating the message sequence number of the + first unseen message in the mailbox. + + If the client can not change the permanent state of one or more of + the flags listed in the FLAGS untagged response, the server SHOULD + send a PERMANENTFLAGS response code in an OK untagged response, + listing the flags that the client may change permanently. + + Only one mailbox may be selected at a time in a session; + simultaneous access to multiple mailboxes requires multiple + + + +Crispin [Page 15] + +RFC 1730 IMAP4 December 1994 + + + sessions. The SELECT command automatically deselects any + currently selected mailbox before attempting the new selection. + Consequently, if a mailbox is selected and a SELECT command that + fails is attempted, no mailbox is selected. + + If the user is permitted to modify the mailbox, the server SHOULD + prefix the text of the tagged OK response with the "[READ-WRITE]" + response code. + + If the user is not permitted to modify the mailbox but is + permitted read access, the mailbox is selected as read-only, and + the server MUST prefix the text of the tagged OK response to + SELECT with the "[READ-ONLY]" response code. Read-only access + through SELECT differs from the EXAMINE command in that certain + read-only mailboxes may permit the change of permanent state on a + per-user (as opposed to global) basis. Netnews messages marked in + a user's .newsrc file are an example of such per-user permanent + state that can be modified with read-only mailboxes. + + Example: C: A142 SELECT INBOX + S: * 172 EXISTS + S: * 1 RECENT + S: * OK [UNSEEN 12] Message 12 is first unseen + S: * OK [UIDVALIDITY 3857529045] UIDs valid + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited + S: A142 OK [READ-WRITE] SELECT completed + + +6.3.2. EXAMINE Command + + Arguments: mailbox name + + Data: mandatory untagged responses: FLAGS, EXISTS, RECENT + optional OK untagged responses: UNSEEN, PERMANENTFLAGS + + Result: OK - examine completed, now in selected state + NO - examine failure, now in authenticated state: no + such mailbox, can't access mailbox + BAD - command unknown or arguments invalid + + The EXAMINE command is identical to SELECT and returns the same + output; however, the selected mailbox is identified as read-only. + No changes to the permanent state of the mailbox, including + per-user state, are permitted. + + + + + + +Crispin [Page 16] + +RFC 1730 IMAP4 December 1994 + + + The text of the tagged OK response to the EXAMINE command MUST + begin with the "[READ-ONLY]" response code. + + Example: C: A932 EXAMINE blurdybloop + S: * 17 EXISTS + S: * 2 RECENT + S: * OK [UNSEEN 8] Message 8 is first unseen + S: * OK [UIDVALIDITY 3857529045] UIDs valid + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + S: * OK [PERMANENTFLAGS ()] No permanent flags permitted + S: A932 OK [READ-ONLY] EXAMINE completed + + +6.3.3. CREATE Command + + Arguments: mailbox name + + Data: no specific data for this command + + Result: OK - create completed + NO - create failure: can't create mailbox with that name + BAD - command unknown or arguments invalid + + The CREATE command creates a mailbox with the given name. An OK + response is returned only if a new mailbox with that name has been + created. It is an error to attempt to create INBOX or a mailbox + with a name that refers to an extant mailbox. Any error in + creation will return a tagged NO response. + + If the mailbox name is suffixed with the server's hierarchy + separator character (as returned from the server by a LIST + command), this is a declaration that the client may, in the + future, create mailbox names under this name in the hierarchy. + Server implementations that do not require this declaration MUST + ignore it. + + If a new mailbox is created with the same name as a mailbox which + was deleted, its unique identifiers MUST be greater than any + unique identifiers used in the previous incarnation of the mailbox + UNLESS the new incarnation has a different unique identifier + validity value. See the description of the UID command for more + detail. + + Example: C: A003 CREATE owatagusiam/ + S: A003 OK CREATE completed + C: A004 CREATE owatagusiam/blurdybloop + S: A004 OK CREATE completed + + + + +Crispin [Page 17] + +RFC 1730 IMAP4 December 1994 + + + Note: the interpretation of this example depends on whether + "/" was returned as the hierarchy separator from LIST. If + "/" is the hierarchy separator, a new level of hierarchy + named "owatagusiam" with a member called "blurdybloop" is + created. Otherwise, two mailboxes at the same hierarchy + level are created. + + +6.3.4. DELETE Command + + Arguments: mailbox name + + Data: no specific data for this command + + Result: OK - delete completed + NO - delete failure: can't delete mailbox with that name + BAD - command unknown or arguments invalid + + The DELETE command permanently removes the mailbox with the given + name. A tagged OK response is returned only if the mailbox has + been deleted. It is an error to attempt to delete INBOX or a + mailbox name that does not exist. Any error in deletion will + return a tagged NO response. + + The value of the highest-used unique indentifier of the deleted + mailbox MUST be preserved so that a new mailbox created with the + same name will not reuse the identifiers of the former + incarnation, UNLESS the new incarnation has a different unique + identifier validity value. See the description of the UID command + for more detail. + + Example: C: A683 DELETE blurdybloop + S: A683 OK DELETE completed + + +6.3.5. RENAME Command + + Arguments: existing mailbox name + new mailbox name + + Data: no specific data for this command + + Result: OK - rename completed + NO - rename failure: can't rename mailbox with that name, + can't rename to mailbox with that name + BAD - command unknown or arguments invalid + + + + + +Crispin [Page 18] + +RFC 1730 IMAP4 December 1994 + + + The RENAME command changes the name of a mailbox. A tagged OK + response is returned only if the mailbox has been renamed. It is + an error to attempt to rename from a mailbox name that does not + exist or to a mailbox name that already exists. Any error in + renaming will return a tagged NO response. + + Renaming INBOX is permitted; a new, empty INBOX is created in its + place. + + Example: C: Z4S9 RENAME blurdybloop owatagusiam + S: Z4S9 OK RENAME completed + + +6.3.6. SUBSCRIBE Command + + Arguments: mailbox + + Data: no specific data for this command + + Result: OK - subscribe completed + NO - subscribe failure: can't subscribe to that name + BAD - command unknown or arguments invalid + + The SUBSCRIBE command adds the specified mailbox name to the + server's set of "active" or "subscribed" mailboxes as returned by + the LSUB command. This command returns a tagged OK response only + if the subscription is successful. + + Example: C: A002 SUBSCRIBE #news.comp.mail.mime + S: A002 OK SUBSCRIBE completed + + +6.3.7. UNSUBSCRIBE Command + + Arguments: mailbox name + + Data: no specific data for this command + + Result: OK - unsubscribe completed + NO - unsubscribe failure: can't unsubscribe that name + BAD - command unknown or arguments invalid + + The UNSUBSCRIBE command removes the specified mailbox name from + the server's set of "active" or "subscribed" mailboxes as returned + by the LSUB command. This command returns a tagged OK response + only if the unsubscription is successful. + + + + + +Crispin [Page 19] + +RFC 1730 IMAP4 December 1994 + + + Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime + S: A002 OK UNSUBSCRIBE completed + + +6.3.8. LIST Command + + Arguments: reference name + mailbox name with possible wildcards + + Data: untagged responses: LIST + + Result: OK - list completed + NO - list failure: can't list that reference or name + BAD - command unknown or arguments invalid + + The LIST command returns a subset of names from the complete set + of all names available to the user. Zero or more untagged LIST + replies are returned, containing the name attributes, hierarchy + delimiter, and name; see the description of the LIST reply for + more detail. + + An empty ("" string) reference name argument indicates that the + mailbox name is interpreted as by SELECT. The returned mailbox + names MUST match the supplied mailbox name pattern. A non-empty + reference name argument is the name of a mailbox or a level of + mailbox hierarchy, and indicates a context in which the mailbox + name is interpreted in an implementation-defined manner. + + The reference and mailbox name arguments are interpreted, in an + implementation-dependent fashion, into a canonical form that + represents an unambiguous left-to-right hierarchy. The returned + mailbox names will be in the interpreted form. + + Any part of the reference argument that is included in the + interpreted form SHOULD prefix the interpreted form. It should + also be in the same form as the reference name argument. This + rule permits the client to determine if the returned mailbox name + is in the context of the reference argument, or if something about + the mailbox argument overrode the reference argument. Without + this rule, the client would have to have knowledge of the server's + naming semantics including what characters are "breakouts" that + override a naming context. + + + + + + + + + +Crispin [Page 20] + +RFC 1730 IMAP4 December 1994 + + + For example, here are some examples of how references + and mailbox names might be interpreted on a UNIX-based + server: + + Reference Mailbox Name Interpretation + ------------ ------------ -------------- + ~smith/Mail/ foo.* ~smith/Mail/foo.* + archive/ % archive/% + #news. comp.mail.* #news.comp.mail.* + ~smith/Mail/ /usr/doc/foo /usr/doc/foo + archive/ ~fred/Mail/* ~fred/Mail/* + + The first three examples demonstrate interpretations in + the context of the reference argument. Note that + "~smith/Mail" should not be transformed into something + like "/u2/users/smith/Mail", or it would be impossible + for the client to determine that the interpretation was + in the context of the reference. + + The character "*" is a wildcard, and matches zero or more + characters at this position. The character "%" is similar to "*", + but it does not match a hierarchy delimiter. If the "%" wildcard + is the last character of a mailbox name argument, matching levels + of hierarchy are also returned. If these levels of hierarchy are + not also selectable mailboxes, they are returned with the + \Noselect mailbox name attribute (see the description of the LIST + response for more detail). + + Server implementations are permitted to "hide" otherwise + accessible mailboxes from the wildcard characters, by preventing + certain characters or names from matching a wildcard in certain + situations. For example, a UNIX-based server might restrict the + interpretation of "*" so that an initial "/" character does not + match. + + The special name INBOX is included in the output from LIST if it + matches the input arguments and INBOX is supported by this server + for this user. The criteria for omitting INBOX is whether SELECT + INBOX will return failure; it is not relevant whether the user's + real INBOX resides on this or some other server. + + Example: C: A002 LIST "~/Mail/" "%" + S: * LIST (\Noselect) "/" ~/Mail/foo + S: * LIST () "/" ~/Mail/meetings + S: A002 OK LIST completed + + + + + + +Crispin [Page 21] + +RFC 1730 IMAP4 December 1994 + + +6.3.9. LSUB Command + + Arguments: reference name + mailbox name with possible wildcards + + Data: untagged responses: LSUB + + Result: OK - lsub completed + NO - lsub failure: can't list that reference or name + BAD - command unknown or arguments invalid + + The LSUB command returns a subset of names from the set of names + that the user has declared as being "active" or "subscribed". + Zero or more untagged LSUB replies are returned. The arguments to + LSUB are in the same form as those for LIST. + + Example: C: A002 LSUB "#news." "comp.mail.*" + S: * LSUB () "." #news.comp.mail.mime + S: * LSUB () "." #news.comp.mail.misc + S: A002 OK LSUB completed + + +6.3.10. APPEND Command + + Arguments: mailbox name + optional flag parenthesized list + optional date/time string + message literal + + Data: no specific data for this command + + Result: OK - append completed + NO - append error: can't append to that mailbox, error + in flags or date/time or message text + BAD - command unknown or arguments invalid + + The APPEND command appends the literal argument as a new message + in the specified destination mailbox. This argument is in the + format of an [RFC-822] message. 8-bit characters are permitted in + the message. A server implementation that is unable to preserve + 8-bit data properly MUST be able to reversibly convert 8-bit + APPEND data to 7-bit using [MIME-1] encoding. + + If a flag parenthesized list or date_time are specified, that data + SHOULD be set in the resulting message; otherwise, the defaults of + empty flags and the current date/time are used. + + + + + +Crispin [Page 22] + +RFC 1730 IMAP4 December 1994 + + + If the append is unsuccessful for any reason, the mailbox MUST be + restored to its state before the APPEND attempt; no partial + appending is permitted. If the mailbox is currently selected, the + normal new mail actions should occur. + + If the destination mailbox does not exist, a server MUST return an + error, and MUST NOT automatically create the mailbox. Unless it + is certain that the destination mailbox can not be created, the + server MUST send the response code "[TRYCREATE]" as the prefix of + the text of the tagged NO response. This gives a hint to the + client that it can attempt a CREATE command and retry the APPEND + if the CREATE is successful. + + Example: C: A003 APPEND saved-messages (\Seen) {310} + C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) + C: From: Fred Foobar + C: Subject: afternoon meeting + C: To: mooch@owatagu.siam.edu + C: Message-Id: + C: MIME-Version: 1.0 + C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII + C: + C: Hello Joe, do you think we can meet at 3:30 tomorrow? + C: + S: A003 OK APPEND completed + + Note: the APPEND command is not used for message delivery, + because it does not provide a mechanism to transfer [SMTP] + envelope information. + + + +6.4. Client Commands - Selected State + + In selected state, commands that manipulate messages in a mailbox are + permitted. + + In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), + and the authenticated state commands (SELECT, EXAMINE, CREATE, + DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, FIND + ALL.MAILBOXES, FIND MAILBOXES, and APPEND), the following commands + are valid in the selected state: CHECK, CLOSE, EXPUNGE, SEARCH, + FETCH, PARTIAL, STORE, COPY, and UID. + + + + + + + + +Crispin [Page 23] + +RFC 1730 IMAP4 December 1994 + + +6.4.1. CHECK Command + + Arguments: none + + Data: no specific data for this command + + Result: OK - check completed + BAD - command unknown or arguments invalid + + The CHECK command requests a checkpoint of the currently selected + mailbox. A checkpoint refers to any implementation-dependent + housekeeping associated with the mailbox (e.g. resolving the + server's in-memory state of the mailbox with the state on its + disk) that is not normally executed as part of each command. A + checkpoint may take a non-instantaneous amount of real time to + complete. If a server implementation has no such housekeeping + considerations, CHECK is equivalent to NOOP. + + There is no guarantee that an EXISTS untagged response will happen + as a result of CHECK. NOOP, not CHECK, should be used for new + mail polling. + + Example: C: FXXZ CHECK + S: FXXZ OK CHECK Completed + + +6.4.2. CLOSE Command + + Arguments: none + + Data: no specific data for this command + + Result: OK - close completed, now in authenticated state + NO - close failure: no mailbox selected + BAD - command unknown or arguments invalid + + The CLOSE command permanently removes from the currently selected + mailbox all messages that have the \Deleted flag set, and returns + to authenticated state from selected state. No untagged EXPUNGE + responses are sent. + + No messages are removed, and no error is given, if the mailbox is + selected by an EXAMINE command or is otherwise selected read-only. + + Even when a mailbox is selected, it is not required to send a + CLOSE command before a SELECT, EXAMINE, or LOGOUT command. The + SELECT, EXAMINE, and LOGOUT commands implicitly close the + currently selected mailbox without doing an expunge. However, + + + +Crispin [Page 24] + +RFC 1730 IMAP4 December 1994 + + + when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT + sequence is considerably faster than an EXPUNGE-LOGOUT or + EXPUNGE-SELECT because no untagged EXPUNGE responses (which the + client would probably ignore) are sent. + + Example: C: A341 CLOSE + S: A341 OK CLOSE completed + + +6.4.3. EXPUNGE Command + + Arguments: none + + Data: untagged responses: EXPUNGE + + Result: OK - expunge completed + NO - expunge failure: can't expunge (e.g. permission + denied) + BAD - command unknown or arguments invalid + + The EXPUNGE command permanently removes from the currently + selected mailbox all messages that have the \Deleted flag set. + Before returning an OK to the client, an untagged EXPUNGE response + is sent for each message that is removed. + + Example: C: A202 EXPUNGE + S: * 3 EXPUNGE + S: * 3 EXPUNGE + S: * 5 EXPUNGE + S: * 8 EXPUNGE + S: A202 OK EXPUNGE completed + + Note: in this example, messages 3, 4, 7, and 11 had the + \Deleted flag set. See the description of the EXPUNGE + response for further explanation. + + + + + + + + + + + + + + + + +Crispin [Page 25] + +RFC 1730 IMAP4 December 1994 + + +6.4.4. SEARCH Command + + Arguments: optional character set specification + searching criteria (one or more) + + Data: mandatory untagged response: SEARCH + + Result: OK - search completed + NO - search error: can't search that character set or + criteria + BAD - command unknown or arguments invalid + + The SEARCH command searches the mailbox for messages that match + the given searching criteria. Searching criteria consist of one + or more search keys. The untagged SEARCH response from the server + contains a listing of message sequence numbers corresponding to + those messages that match the searching criteria. + + When multiple keys are specified, the result is the intersection + (AND function) of all the messages that match those keys. For + example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers + to all deleted messages from Smith that were placed in the mailbox + since February 1, 1994. A search key may also be a parenthesized + list of one or more search keys (e.g. for use with the OR and NOT + keys). + + Server implementations MAY exclude [MIME-1] body parts with + terminal content types other than TEXT and MESSAGE from + consideration in SEARCH matching. + + The optional character set specification consists of the word + "CHARSET" followed by a registered MIME character set. It + indicates the character set of the strings that appear in the + search criteria. [MIME-2] strings that appear in RFC 822/MIME + message headers, and [MIME-1] content transfer encodings, MUST be + decoded before matching. Except for US-ASCII, it is not required + that any particular character set be supported. If the server + does not support the specified character set, it MUST return a + tagged NO response (not a BAD). + + In all search keys that use strings, a message matches the key if + the string is a substring of the field. The matching is + case-insensitive. + + + + + + + + +Crispin [Page 26] + +RFC 1730 IMAP4 December 1994 + + + The defined search keys are as follows. Refer to the Formal + Syntax section for the precise syntactic definitions of the + arguments. + + Messages with message sequence numbers + corresponding to the specified message sequence + number set + + ALL All messages in the mailbox; the default initial + key for ANDing. + + ANSWERED Messages with the \Answered flag set. + + BCC Messages that contain the specified string in the + envelope structure's BCC field. + + BEFORE Messages whose internal date is earlier than the + specified date. + + BODY Messages that contain the specified string in the + body of the message. + + CC Messages that contain the specified string in the + envelope structure's CC field. + + DELETED Messages with the \Deleted flag set. + + DRAFT Messages with the \Draft flag set. + + FLAGGED Messages with the \Flagged flag set. + + FROM Messages that contain the specified string in the + envelope structure's FROM field. + + HEADER + Messages that have a header with the specified + field-name (as defined in [RFC-822]) and that + contains the specified string in the [RFC-822] + field-body. + + KEYWORD Messages with the specified keyword set. + + LARGER Messages with an RFC822.SIZE larger than the + specified number of octets. + + NEW Messages that have the \Recent flag set but not the + \Seen flag. This is functionally equivalent to + "(RECENT UNSEEN)". + + + +Crispin [Page 27] + +RFC 1730 IMAP4 December 1994 + + + NOT + Messages that do not match the specified search + key. + + OLD Messages that do not have the \Recent flag set. + This is functionally equivalent to "NOT RECENT" (as + opposed to "NOT NEW"). + + ON Messages whose internal date is within the + specified date. + + OR + Messages that match either search key. + + RECENT Messages that have the \Recent flag set. + + SEEN Messages that have the \Seen flag set. + + SENTBEFORE + Messages whose [RFC-822] Date: header is earlier + than the specified date. + + SENTON Messages whose [RFC-822] Date: header is within the + specified date. + + SENTSINCE + Messages whose [RFC-822] Date: header is within or + later than the specified date. + + SINCE Messages whose internal date is within or later + than the specified date. + + SMALLER Messages with an RFC822.SIZE smaller than the + specified number of octets. + + SUBJECT + Messages that contain the specified string in the + envelope structure's SUBJECT field. + + TEXT Messages that contain the specified string in the + header or body of the message. + + TO Messages that contain the specified string in the + envelope structure's TO field. + + UID + Messages with unique identifiers corresponding to + the specified unique identifier set. + + + +Crispin [Page 28] + +RFC 1730 IMAP4 December 1994 + + + UNANSWERED Messages that do not have the \Answered flag set. + + UNDELETED Messages that do not have the \Deleted flag set. + + UNDRAFT Messages that do not have the \Draft flag set. + + UNFLAGGED Messages that do not have the \Flagged flag set. + + UNKEYWORD + Messages that do not have the specified keyword + set. + + UNSEEN Messages that do not have the \Seen flag set. + + + Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" + S: * SEARCH 2 84 882 + S: A282 OK SEARCH completed + + +6.4.5. FETCH Command + + Arguments: message set + message data item names + + Data: untagged responses: FETCH + + Result: OK - fetch completed + NO - fetch error: can't fetch that data + BAD - command unknown or arguments invalid + + The FETCH command retrieves data associated with a message in the + mailbox. The data items to be fetched may be either a single atom + or a parenthesized list. The currently defined data items that + can be fetched are: + + ALL Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE ENVELOPE) + + BODY Non-extensible form of BODYSTRUCTURE. + + BODY[
] + The text of a particular body section. The section + specification is a set of one or more part numbers + delimited by periods. + + Single-part messages only have a part 1. + + + + +Crispin [Page 29] + +RFC 1730 IMAP4 December 1994 + + + Multipart messages are assigned consecutive part + numbers, as they occur in the message. If a + particular part is of type message or multipart, + its parts must be indicated by a period followed by + the part number within that nested multipart part. + It is not permitted to fetch a multipart part + itself, only its individual members. + + A part of type MESSAGE and subtype RFC822 also has + nested parts. These are the parts of the MESSAGE + part's body. Nested part 0 of a part of type + MESSAGE and subtype RFC822 is the [RFC-822] header + of the message. + + Every message has at least one part. + + Here is an example of a complex message + with its associated section + specifications: + + 0 ([RFC-822] header of the message) + MULTIPART/MIXED + 1 TEXT/PLAIN + 2 APPLICATION/OCTET-STREAM + 3 MESSAGE/RFC822 + 3.0 ([RFC-822] header of the message) + 3.1 TEXT/PLAIN + 3.2 APPLICATION/OCTET-STREAM + MULTIPART/MIXED + 4.1 IMAGE/GIF + 4.2 MESSAGE/RFC822 + 4.2.0 ([RFC-822] header of the message) + 4.2.1 TEXT/PLAIN + MULTIPART/ALTERNATIVE + 4.2.2.1 TEXT/PLAIN + 4.2.2.2 TEXT/RICHTEXT + + Note that there is no section + specification for the Multi-part parts + (no section 4 or 4.2.2). + + The \Seen flag is implicitly set; if this causes + the flags to change they should be included as part + of the fetch responses. + + BODY.PEEK[
] + An alternate form of BODY[section] that does not + implicitly set the \Seen flag. + + + +Crispin [Page 30] + +RFC 1730 IMAP4 December 1994 + + + BODYSTRUCTURE The [MIME-1] body structure of the message. This + is computed by the server by parsing the [MIME-1] + header lines. + + ENVELOPE The envelope structure of the message. This is + computed by the server by parsing the [RFC-822] + header into the component parts, defaulting various + fields as necessary. + + FAST Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE) + + FLAGS The flags that are set for this message. + + FULL Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE ENVELOPE BODY) + + INTERNALDATE The date and time of final delivery of the message + as defined by RFC 821. + + RFC822 The message in [RFC-822] format. The \Seen flag is + implicitly set; if this causes the flags to change + they should be included as part of the fetch + responses. This is the concatenation of + RFC822.HEADER and RFC822.TEXT. + + RFC822.PEEK An alternate form of RFC822 that does not + implicitly set the \Seen flag. + + RFC822.HEADER The [RFC-822] format header of the message as + stored on the server including the delimiting blank + line between the header and the body. + + RFC822.HEADER.LINES + All header lines (including continuation lines) of + the [RFC-822] format header of the message with a + field-name (as defined in [RFC-822]) that matches + any of the strings in header_list. The matching is + case-insensitive but otherwise exact. The + delimiting blank line between the header and the + body is always included. + + + + + + + + + + +Crispin [Page 31] + +RFC 1730 IMAP4 December 1994 + + + RFC822.HEADER.LINES.NOT + All header lines (including continuation lines) of + the [RFC-822] format header of the message with a + field-name (as defined in [RFC-822]) that does not + match any of the strings in header_list. The + matching is case-insensitive but otherwise exact. + The delimiting blank line between the header and + the body is always included. + + RFC822.SIZE The number of octets in the message, as expressed + in [RFC-822] format. + + RFC822.TEXT The text body of the message, omitting the + [RFC-822] header. The \Seen flag is implicitly + set; if this causes the flags to change they should + be included as part of the fetch responses. + + RFC822.TEXT.PEEK + An alternate form of RFC822.TEXT that does not + implicitly set the \Seen flag. + + UID The unique identifier for the message. + + + Example: C: A654 FETCH 2:4 (FLAGS RFC822.HEADER.LINES (DATE FROM)) + S: * 2 FETCH .... + S: * 3 FETCH .... + S: * 4 FETCH .... + S: A003 OK FETCH completed + + +6.4.6. PARTIAL Command + + Arguments: message sequence number + message data item name + position of first octet + number of octets + + Data: untagged responses: FETCH + + Result: OK - partial completed + NO - partial error: can't fetch that data + BAD - command unknown or arguments invalid + + The PARTIAL command is equivalent to the associated FETCH command, + with the added functionality that only the specified number of + octets, beginning at the specified starting octet, are returned. + Only a single message can be fetched at a time. The first octet + + + +Crispin [Page 32] + +RFC 1730 IMAP4 December 1994 + + + of a message, and hence the minimum for the starting octet, is + octet 1. + + The following FETCH items are valid data for PARTIAL: RFC822, + RFC822.HEADER, RFC822.TEXT, BODY[section], as well as any .PEEK + forms of these. + + Any partial fetch that attempts to read beyond the end of the text + is truncated as appropriate. If the starting octet is beyond the + end of the text, an empty string is returned. + + The data are returned with the FETCH response. There is no + indication of the range of the partial data in this response. It + is not possible to stream multiple PARTIAL commands of the same + data item without processing and synchronizing at each step, since + streamed commands may be executed out of order. + + There is no requirement that partial fetches follow any sequence. + For example, if a partial fetch of octets 1 through 10000 breaks + in an awkward place for BASE64 decoding, it is permitted to + continue with a partial fetch of 9987 through 19987, etc. + + The handling of the \Seen flag is the same as in the associated + FETCH command. + + Example: C: A005 PARTIAL 4 RFC822 1 1024 + S: * 1 FETCH (RFC822 {1024} + S: Return-Path: + S: ... + S: ......... FLAGS (\Seen)) + S: A005 OK PARTIAL completed + + +6.4.7. STORE Command + + Arguments: message set + message data item name + value for message data item + + Data: untagged responses: FETCH + + Result: OK - store completed + NO - store error: can't store that data + BAD - command unknown or arguments invalid + + The STORE command alters data associated with a message in the + mailbox. Normally, STORE will return the updated value of the + data with an untagged FETCH response. A suffix of ".SILENT" in + + + +Crispin [Page 33] + +RFC 1730 IMAP4 December 1994 + + + the data item name prevents the untagged FETCH, and the server + should assume that the client has determined the updated value + itself or does not care about the updated value. + + The currently defined data items that can be stored are: + + FLAGS + Replace the flags for the message with the + argument. The new value of the flags are returned + as if a FETCH of those flags was done. + + FLAGS.SILENT + Equivalent to FLAGS, but without returning a new + value. + + +FLAGS + Add the argument to the flags for the message. The + new value of the flags are returned as if a FETCH + of those flags was done. + + +FLAGS.SILENT + Equivalent to +FLAGS, but without returning a new + value. + + -FLAGS + Remove the argument from the flags for the message. + The new value of the flags are returned as if a + FETCH of those flags was done. + + -FLAGS.SILENT + Equivalent to -FLAGS, but without returning a new + value. + + + Example: C: A003 STORE 2:4 +FLAGS (\Deleted) + S: * 2 FETCH FLAGS (\Deleted \Seen) + S: * 3 FETCH FLAGS (\Deleted) + S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen) + S: A003 OK STORE completed + + + + + + + + + + + + +Crispin [Page 34] + +RFC 1730 IMAP4 December 1994 + + +6.4.8. COPY Command + + Arguments: message set + mailbox name + + Data: no specific data for this command + + Result: OK - copy completed + NO - copy error: can't copy those messages or to that + name + BAD - command unknown or arguments invalid + + The COPY command copies the specified message(s) to the specified + destination mailbox. The flags and internal date of the + message(s) SHOULD be preserved in the copy. + + If the destination mailbox does not exist, a server SHOULD return + an error. It SHOULD NOT automatically create the mailbox. Unless + it is certain that the destination mailbox can not be created, the + server MUST send the response code "[TRYCREATE]" as the prefix of + the text of the tagged NO response. This gives a hint to the + client that it can attempt a CREATE command and retry the COPY if + the CREATE is successful. + + If the COPY command is unsuccessful for any reason, server + implementations MUST restore the destination mailbox to its state + before the COPY attempt. + + Example: C: A003 COPY 2:4 MEETING + S: A003 OK COPY completed + + +6.4.9. UID Command + + Arguments: command name + command arguments + + Data: untagged responses: FETCH, SEARCH + + Result: OK - UID command completed + NO - UID command error + BAD - command unknown or arguments invalid + + The UID command has two forms. In the first form, it takes as its + arguments a COPY, FETCH, or STORE command with arguments + appropriate for the associated command. However, the numbers in + the message set argument are unique identifiers instead of message + sequence numbers. + + + +Crispin [Page 35] + +RFC 1730 IMAP4 December 1994 + + + In the second form, the UID command takes a SEARCH command with + SEARCH command arguments. The interpretation of the arguments is + the same as with SEARCH; however, the numbers returned in a SEARCH + response for a UID SEARCH command are unique identifiers instead + of message sequence numbers. For example, the command UID SEARCH + 1:100 UID 443:557 returns the unique identifiers corresponding to + the intersection of the message sequence number set 1:100 and the + UID set 443:557. + + A unique identifier of a message is a number, and is guaranteed + not to refer to any other message in the mailbox. Unique + identifiers are assigned in a strictly ascending fashion for each + message added to the mailbox. Unlike message sequence numbers, + unique identifiers persist across sessions. This permits a client + to resynchronize its state from a previous session with the server + (e.g. disconnected or offline access clients); this is discussed + further in [IMAP-DISC]. + + Associated with every mailbox is a unique identifier validity + value, which is sent in an UIDVALIDITY response code in an OK + untagged response at message selection time. If unique + identifiers from an earlier session fail to persist to this + session, the unique identifier validity value MUST be greater than + in the earlier session. + + Note: An example of a good value to use for the unique + identifier validity value would be a 32-bit + representation of the creation date/time of the mailbox. + It is alright to use a constant such as 1, but only if + it guaranteed that unique identifers will never be + reused, even in the case of a mailbox being deleted and + a new mailbox by the same name created at some future + time. + + + Message set ranges are permitted; however, there is no guarantee + that unique identifiers be contiguous. A non-existent unique + identifier within a message set range is ignored without any error + message generated. + + The number after the "*" in an untagged FETCH response is always a + message sequence number, not a unique identifier, even for a UID + command response. However, server implementations MUST implicitly + include the UID message data item as part of any FETCH response + caused by a UID command, regardless of whether UID was specified + as a message data item to the FETCH. + + + + + +Crispin [Page 36] + +RFC 1730 IMAP4 December 1994 + + + Example: C: A003 UID FETCH 4827313:4828442 FLAGS + S: * 23 FETCH (FLAGS (\Seen) UID 4827313) + S: * 24 FETCH (FLAGS (\Seen) UID 4827943) + S: * 25 FETCH (FLAGS (\Seen) UID 4828442) + S: A999 UID FETCH completed + + + +6.5. Client Commands - Experimental/Expansion + + +6.5.1. X Command + + Arguments: implementation defined + + Data: implementation defined + + Result: OK - command completed + NO - failure + BAD - command unknown or arguments invalid + + Any command prefixed with an X is an experimental command. + Commands which are not part of this specification, or a standard + or standards-track revision of this specification, MUST use the X + prefix. + + Any added untagged responses issued by an experimental command + MUST also be prefixed with an X. Server implementations MUST NOT + send any such untagged responses, unless the client requested it + by issuing the associated experimental command. + + Example: C: a441 CAPABILITY + S: * CAPABILITY IMAP4 XPIG-LATIN + S: a441 OK CAPABILITY completed + C: A442 XPIG-LATIN + S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay + S: A442 OK XPIG-LATIN ompleted-cay + + + + + + + + + + + + + + +Crispin [Page 37] + +RFC 1730 IMAP4 December 1994 + + +7. Server Responses + + Server responses are in three forms: status responses, server data, + and command continuation request. + + Server response data, identified by "Data:" in the response + descriptions below, are described by function, not by syntax. The + precise syntax of server response data is described in the Formal + Syntax section. + + The client MUST be prepared to accept any response at all times. + + Status responses that are tagged indicate the completion result of a + client command, and have a tag matching the command. + + Some status responses, and all server data, are untagged. An + untagged response is indicated by the token "*" instead of a tag. + Untagged status responses indicate server greeting, or server status + that does not indicate the completion of a command. For historical + reasons, untagged server data responses are also called "unsolicited + data", although strictly speaking only unilateral server data is + truly "unsolicited". + + Certain server data MUST be recorded by the client when it is + received; this is noted in the description of that data. Such data + conveys critical information which affects the interpretation of all + subsequent commands and responses (e.g. updates reflecting the + creation or destruction of messags). + + Other server data SHOULD be recorded for later reference; if the + client does not need to record the data, or if recording the data has + no obvious purpose (e.g. a SEARCH response when no SEARCH command is + in progress), the data SHOULD be ignored. + + An example of unilateral untagged responses occurs when the IMAP + connection is in selected state. In selected state, the server + checks the mailbox for new messages as part of the execution of each + command. If new messages are found, the server sends untagged EXISTS + and RECENT responses reflecting the new size of the mailbox. Server + implementations that offer multiple simultaneous access to the same + mailbox should also send appropriate unilateral untagged FETCH and + EXPUNGE responses if another agent changes the state of any message + flags or expunges any messages. + + Command continuation request responses use the token "+" instead of a + tag. These responses are sent by the server to indicate acceptance + of an incomplete client command and readiness for the remainder of + the command. + + + +Crispin [Page 38] + +RFC 1730 IMAP4 December 1994 + + +7.1. Server Responses - Status Responses + + Status responses may include an optional response code. A response + code consists of data inside square brackets in the form of an atom, + possibly followed by a space and arguments. The response code + contains additional information or status codes for client software + beyond the OK/NO/BAD condition, and are defined when there is a + specific action that a client can take based upon the additional + information. + + The currently defined response codes are: + + ALERT The human-readable text contains a special alert + that MUST be presented to the user in a fashion + that calls the user's attention to the message. + + PARSE The human-readable text represents an error in + parsing the [RFC-822] or [MIME-1] headers of a + message in the mailbox. + + PERMANENTFLAGS Followed by a parenthesized list of flags, + indicates which of the known flags that the client + may change permanently. Any flags that are in the + FLAGS untagged response, but not the PERMANENTFLAGS + list, can not be set permanently. If the client + attempts to STORE a flag that is not in the + PERMANENTFLAGS list, the server will either reject + it with a NO reply or store the state for the + remainder of the current session only. The + PERMANENTFLAGS list may also include the special + flag \*, which indicates that it is possible to + create new keywords by attempting to store those + flags in the mailbox. + + READ-ONLY The mailbox is selected read-only, or its access + while selected has changed from read-write to + read-only. + + READ-WRITE The mailbox is selected read-write, or its access + while selected has changed from read-only to + read-write. + + TRYCREATE An APPEND or COPY attempt is failing because the + target mailbox does not exist (as opposed to some + other reason). This is a hint to the client that + the operation may succeed if the mailbox is first + created by the CREATE command. + + + + +Crispin [Page 39] + +RFC 1730 IMAP4 December 1994 + + + UIDVALIDITY Followed by a decimal number, indicates the unique + identifier validity value. See the description of + the UID command for more detail. + + UNSEEN Followed by a decimal number, indicates the number + of the first message without the \Seen flag set. + + Additional response codes defined by particular client or server + implementations should be prefixed with an "X" until they are + added to a revision of this protocol. Client implementations + should ignore response codes that they do not recognize. + + +7.1.1. OK Response + + Data: optional response code + human-readable text + + The OK response indicates an information message from the server. + When tagged, it indicates successful completion of the associated + command. The human-readable text may be presented to the user as + an information message. The untagged form indicates an + information-only message; the nature of the information may be + indicated by a response code. + + The untagged form is also used as one of three possible greetings + at session startup. It indicates that the session is not yet + authenticated and that a LOGIN command is needed. + + Example: S: * OK IMAP4 server ready + C: A001 LOGIN fred blurdybloop + S: * OK [ALERT] System shutdown in 10 minutes + S: A001 OK LOGIN Completed + + +7.1.2. NO Response + + Data: optional response code + human-readable text + + The NO response indicates an operational error message from the + server. When tagged, it indicates unsuccessful completion of the + associated command. The untagged form indicates a warning; the + command may still complete successfully. The human-readable text + describes the condition. + + + + + + +Crispin [Page 40] + +RFC 1730 IMAP4 December 1994 + + + Example: C: A222 COPY 1:2 owatagusiam + S: * NO Disk is 98% full, please delete unnecessary data + S: A222 OK COPY completed + C: A222 COPY 3:200 blurdybloop + S: * NO Disk is 98% full, please delete unnecessary data + S: * NO Disk is 99% full, please delete unnecessary data + S: A222 NO COPY failed: disk is full + + +7.1.3. BAD Response + + Data: optional response code + human-readable text + + The BAD response indicates an error message from the server. When + tagged, it reports a protocol-level error in the client's command; + the tag indicates the command that caused the error. The untagged + form indicates a protocol-level error for which the associated + command can not be determined; it may also indicate an internal + server failure. The human-readable text describes the condition. + + Example: C: ...very long command line... + S: * BAD Command line too long + C: ...empty line... + S: * BAD Empty command line + C: A443 EXPUNGE + S: * BAD Disk crash, attempting salvage to a new disk! + S: * OK Salvage successful, no data lost + S: A443 OK Expunge completed + + +7.1.4. PREAUTH Response + + Data: optional response code + human-readable text + + The PREAUTH response is always untagged, and is one of three + possible greetings at session startup. It indicates that the + session has already been authenticated by external means and thus + no LOGIN command is needed. + + Example: S: * PREAUTH IMAP4 server ready and logged in as Smith + + + + + + + + + +Crispin [Page 41] + +RFC 1730 IMAP4 December 1994 + + +7.1.5. BYE Response + + Data: optional response code + human-readable text + + The BYE response is always untagged, and indicates that the server + is about to close the connection. The human-readable text may be + displayed to the user in a status report by the client. The BYE + response may be sent as part of a normal logout sequence, or as a + panic shutdown announcement by the server. It is also used by + some server implementations as an announcement of an inactivity + autologout. + + This response is also used as one of three possible greetings at + session startup. It indicates that the server is not willing to + accept a session from this client. + + Example: S: * BYE Autologout; idle for too long + + + +7.2. Server Responses - Server and Mailbox Status + + These responses are always untagged. This is how server data are + transmitted from the server to the client, often as a result of a + command with the same name. + +7.2.1. CAPABILITY Response + + Data: capability listing + + The CAPABILITY response occurs as a result of a CAPABILITY + command. The capability listing contains a space-separated + listing of capability names that the server supports. The first + name in the capability listing MUST be the atom "IMAP4". + + A capability name other than IMAP4 indicates that the server + supports an extension, revision, or amendment to the IMAP4 + protocol. Server responses MUST conform to this document until + the client issues a command that uses the associated capability. + + Capability names MUST either begin with "X" or be standard or + standards-track IMAP4 extensions, revisions, or amendments + registered with IANA. A server MUST NOT offer unregistered or + non-standard capability names, unless such names are prefixed with + an "X". + + + + + +Crispin [Page 42] + +RFC 1730 IMAP4 December 1994 + + + Client implementations SHOULD NOT require any capability name + other than "IMAP4", and MUST ignore any unknown capability names. + + Example: S: * CAPABILITY IMAP4 XPIG-LATIN + + +7.2.2. LIST Response + + Data: name attributes + hierarchy delimiter + name + + The LIST response occurs as a result of a LIST command. It + returns a single name that matches the LIST specification. There + may be multiple LIST responses for a single LIST command. + + Four name attributes are defined: + + \Noinferiors It is not possible for any child levels of + hierarchy to exist under this name; no child levels + exist now and none can be created in the future. + + \Noselect It is not possible to use this name as a selectable + mailbox. + + \Marked The mailbox has been marked "interesting" by the + server; the mailbox probably contains messages that + have been added since the last time the mailbox was + selected. + + \Unmarked The mailbox does not contain any additional + messages since the last time the mailbox was + selected. + + If it is not feasible for the server to determine whether the + mailbox is "interesting" or not, or if the name is a \Noselect + name, the server should not send either \Marked or \Unmarked. + + The hierarchy delimiter is a character used to delimit levels of + hierarchy in a mailbox name. A client may use it to create child + mailboxes, and to search higher or lower levels of naming + hierarchy. All children of a top-level hierarchy node must use + the same separator character. A NIL hierarchy delimiter means + that no hierarchy exists; the name is a "flat" name. + + + + + + + +Crispin [Page 43] + +RFC 1730 IMAP4 December 1994 + + + The name represents an unambiguous left-to-right hierarchy, and + MUST be valid for use as a reference in LIST and LSUB commands. + Unless \Noselect is indicated, the name must also be valid as an + argument for commands, such as SELECT, that accept mailbox names. + + Example: S: * LIST (\Noselect) "/" ~/Mail/foo + + +7.2.3. LSUB Response + + Data: name attributes + hierarchy delimiter + name + + The LSUB response occurs as a result of an LSUB command. It + returns a single name that matches the LSUB specification. There + may be multiple LSUB responses for a single LSUB command. The + data is identical in format to the LIST response. + + Example: S: * LSUB () "." #news.comp.mail.misc + + +7.2.4. SEARCH Response + + Data: zero or more numbers + + The SEARCH response occurs as a result of a SEARCH or UID SEARCH + command. The number(s) refer to those messages that match the + search criteria. For SEARCH, these are message sequence numbers; + for UID SEARCH, these are unique identifiers. Each number is + delimited by a space. + + Example: S: * SEARCH 2 3 6 + + +7.2.5. FLAGS Response + + Data: flag parenthesized list + + The FLAGS response occurs as a result of a SELECT or EXAMINE + command. The flag parenthesized list identifies the flags (at a + minimum, the system-defined flags) that are applicable for this + mailbox. Flags other than the system flags may also exist, + depending on server implementation. + + The update from the FLAGS response MUST be recorded by the client. + + Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + + + +Crispin [Page 44] + +RFC 1730 IMAP4 December 1994 + + +7.3. Server Responses - Message Status + + These responses are always untagged. This is how message data are + transmitted from the server to the client, often as a result of a + command with the same name. Immediately following the "*" token is a + number that represents either a message sequence number or a message + count. + +7.3.1. EXISTS Response + + Data: none + + The EXISTS response reports the number of messages in the mailbox. + This response occurs as a result of a SELECT or EXAMINE command, + and if the size of the mailbox changes (e.g. new mail). + + The update from the EXISTS response MUST be recorded by the + client. + + Example: S: * 23 EXISTS + + +7.3.2. RECENT Response + + Data: none + + The RECENT response reports the number of messages that have + arrived since the previous time a SELECT command was done on this + mailbox. This response occurs as a result of a SELECT or EXAMINE + command, and if the size of the mailbox changes (e.g. new mail). + + The update from the RECENT response MUST be recorded by the + client. + + Example: S: * 5 RECENT + + +7.3.3. EXPUNGE Response + + Data: none + + The EXPUNGE response reports that the specified message sequence + number has been permanently removed from the mailbox. The message + sequence number for each successive message in the mailbox is + immediately decremented by 1, and this decrement is reflected in + message sequence numbers in subsequent responses (including other + untagged EXPUNGE responses). + + + + +Crispin [Page 45] + +RFC 1730 IMAP4 December 1994 + + + As a result of the immediate decrement rule, message sequence + numbers that appear in a set of successive EXPUNGE responses + depend upon whether the messages are removed starting from lower + numbers to higher numbers, or from higher numbers to lower + numbers. For example, if the last 5 messages in a 9-message + mailbox are expunged; a "lower to higher" server will send five + untagged EXPUNGE responses for message sequence number 5, whereas + a "higher to lower server" will send successive untagged EXPUNGE + responses for message sequence numbers 9, 8, 7, 6, and 5. + + An EXPUNGE response MUST NOT be sent when no command is in + progress; nor while responding to a FETCH, STORE, or SEARCH + command. This rule is necessary to prevent a loss of + synchronization of message sequence numbers between client and + server. + + The update from the EXPUNGE response MUST be recorded by the + client. + + Example: S: * 44 EXPUNGE + + +7.3.4. FETCH Response + + Data: message data + + The FETCH response returns data about a message to the client. + The data are pairs of data item names and their values in + parentheses. This response occurs as the result of a FETCH or + STORE command, as well as by unilateral server decision (e.g. flag + updates). + + The current data items are: + + BODY A form of BODYSTRUCTURE without extension data. + + BODY[section] A string expressing the body contents of the + specified section. The string should be + interpreted by the client according to the content + transfer encoding, body type, and subtype. + + 8-bit textual data is permitted if a character set + identifier is part of the body parameter + parenthesized list for this section. + + Non-textual data such as binary data must be + transfer encoded into a textual form such as BASE64 + prior to being sent to the client. To derive the + + + +Crispin [Page 46] + +RFC 1730 IMAP4 December 1994 + + + original binary data, the client must decode the + transfer encoded string. + + BODYSTRUCTURE A parenthesized list that describes the body + structure of a message. This is computed by the + server by parsing the [RFC-822] header and body + into the component parts, defaulting various fields + as necessary. + + Multiple parts are indicated by parenthesis + nesting. Instead of a body type as the first + element of the parenthesized list there is a nested + body. The second element of the parenthesized list + is the multipart subtype (mixed, digest, parallel, + alternative, etc.). + + Extension data follows the multipart subtype. + Extension data is never returned with the BODY + fetch, but may be returned with a BODYSTRUCTURE + fetch. Extension data, if present, must be in the + defined order. + + The extension data of a multipart body part are in + the following order: + + body parameter parenthesized list + A parenthesized list of attribute/value pairs + [e.g. (foo bar baz rag) where "bar" is the value + of "foo" and "rag" is the value of "baz"] as + defined in [MIME-1]. + + Any following extension data are not yet defined in + this version of the protocol. Such extension data + may consist of zero or more NILs, strings, numbers, + or potentially nested parenthesized lists of such + data. Client implementations that do a + BODYSTRUCTURE fetch MUST be prepared to accept such + extension data. Server implementations MUST NOT + send such extension data until it has been defined + by a revision of this protocol. + + The basic fields of a non-multipart body part are + in the following order: + + body type + A string giving the content type name as defined + in [MIME-1]. + + + + +Crispin [Page 47] + +RFC 1730 IMAP4 December 1994 + + + body subtype + A string giving the content subtype name as + defined in [MIME-1]. + + body parameter parenthesized list + A parenthesized list of attribute/value pairs + [e.g. (foo bar baz rag) where "bar" is the value + of "foo" and "rag" is the value of "baz"] as + defined in [MIME-1]. + + body id + A string giving the content id as defined in + [MIME-1]. + + body description + A string giving the content description as + defined in [MIME-1]. + + body encoding + A string giving the content transfer encoding as + defined in [MIME-1]. + + body size + A number giving the size of the body in octets. + Note that this size is the size in its transfer + encoding and not the resulting size after any + decoding. + + A body type of type MESSAGE and subtype RFC822 + contains, immediately after the basic fields, the + envelope structure, body structure, and size in + text lines of the encapsulated message. + + A body type of type TEXT contains, immediately + after the basic fields, the size of the body in + text lines. Note that this size is the size in its + transfer encoding and not the resulting size after + any decoding. + + Extension data follows the basic fields and the + type-specific fields listed above. Extension data + is never returned with the BODY fetch, but may be + returned with a BODYSTRUCTURE fetch. Extension + data, if present, must be in the defined order. + + The extension data of a non-multipart body part are + in the following order: + + + + +Crispin [Page 48] + +RFC 1730 IMAP4 December 1994 + + + body MD5 + A string giving the content MD5 value as defined + in [MIME-1]. + + Any following extension data are not yet defined in + this version of the protocol, and would be as + described above under multipart extension data. + + ENVELOPE A parenthesized list that describes the envelope + structure of a message. This is computed by the + server by parsing the [RFC-822] header into the + component parts, defaulting various fields as + necessary. + + The fields of the envelope structure are in the + following order: date, subject, from, sender, + reply-to, to, cc, bcc, in-reply-to, and message-id. + The date, subject, in-reply-to, and message-id + fields are strings. The from, sender, reply-to, + to, cc, and bcc fields are parenthesized lists of + address structures. + + An address structure is a parenthesized list that + describes an electronic mail address. The fields + of an address structure are in the following order: + personal name, [SMTP] at-domain-list (source + route), mailbox name, and host name. + + [RFC-822] group syntax is indicated by a special + form of address structure in which the host name + field is NIL. If the mailbox name field is also + NIL, this is an end of group marker (semi-colon in + RFC 822 syntax). If the mailbox name field is + non-NIL, this is a start of group marker, and the + mailbox name field holds the group name phrase. + + Any field of an envelope or address structure that + is not applicable is presented as NIL. Note that + the server must default the reply-to and sender + fields from the from field; a client is not + expected to know to do this. + + + + + + + + + + +Crispin [Page 49] + +RFC 1730 IMAP4 December 1994 + + + FLAGS A parenthesized list of flags that are set for this + message. This may include keywords as well as the + following system flags: + + \Seen Message has been read + + \Answered Message has been answered + + \Flagged Message is "flagged" for urgent/special + attention + + \Deleted Message is "deleted" for removal by + later EXPUNGE + + \Draft Message has not completed composition + (marked as a draft). + + as well as the following special flag, which may be + fetched but not stored: + + \Recent Message has arrived since the previous + time this mailbox was selected. + + INTERNALDATE A string containing the date and time of final + delivery of the message as defined by [SMTP]. + + RFC822 A string expressing the message in [RFC-822] + format. The header portion of the message must be + 7-bit. 8-bit characters are permitted only in the + non-header portion of the message only if there are + [MIME-1] data in the message that identify the + character set of the message. + + RFC822.HEADER A string expressing the [RFC-822] format header of + the message, including the delimiting blank line + between the header and the body. The entire string + must be 7-bit; 8-bit characters are not permitted + in headers. RFC822.HEADER is used to return data + for the RFC822.HEADER, RFC822.HEADER.LINES, and + RFC822.HEADER.LINES.NOT FETCH data items. Note + that a blank line is always included regardless of + header line restrictions. + + RFC822.SIZE A number expressing the number of octets in the + message in [RFC-822] format. + + + + + + +Crispin [Page 50] + +RFC 1730 IMAP4 December 1994 + + + RFC822.TEXT A string expressing the text body of the message, + omitting the [RFC-822] header. 8-bit characters + are permitted only if there are [MIME-1] data in + the message that identify the character set of the + message. + + UID A number expressing the unique identifier of the + message. + + + Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827) + + +7.3.5. Obsolete Responses + + In addition to the responses listed in here, client implementations + MUST accept and implement the obsolete responses described in + Appendix B. + + + +7.4. Server Responses - Command Continuation Request + + The command completion request response is indicated by a "+" token + instead of a tag. This form of response indicates that the server is + ready to accept the continuation of a command from the client. The + remainder of this response is a line of text. + + This response is used in the AUTHORIZATION command to transmit server + data to the client, and request additional client data. This + response is also used if an argument to any command is a literal. + + The client is not permitted to send the octets of the literal unless + the server indicates that it expects it. This permits the server to + process commands and reject errors on a line-by-line basis. The + remainder of the command, including the CRLF that terminates a + command, follows the octets of the literal. If there are any + additional command arguments the literal octets are followed by a + space and those arguments. + + Example: C: A001 LOGIN {11} + S: + Ready for additional command text + C: FRED FOOBAR {7} + S: + Ready for additional command text + C: fat man + S: A001 OK LOGIN completed + C: A044 BLURDYBLOOP {102856} + S: A044 BAD No such command as "BLURDYBLOOP" + + + +Crispin [Page 51] + +RFC 1730 IMAP4 December 1994 + + +8. Sample IMAP4 session + + The following is a transcript of an IMAP4 session. A long line in + this sample is broken for editorial clarity. + + S: * OK IMAP4 Service Ready + C: a001 login mrc secret + S: a001 OK LOGIN completed + C: a002 select inbox + S: * 18 EXISTS + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + S: * 2 RECENT + S: * OK [UNSEEN 17] Message 17 is the first unseen message + S: * OK [UIDVALIDITY 3857529045] UIDs valid + S: a002 OK [READ-WRITE] SELECT completed + C: a003 fetch 12 full + S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "14-Jul-1993 02:44:25 -0700" + RFC822.SIZE 4282 ENVELOPE ("Wed, 14 Jul 1993 02:23:25 -0700 (PDT)" + "IMAP4 WG mtg summary and minutes" + (("Terry Gray" NIL "gray" "cac.washington.edu")) + (("Terry Gray" NIL "gray" "cac.washington.edu")) + (("Terry Gray" NIL "gray" "cac.washington.edu")) + ((NIL NIL "imap" "cac.washington.edu")) + ((NIL NIL "minutes" "CNRI.Reston.VA.US") + ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL + "") + BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92)) + S: a003 OK FETCH completed + C: a004 fetch 12 rfc822.header + S: * 12 FETCH (RFC822.HEADER {346} + S: Date: Wed, 14 Jul 1993 02:23:25 -0700 (PDT) + S: From: Terry Gray + S: Subject: IMAP4 WG mtg summary and minutes + S: To: imap@cac.washington.edu + S: cc: minutes@CNRI.Reston.VA.US, John Klensin + S: Message-Id: + S: MIME-Version: 1.0 + S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII + S: + S: ) + S: a004 OK FETCH completed + C: a005 store 12 +flags \deleted + S: * 12 FETCH (FLAGS (\Seen \Deleted)) + S: a005 OK +FLAGS completed + C: a006 logout + S: * BYE IMAP4 server terminating connection + S: a006 OK LOGOUT completed + + + + +Crispin [Page 52] + +RFC 1730 IMAP4 December 1994 + + +9. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in [RFC-822] with one exception; the + delimiter used with the "#" construct is a single space (SPACE) and + not a comma. + + Except as noted otherwise, all alphabetic characters are + case-insensitive. The use of upper or lower case characters to + define token strings is for editorial clarity only. Implementations + MUST accept these strings in a case-insensitive fashion. + + Syntax marked as obsolete may be encountered with implementations + written for an earlier version of this protocol (e.g. IMAP2). New + implementations SHOULD accept obsolete syntax as input, but MUST NOT + otherwise use such syntax. + + address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox + SPACE addr_host ")" + + addr_adl ::= nstring + + addr_host ::= nstring + ;; NIL indicates [RFC-822] group syntax + + addr_mailbox ::= nstring + ;; NIL indicates end of [RFC-822] group; if + ;; non-NIL and addr_host is NIL, holds + ;; [RFC-822] group name + + addr_name ::= nstring + + alpha ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / + "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / + "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / + "Y" / "Z" / + "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / + "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / + "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / + "y" / "z" / + ;; Case-sensitive + + append ::= "APPEND" SPACE mailbox [SPACE flag_list] + [SPACE date_time] SPACE literal + + astring ::= atom / string + + + + + +Crispin [Page 53] + +RFC 1730 IMAP4 December 1994 + + + atom ::= 1*ATOM_CHAR + + ATOM_CHAR ::= + + atom_specials ::= "(" / ")" / "{" / SPACE / CTLs / list_wildcards / + quoted_specials + + authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64) + + auth_type ::= atom + + base64 ::= *(4base64_char) [base64_terminal] + + base64_char ::= alpha / digit / "+" / "/" + + base64_terminal ::= (2base64_char "==") / (3base64_char "=") + + body ::= "(" body_type_1part / body_type_mpart ")" + + body_extension ::= nstring / number / "(" 1#body_extension ")" + ;; Future expansion. Client implementations + ;; MUST accept body_extension fields. Server + ;; implementations MUST NOT generate + ;; body_extension fields except as defined by + ;; future standard or standards-track + ;; revisions of this specification. + + body_ext_1part ::= body_fld_md5 [SPACE 1#body_extension] + ;; MUST NOT be returned on non-extensible + ;; "BODY" fetch + + body_ext_mpart ::= body_fld_param [SPACE 1#body_extension]] + ;; MUST NOT be returned on non-extensible + ;; "BODY" fetch + + body_fields ::= body_fld_param SPACE body_fld_id SPACE + body_fld_desc SPACE body_fld_enc SPACE + body_fld_octets + + body_fld_desc ::= nstring + + body_fld_enc ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/ + "QUOTED-PRINTABLE") <">) / string + + body_fld_id ::= nstring + + body_fld_lines ::= number + + + + +Crispin [Page 54] + +RFC 1730 IMAP4 December 1994 + + + body_fld_md5 ::= nstring + + body_fld_octets ::= number + + body_fld_param ::= "(" 1#(string string) ")" / nil + + body_fld_subtyp ::= string + + body_type_1part ::= (body_type_basic / body_type_msg / body_type_text) + [SPACE body_ext_1part] + + body_type_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" / + "MESSAGE" / "VIDEO") <">) / string) SPACE + body_fld_subtyp SPACE body_fields + ;; MESSAGE subtype MUST NOT be "RFC822" + + body_type_mpart ::= 1*body SPACE body_fld_subtyp + [SPACE body_ext_mpart] + + body_type_msg ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> SPACE + body_fields SPACE envelope SPACE body SPACE + body_fld_lines + + body_type_text ::= <"> "TEXT" <"> SPACE body_fld_subtyp SPACE + body_fields SPACE body_fld_lines + + capability ::= atom + ;; Must begin with "X" or be registered with + ;; IANA as standard or standards-track + + capability_data ::= "CAPABILITY" SPACE "IMAP4" [SPACE 1#capability] + + CHAR ::= + + CHAR8 ::= + + command ::= tag SPACE (command_any / command_auth / + command_nonauth / command_select) CRLF + ;; Modal based on state + + command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command + ;; Valid in all states + + command_auth ::= append / create / delete / examine / find / list / + lsub / rename / select / subscribe / unsubscribe / + ;; Valid only in Authenticated or Selected state + + + + +Crispin [Page 55] + +RFC 1730 IMAP4 December 1994 + + + command_nonauth ::= login / authenticate + ;; Valid only when in Non-Authenticated state + + command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" / + copy / fetch / partial / store / uid / search + ;; Valid only when in Selected state + + continue_req ::= "+" SPACE (resp_text / base64) + + copy ::= "COPY" SPACE set SPACE mailbox + + CR ::= + + create ::= "CREATE" SPACE mailbox + ;; Use of INBOX gives a NO error + + CRLF ::= CR LF + + CTL ::= + + date ::= date_text / <"> date_text <"> + + date_day ::= 1*2digit + ;; Day of month + + date_day_fixed ::= (SPACE digit) / 2digit + ;; Fixed-format version of date_day + + date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / + "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" + + date_text ::= date_day "-" date_month "-" (date_year / + date_year_old) + + date_year ::= 4digit + + date_year_old ::= 2digit + ;; OBSOLETE, (year - 1900) + + date_time ::= <"> (date_time_new / date_time_old) <"> + + date_time_new ::= date_day_fixed "-" date_month "-" date_year + SPACE time SPACE zone + + date_time_old ::= date_day_fixed "-" date_month "-" date_year_old + SPACE time "-" zone_old + ;; OBSOLETE + + + +Crispin [Page 56] + +RFC 1730 IMAP4 December 1994 + + + delete ::= "DELETE" SPACE mailbox + ;; Use of INBOX gives a NO error + + digit ::= "0" / digit_nz + + digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / + "9" + + envelope ::= "(" env_date SPACE env_subject SPACE env_from + SPACE env_sender SPACE env_reply-to SPACE env_to + SPACE env_cc SPACE env_bcc SPACE env_in-reply-to + SPACE env_message-id ")" + + env_bcc ::= "(" 1*address ")" / nil + + env_cc ::= "(" 1*address ")" / nil + + env_date ::= nstring + + env_from ::= "(" 1*address ")" / nil + + env_in-reply-to ::= nstring + + env_message-id ::= nstring + + env_reply-to ::= "(" 1*address ")" / nil + + env_sender ::= "(" 1*address ")" / nil + + env_subject ::= nstring + + env_to ::= "(" 1*address ")" / nil + + examine ::= "EXAMINE" SPACE mailbox + + fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" / + "FAST" / fetch_att / "(" 1#fetch_att ")") + + fetch_att ::= "BODY" / "BODYSTRUCTURE" / + "BODY" [".PEEK"] "[" section "]" / "ENVELOPE" / + "FLAGS" / "INTERNALDATE" / "UID" / + "RFC822" (([".TEXT"] [".PEEK"]) / ".SIZE" / + (".HEADER" [".LINES" [".NOT"] SPACE header_list]) + + find ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE + list_mailbox + ;; OBSOLETE + + + + +Crispin [Page 57] + +RFC 1730 IMAP4 December 1994 + + + flag ::= "\Answered" / "\Flagged" / "\Deleted" / + "\Seen" / "\Draft" / flag_keyword / + flag_extension + + flag_extension ::= "\" atom + ;; Future expansion. Client implementations + ;; MUST accept flag_extension flags. Server + ;; implementations MUST NOT generate + ;; flag_extension flags except as defined by + ;; future standard or standards-track + ;; revisions of this specification. + + flag_keyword ::= atom + + flag_list ::= "(" #flag ")" + + greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF + + header_line ::= astring + + header_list ::= "(" 1#header_line ")" + + LF ::= + + list ::= "LIST" SPACE mailbox SPACE list_mailbox + + list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string + + list_wildcards ::= "%" / "*" + + literal ::= "{" number "}" CRLF *CHAR8 + ;; Number represents the number of CHAR8 octets + + login ::= "LOGIN" SPACE userid SPACE password + + lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox + + mailbox ::= "INBOX" / astring + ;; INBOX is case-insensitive; other names may be + ;; case-sensitive depending on implementation. + + mailbox_data ::= "FLAGS" SPACE flag_list / + "LIST" SPACE mailbox_list / + "LSUB" SPACE mailbox_list / + "MAILBOX" SPACE text / + "SEARCH" [SPACE 1#nz_number] / + number SPACE "EXISTS" / number SPACE "RECENT" + + + + +Crispin [Page 58] + +RFC 1730 IMAP4 December 1994 + + + mailbox_list ::= "(" #("\Marked" / "\Noinferiors" / + "\Noselect" / "\Unmarked" / flag_extension) ")" + SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox + + message_data ::= nz_number SPACE ("EXPUNGE" / + ("FETCH" SPACE msg_fetch) / msg_obsolete) + + msg_fetch ::= "(" 1#("BODY" SPACE body / + "BODYSTRUCTURE" SPACE body / + "BODY[" section "]" SPACE nstring / + "ENVELOPE" SPACE envelope / + "FLAGS" SPACE "(" #(flag / "\Recent") ")" / + "INTERNALDATE" SPACE date_time / + "RFC822" [".HEADER" / ".TEXT"] SPACE nstring / + "RFC822.SIZE" SPACE number / + "UID" SPACE uniqueid) ")" + + msg_obsolete ::= "COPY" / ("STORE" SPACE msg_fetch) + ;; OBSOLETE untagged data responses + + nil ::= "NIL" + + nstring ::= string / nil + + number ::= 1*digit + ;; Unsigned 32-bit integer + ;; (0 <= n < 4,294,967,296) + + nz_number ::= digit_nz *digit + ;; Non-zero unsigned 32-bit integer + ;; (0 < n < 4,294,967,296) + + partial ::= "PARTIAL" SPACE nz_number SPACE + ("BODY" [".PEEK"] "[" section "]" / + "RFC822" (([".TEXT"] [".PEEK"]) / ".HEADER") + SPACE number SPACE number + + password ::= astring + + quoted ::= <"> *QUOTED_CHAR <"> + + QUOTED_CHAR ::= / + "\" quoted_specials + + quoted_specials ::= <"> / "\" + + rename ::= "RENAME" SPACE mailbox SPACE mailbox + ;; Use of INBOX as a destination gives a NO error + + + +Crispin [Page 59] + +RFC 1730 IMAP4 December 1994 + + + response ::= *response_data response_done + + response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye / + mailbox_data / message_data / capability_data) + CRLF + + response_done ::= response_tagged / response_fatal + + response_fatal ::= "*" SPACE resp_cond_bye CRLF + + response_tagged ::= tag SPACE resp_cond_state CRLF + + resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text + ;; Authentication condition + + resp_cond_bye ::= "BYE" SPACE resp_text + ;; Server will disconnect condition + + resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text + ;; Status condition + + resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text) + + resp_text_code ::= "ALERT" / "PARSE" / + "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" / + "READ-ONLY" / "READ-WRITE" / "TRYCREATE" / + "UIDVALIDITY" SPACE nz_number / + "UNSEEN" SPACE nz_number / + atom [SPACE 1*] + + search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE] + search_criteria + ;; Character set must be registered with IANA + ;; as a MIME character set + + search_criteria ::= 1#search_key + + search_key ::= search_new / search_old + + search_new ::= "DRAFT" / + "HEADER" SPACE header_line SPACE astring / + "LARGER" SPACE number / "NOT" SPACE search_key / + "OR" SPACE search_key SPACE search_key / + "SENTBEFORE" SPACE date / "SENTON" SPACE date / + "SENTSINCE" SPACE date / "SMALLER" SPACE number / + "UID" SPACE set / "UNDRAFT" / set / + "(" search_criteria ")" + ;; New in IMAP4 + + + +Crispin [Page 60] + +RFC 1730 IMAP4 December 1994 + + + search_old ::= "ALL" / "ANSWERED" / "BCC" SPACE astring / + "BEFORE" SPACE date / "BODY" SPACE astring / + "CC" SPACE astring / "DELETED" / "FLAGGED" / + "FROM" SPACE astring / + "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" / + "ON" SPACE date / "RECENT" / "SEEN" / + "SINCE" SPACE date / "SUBJECT" SPACE astring / + "TEXT" SPACE astring / "TO" SPACE astring / + "UNANSWERED" / "UNDELETED" / "UNFLAGGED" / + "UNKEYWORD" SPACE flag_keyword / "UNSEEN" + ;; Defined in [IMAP2] + + section ::= "0" / nz_number ["." section] + + select ::= "SELECT" SPACE mailbox + + sequence_num ::= nz_number / "*" + ;; * is the largest number in use. For message + ;; sequence numbers, it is the number of messages + ;; in the mailbox. For unique identifiers, it is + ;; the unique identifier of the last message in + ;; the mailbox. + + set ::= sequence_num / (sequence_num ":" sequence_num) / + (set "," set) + ;; Identifies a set of messages. For message + ;; sequence numbers, these are consecutive + ;; numbers from 1 to the number of messages in + ;; the mailbox + ;; Comma delimits individual numbers, colon + ;; delimits between two numbers inclusive. + ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13, + ;; 14,15 for a mailbox with 15 messages. + + SPACE ::= + + store ::= "STORE" SPACE set SPACE store_att_flags + + store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE + (flag_list / #flag) + + string ::= quoted / literal + + subscribe ::= ("SUBSCRIBE" SPACE mailbox) / subscribe_obs + + subscribe_obs ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox + ;;OBSOLETE + + + + +Crispin [Page 61] + +RFC 1730 IMAP4 December 1994 + + + tag ::= 1* + + text ::= 1*TEXT_CHAR + + text_mime2 ::= "=?" "?" "?" + "?=" + ;; Syntax defined in [MIME-2] + + TEXT_CHAR ::= + + time ::= 2digit ":" 2digit ":" 2digit + ;; Hours minutes seconds + + uid ::= "UID" SPACE (copy / fetch / search / store) + ;; Unique identifiers used instead of message + ;; sequence numbers + + uniqueid ::= nz_number + ;; Strictly ascending + + unsubscribe ::= ("UNSUBSCRIBE" SPACE mailbox) / unsubscribe_obs + + unsubscribe_obs ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox + ;;OBSOLETE + + userid ::= astring + + x_command ::= "X" atom + + zone ::= ("+" / "-") 4digit + ;; Signed four-digit value of hhmm representing + ;; hours and minutes west of Greenwich (that is, + ;; (the amount that the given time differs from + ;; Universal Time). Subtracting the timezone + ;; from the given time will give the UT form. + ;; The Universal Time zone is "+0000". + + + + + + + + + + + + + + + +Crispin [Page 62] + +RFC 1730 IMAP4 December 1994 + + + zone_old ::= "UT" / "GMT" / "Z" / ;; +0000 + "AST" / "EDT" / ;; -0400 + "EST" / "CDT" / ;; -0500 + "CST" / "MDT" / ;; -0600 + "MST" / "PDT" / ;; -0700 + "PST" / "YDT" / ;; -0800 + "YST" / "HDT" / ;; -0900 + "HST" / "BDT" / ;; -1000 + "BST" / ;; -1100 + "A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6 + "G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12 + "N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6 + "T" / "U" / "V" / "W" / "X" / "Y" ;; -7 to -12 + ;; OBSOLETE + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin [Page 63] + +RFC 1730 IMAP4 December 1994 + + +10. Author's Note + + This document is a revision or rewrite of earlier documents, and + supercedes the protocol specification in those documents: IMAP4 + Internet drafts, the IMAP2bis Internet drafts, unpublished + IMAP2bis.TXT document, RFC 1176, and RFC 1064. + + +11. Security Considerations + + IMAP4 protocol transactions, including electronic mail data, are sent + in the clear over the network unless the optional privacy protection + is negotiated in the AUTHENTICATE command. + + A server error message for an AUTHENTICATE command which fails due to + invalid credentials should not detail why the credentials are + invalid. + + Use of the LOGIN command sends passwords in the clear. This can be + avoided by using the AUTHENTICATE command instead. + + A server error message for a failing LOGIN command should not specify + that the user name, as opposed to the password, is invalid. + + Additional security considerations are discussed in the section + discussing the AUTHENTICATE and LOGIN commands. + + +12. Author's Address + + Mark R. Crispin + Networks and Distributed Computing, JE-30 + University of Washington + Seattle, WA 98195 + + Phone: (206) 543-5762 + + EMail: MRC@CAC.Washington.EDU + + + + + + + + + + + + + +Crispin [Page 64] + +RFC 1730 IMAP4 December 1994 + + +Appendices + +A. Obsolete Commands + + The following commands are OBSOLETE. It is NOT required to support + any of these commands in new server implementations. These commands + are documented here for the benefit of implementors who may wish to + support them for compatibility with old client implementations. + + The section headings of these commands are intended to correspond + with where they would be located in the main document if they were + not obsoleted. + + +A.6.3.OBS.1. FIND ALL.MAILBOXES Command + + Arguments: mailbox name with possible wildcards + + Data: untagged responses: MAILBOX + + Result: OK - find completed + NO - find failure: can't list that name + BAD - command unknown or arguments invalid + + The FIND ALL.MAILBOXES command returns a subset of names from the + complete set of all names available to the user. It returns zero + or more untagged MAILBOX replies. The mailbox argument to FIND + ALL.MAILBOXES is similar to that for LIST with an empty reference, + except that the characters "%" and "?" match a single character. + + Example: C: A002 FIND ALL.MAILBOXES * + S: * MAILBOX blurdybloop + S: * MAILBOX INBOX + S: A002 OK FIND ALL.MAILBOXES completed + + +A.6.3.OBS.2. FIND MAILBOXES Command + + Arguments: mailbox name with possible wildcards + + Data: untagged responses: MAILBOX + + Result: OK - find completed + NO - find failure: can't list that name + BAD - command unknown or arguments invalid + + The FIND MAILBOXES command returns a subset of names from the set + of names that the user has declared as being "active" or + + + +Crispin [Page 65] + +RFC 1730 IMAP4 December 1994 + + + "subscribed". It returns zero or more untagged MAILBOX replies. + The mailbox argument to FIND MAILBOXES is similar to that for LSUB + with an empty reference, except that the characters "%" and "?" + match a single character. + + Example: C: A002 FIND MAILBOXES * + S: * MAILBOX blurdybloop + S: * MAILBOX INBOX + S: A002 OK FIND MAILBOXES completed + + +A.6.3.OBS.3. SUBSCRIBE MAILBOX Command + + Arguments: mailbox name + + Data: no specific data for this command + + Result: OK - subscribe completed + NO - subscribe failure: can't subscribe to that name + BAD - command unknown or arguments invalid + + The SUBSCRIBE MAILBOX command is identical in effect to the + SUBSCRIBE command. A server which implements this command must be + able to distinguish between a SUBSCRIBE MAILBOX command and a + SUBSCRIBE command with a mailbox name argument of "MAILBOX". + + Example: C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime + S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime + completed + C: A003 SUBSCRIBE MAILBOX + S: A003 OK SUBSCRIBE to MAILBOX completed + + +A.6.3.OBS.4. UNSUBSCRIBE MAILBOX Command + + Arguments: mailbox name + + Data: no specific data for this command + + Result: OK - unsubscribe completed + NO - unsubscribe failure: can't unsubscribe that name + BAD - command unknown or arguments invalid + + The UNSUBSCRIBE MAILBOX command is identical in effect to the + UNSUBSCRIBE command. A server which implements this command must + be able to distinguish between a UNSUBSCRIBE MAILBOX command and + an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX". + + + + +Crispin [Page 66] + +RFC 1730 IMAP4 December 1994 + + + Example: C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime + S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime + completed + C: A003 UNSUBSCRIBE MAILBOX + S: A003 OK UNSUBSCRIBE from MAILBOX completed + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin [Page 67] + +RFC 1730 IMAP4 December 1994 + + +B. Obsolete Responses + + The following responses are OBSOLETE. Except as noted below, these + responses MUST NOT be transmitted by new server implementations. + + The section headings of these responses are intended to correspond + with where they would be located in the main document if they were + not obsoleted. + + +B.7.2.OBS.1. MAILBOX Response + + Data: name + + The MAILBOX response MUST NOT be transmitted by server + implementations except in response to the obsolete FIND MAILBOXES + and FIND ALL.MAILBOXES commands. Client implementations that do + not use these commands MAY ignore this response. It is documented + here for the benefit of implementors who may wish to support it + for compatibility with old client implementations. + + This response occurs as a result of the FIND MAILBOXES and FIND + ALL.MAILBOXES commands. It returns a single name that matches the + FIND specification. There are no attributes or hierarchy + delimiter. + + Example: S: * MAILBOX blurdybloop + + +B.7.3.OBS.1. COPY Response + + Data: none + + The COPY response MUST NOT be transmitted by new server + implementations. Client implementations MUST ignore the COPY + response. It is documented here for the benefit of client + implementors who may encounter this response from old server + implementations. + + In some experimental versions of this protocol, this response was + returned in response to a COPY command to indicate on a + per-message basis that the message was copied successfully. + + Example: S: * 44 COPY + + + + + + + +Crispin [Page 68] + +RFC 1730 IMAP4 December 1994 + + +B.7.3.OBS.2. STORE Response + + Data: message data + + The STORE response MUST NOT be transmitted by new server + implementations. Client implementations MUST treat the STORE + response as equivalent to the FETCH response. It is documented + here for the benefit of client implementors who may encounter this + response from old server implementations. + + In some experimental versions of this protocol, this response was + returned instead of FETCH in response to a STORE command to report + the new value of the flags. + + Example: S: * 69 STORE (FLAGS (\Deleted)) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin [Page 69] + +RFC 1730 IMAP4 December 1994 + + +C. References + + + [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731. + Carnegie-Mellon University, December 1994. + + [IMAP-COMPAT] Crispin, M. "IMAP4 Compatibility with IMAP2 and + IMAP2bis", RFC 1732, University of Washington, December 1994. + + [IMAP-DISC] Austein, R. "Synchronization Operations for Disconnected + IMAP4 Clients", Work in Progress. + + [IMAP-MODEL] Crispin, M. "Distributed Electronic Mail Models in + IMAP4", RFC 1733, University of Washington, December 1994. + + [IMAP-NAMING] Crispin, M. "Mailbox Naming Convention in IMAP4", Work + in Progress. + + [IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", + RFC 1176, University of Washington, August 1990. + + [IMSP] Myers, J. "IMSP -- Internet Message Support Protocol", Work in + Progress. + + [MIME-1] Borenstein, N., and Freed, N., "MIME (Multipurpose Internet + Mail Extensions) Part One: Mechanisms for Specifying and Describing + the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, + September 1993. + + [MIME-2] Moore, K., "MIME (Multipurpose Internet Mail Extensions) + Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522, + University of Tennessee, September 1993. + + [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, University of Delaware, August 1982. + + [SMTP] Postel, Jonathan B. "Simple Mail Transfer Protocol", STD 10, + RFC 821, USC/Information Sciences Institute, August 1982. + + + + + + + + + + + + + +Crispin [Page 70] + +RFC 1730 IMAP4 December 1994 + + +E. IMAP4 Keyword Index + + + +FLAGS (store command data item) ............... 34 + +FLAGS.SILENT (store command data item) ........ 34 + -FLAGS (store command data item) ............... 34 + -FLAGS.SILENT (store command data item) ........ 34 + ALERT (response code) ...................................... 39 + ALL (fetch item) ........................................... 29 + ALL (search key) ........................................... 27 + ANSWERED (search key) ...................................... 27 + APPEND (command) ........................................... 22 + AUTHENTICATE (command) ..................................... 12 + BAD (response) ............................................. 41 + BCC (search key) .................................. 27 + BEFORE (search key) ................................. 27 + BODY (fetch item) .......................................... 29 + BODY (fetch result) ........................................ 46 + BODY (search key) ................................. 27 + BODY.PEEK[
] (fetch item) .......................... 30 + BODYSTRUCTURE (fetch item) ................................. 31 + BODYSTRUCTURE (fetch result) ............................... 47 + BODY[
] (fetch item) ............................... 29 + BODY[section] (fetch result) ............................... 46 + BYE (response) ............................................. 41 + CAPABILITY (command) ....................................... 10 + CAPABILITY (response) ...................................... 42 + CC (search key) ................................... 27 + CHECK (command) ............................................ 23 + CLOSE (command) ............................................ 24 + COPY (command) ............................................. 34 + COPY (response) ............................................ 68 + CREATE (command) ........................................... 17 + DELETE (command) ........................................... 18 + DELETED (search key) ....................................... 27 + DRAFT (search key) ......................................... 27 + ENVELOPE (fetch item) ...................................... 31 + ENVELOPE (fetch result) .................................... 49 + EXAMINE (command) .......................................... 16 + EXISTS (response) .......................................... 45 + EXPUNGE (command) .......................................... 25 + EXPUNGE (response) ......................................... 45 + FAST (fetch item) .......................................... 31 + FETCH (command) ............................................ 29 + FETCH (response) ........................................... 46 + FIND ALL.MAILBOXES (command) ............................... 65 + FIND MAILBOXES (command) ................................... 65 + FLAGGED (search key) ....................................... 27 + FLAGS (fetch item) ......................................... 31 + + + +Crispin [Page 71] + +RFC 1730 IMAP4 December 1994 + + + + FLAGS (fetch result) ....................................... 50 + FLAGS (response) ........................................... 44 + FLAGS (store command data item) ................ 34 + FLAGS.SILENT (store command data item) ......... 34 + FROM (search key) ................................. 27 + FULL (fetch item) .......................................... 31 + HEADER (search key) .................. 27 + INTERNALDATE (fetch item) .................................. 31 + INTERNALDATE (fetch result) ................................ 50 + KEYWORD (search key) ................................ 27 + LARGER (search key) .................................... 27 + LIST (command) ............................................. 20 + LIST (response) ............................................ 43 + LOGIN (command) ............................................ 14 + LOGOUT (command) ........................................... 11 + LSUB (command) ............................................. 22 + LSUB (response) ............................................ 44 + MAILBOX (response) ......................................... 68 + NEW (search key) ........................................... 27 + NO (response) .............................................. 40 + NOOP (command) ............................................. 11 + NOT (search key) .............................. 28 + OK (response) .............................................. 40 + OLD (search key) ........................................... 28 + ON (search key) ..................................... 28 + OR (search key) ................ 28 + PARSE (response code) ...................................... 39 + PARTIAL (command) .......................................... 32 + PERMANENTFLAGS (response code) ............................. 39 + PREAUTH (response) ......................................... 41 + READ-ONLY (response code) .................................. 39 + READ-WRITE (response code) ................................. 39 + RECENT (response) .......................................... 45 + RECENT (search key) ........................................ 28 + RENAME (command) ........................................... 18 + RFC822 (fetch item) ........................................ 31 + RFC822 (fetch result) ...................................... 50 + RFC822.HEADER (fetch item) ................................. 31 + RFC822.HEADER (fetch result) ............................... 50 + RFC822.HEADER.LINES (fetch item) ............. 31 + RFC822.HEADER.LINES.NOT (fetch item) ......... 32 + RFC822.PEEK (fetch item) ................................... 31 + RFC822.SIZE (fetch item) ................................... 32 + RFC822.SIZE (fetch result) ................................. 50 + RFC822.TEXT (fetch item) ................................... 32 + RFC822.TEXT (fetch result) ................................. 51 + RFC822.TEXT.PEEK (fetch item) .............................. 32 + SEARCH (command) ........................................... 25 + + + +Crispin [Page 72] + +RFC 1730 IMAP4 December 1994 + + + + SEARCH (response) .......................................... 44 + SEEN (search key) .......................................... 28 + SELECT (command) ........................................... 15 + SENTBEFORE (search key) ............................. 28 + SENTON (search key) ................................. 28 + SENTSINCE (search key) .............................. 28 + SINCE (search key) .................................. 28 + SMALLER (search key) ................................... 28 + STORE (command) ............................................ 33 + STORE (response) ........................................... 69 + SUBJECT (search key) .............................. 28 + SUBSCRIBE (command) ........................................ 19 + SUBSCRIBE MAILBOX (command) ................................ 66 + TEXT (search key) ................................. 28 + TO (search key) ................................... 28 + TRYCREATE (response code) .................................. 39 + UID (command) .............................................. 35 + UID (fetch item) ........................................... 32 + UID (fetch result) ......................................... 51 + UID (search key) ............................. 28 + UIDVALIDITY (response code) ................................ 40 + UNANSWERED (search key) .................................... 29 + UNDELETED (search key) ..................................... 29 + UNDRAFT (search key) ....................................... 29 + UNFLAGGED (search key) ..................................... 29 + UNKEYWORD (search key) .............................. 29 + UNSEEN (response code) ..................................... 40 + UNSEEN (search key) ........................................ 29 + UNSUBSCRIBE (command) ...................................... 19 + UNSUBSCRIBE MAILBOX (command) .............................. 66 + X (command) .......................................... 37 + \Answered (system flag) .................................... 50 + \Deleted (system flag) ..................................... 50 + \Draft (system flag) ....................................... 50 + \Flagged (system flag) ..................................... 50 + \Marked (mailbox name attribute) ........................... 43 + \Noinferiors (mailbox name attribute) ...................... 43 + \Noselect (mailbox name attribute) ......................... 43 + \Recent (system flag) ...................................... 50 + \Seen (system flag) ........................................ 50 + \Unmarked (mailbox name attribute) ......................... 43 + + + + + + + + + + +Crispin [Page 73] + diff --git a/RFC/rfc1731.txt b/RFC/rfc1731.txt new file mode 100644 index 00000000..42215dec --- /dev/null +++ b/RFC/rfc1731.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group J. Myers +Request for Comments: 1731 Carnegie Mellon +Category: Standards Track December 1994 + + + IMAP4 Authentication Mechanisms + +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. Introduction + + The Internet Message Access Protocol, Version 4 [IMAP4] contains the + AUTHENTICATE command, for identifying and authenticating a user to an + IMAP4 server and for optionally negotiating a protection mechanism + for subsequent protocol interactions. This document describes + several authentication mechanisms for use by the IMAP4 AUTHENTICATE + command. + + +2. Kerberos version 4 authentication mechanism + + The authentication type associated with Kerberos version 4 is + "KERBEROS_V4". + + The data encoded in the first ready response contains a random 32-bit + number in network byte order. The client should respond with a + Kerberos ticket and an authenticator for the principal + "imap.hostname@realm", where "hostname" is the first component of the + host name of the server with all letters in lower case and where + "realm" is the Kerberos realm of the server. The encrypted checksum + field included within the Kerberos authenticator should contain the + server provided 32-bit number in network byte order. + + Upon decrypting and verifying the ticket and authenticator, the + server should verify that the contained checksum field equals the + original server provided random 32-bit number. Should the + verification be successful, the server must add one to the checksum + and construct 8 octets of data, with the first four octets containing + the incremented checksum in network byte order, the fifth octet + containing a bit-mask specifying the protection mechanisms supported + by the server, and the sixth through eighth octets containing, in + + + +Myers [Page 1] + +RFC 1731 IMAP4 Authentication Mechanisms December 1994 + + + network byte order, the maximum cipher-text buffer size the server is + able to receive. The server must encrypt the 8 octets of data in the + session key and issue that encrypted data in a second ready response. + The client should consider the server authenticated if the first four + octets the un-encrypted data is equal to one plus the checksum it + previously sent. + + The client must construct data with the first four octets containing + the original server-issued checksum in network byte order, the fifth + octet containing the bit-mask specifying the selected protection + mechanism, the sixth through eighth octets containing in network byte + order the maximum cipher-text buffer size the client is able to + receive, and the following octets containing a user name string. The + client must then append from one to eight octets so that the length + of the data is a multiple of eight octets. The client must then PCBC + encrypt the data with the session key and respond to the second ready + response with the encrypted data. The server decrypts the data and + verifies the contained checksum. The username field identifies the + user for whom subsequent IMAP operations are to be performed; the + server must verify that the principal identified in the Kerberos + ticket is authorized to connect as that user. After these + verifications, the authentication process is complete. + + The protection mechanisms and their corresponding bit-masks are as + follows: + + 1 No protection mechanism + 2 Integrity (krb_mk_safe) protection + 4 Privacy (krb_mk_priv) protection + + + EXAMPLE: The following are two Kerberos version 4 login scenarios + (note that the line breaks in the sample authenticators are for + editorial clarity and are not in real authenticators) + + S: * OK IMAP4 Server + C: A001 AUTHENTICATE KERBEROS_V4 + S: + AmFYig== + C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT + +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd + WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh + S: + or//EoAADZI= + C: DiAF5A4gA+oOIALuBkAAmw== + S: A001 OK Kerberos V4 authentication successful + + + + + + + +Myers [Page 2] + +RFC 1731 IMAP4 Authentication Mechanisms December 1994 + + + S: * OK IMAP4 Server + C: A001 AUTHENTICATE KERBEROS_V4 + S: + gcfgCA== + C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT + +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd + WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh + S: A001 NO Kerberos V4 authentication failed + + +3. GSSAPI authentication mechanism + + The authentication type associated with all mechanisms employing the + GSSAPI [RFC1508] is "GSSAPI". + + The first ready response issued by the server contains no data. The + client should call GSS_Init_sec_context, passing in 0 for + input_context_handle (initially) and a targ_name equal to output_name + from GSS_Import_Name called with input_name_type of NULL and + input_name_string of "SERVICE:imap@hostname" where "hostname" is the + fully qualified host name of the server with all letters in lower + case. The client must then respond with the resulting output_token. + If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, then the client + should expect the server to issue a token in a subsequent ready + response. The client must pass the token to another call to + GSS_Init_sec_context. + + If GSS_Init_sec_context returns GSS_COMPLETE, then the client should + respond with any resulting output_token. If there is no + output_token, the client should respond with no data. The client + should then expect the server to issue a token in a subsequent ready + response. The client should pass this token to GSS_Unseal and + interpret the first octet of resulting cleartext as a bit-mask + specifying the protection mechanisms supported by the server and the + second through fourth octets as the maximum size output_message to + send to the server. The client should construct data, with the first + octet containing the bit-mask specifying the selected protection + mechanism, the second through fourth octets containing in network + byte order the maximum size output_message the client is able to + receive, and the remaining octets containing a user name string. The + client must pass the data to GSS_Seal with conf_flag set to FALSE, + and respond with the generated output_message. The client can then + consider the server authenticated. + + The server must issue a ready response with no data and pass the + resulting client supplied token to GSS_Accept_sec_context as + input_token, setting acceptor_cred_handle to NULL (for "use default + credentials"), and 0 for input_context_handle (initially). If + GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server should + + + +Myers [Page 3] + +RFC 1731 IMAP4 Authentication Mechanisms December 1994 + + + return the generated output_token to the client in a ready response + and pass the resulting client supplied token to another call to + GSS_Accept_sec_context. + + If GSS_Accept_sec_context returns GSS_COMPLETE, then if an + output_token is returned, the server should return it to the client + in a ready response and expect a reply from the client with no data. + Whether or not an output_token was returned, the server then should + then construct 4 octets of data, with the first octet containing a + bit-mask specifying the protection mechanisms supported by the server + and the second through fourth octets containing in network byte order + the maximum size output_token the server is able to receive. The + server must then pass the plaintext to GSS_Seal with conf_flag set to + FALSE and issue the generated output_message to the client in a ready + response. The server must then pass the resulting client supplied + token to GSS_Unseal and interpret the first octet of resulting + cleartext as the bit-mask for the selected protection mechanism, the + second through fourth octets as the maximum size output_message to + send to the client, and the remaining octets as the user name. Upon + verifying the src_name is authorized to authenticate as the user + name, The server should then consider the client authenticated. + + The protection mechanisms and their corresponding bit-masks are as + follows: + + 1 No protection mechanism + 2 Integrity protection. + Sender calls GSS_Seal with conf_flag set to FALSE + 4 Privacy protection. + Sender calls GSS_Seal with conf_flag set to TRUE + + +4. S/Key authentication mechanism + + The authentication type associated with S/Key [SKEY] is "SKEY". + + The first ready response issued by the server contains no data. The + client responds with the user name string. + + The data encoded in the second ready response contains the decimal + sequence number followed by a single space and the seed string for + the indicated user. The client responds with the one-time-password, + as either a 64-bit value in network byte order or encoded in the "six + English words" format. + + Upon successful verification of the one-time-password, the server + should consider the client authenticated. + + + + +Myers [Page 4] + +RFC 1731 IMAP4 Authentication Mechanisms December 1994 + + + S/Key authentication does not provide for any protection mechanisms. + + + EXAMPLE: The following are two S/Key login scenarios. + + S: * OK IMAP4 Server + C: A001 AUTHENTICATE SKEY + S: + + C: bW9yZ2Fu + S: + OTUgUWE1ODMwOA== + C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== + S: A001 OK S/Key authentication successful + + + S: * OK IMAP4 Server + C: A001 AUTHENTICATE SKEY + S: + + C: c21pdGg= + S: + OTUgUWE1ODMwOA== + C: BsAY3g4gBNo= + S: A001 NO S/Key authentication failed + + +5. References + + [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", + RFC 1730, University of Washington, December 1994. + + [RFC1508] Linn, J., "Generic Security Service Application Program + Interface", RFC 1508, Geer Zolot Associates, September 1993. + + [SKEY] Haller, Neil M. "The S/Key One-Time Password System", + Bellcore, Morristown, New Jersey, October 1993, + thumper.bellcore.com:pub/nmh/docs/ISOC.symp.ps + + + + + + + + + + + + + + + + + +Myers [Page 5] + +RFC 1731 IMAP4 Authentication Mechanisms December 1994 + + +6. Security Considerations + + Security issues are discussed throughout this memo. + + +7. Author's Address + + John G. Myers + Carnegie-Mellon University + 5000 Forbes Ave. + Pittsburgh PA, 15213-3890 + + EMail: jgm+@cmu.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Myers [Page 6] + diff --git a/RFC/rfc1732.txt b/RFC/rfc1732.txt new file mode 100644 index 00000000..cfae89c0 --- /dev/null +++ b/RFC/rfc1732.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group M. Crispin +Request for Comments: 1732 University of Washington +Category: Informational December 1994 + + + IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS + + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Introduction + + This is a summary of hints and recommendations to enable an IMAP4 + implementation to interoperate with implementations that conform to + earlier specifications. None of these hints and recommendations are + required by the IMAP4 specification; implementors must decide for + themselves whether they want their implementation to fail if it + encounters old software. + + IMAP4 has been designed to be upwards compatible with earlier + specifications. For the most part, IMAP4 facilities that were not in + earlier specifications should be invisible to clients unless the + client asks for the facility. + + In some cases, older servers may support some of the capabilities + listed as being "new in IMAP4" as experimental extensions to the + IMAP2 protocol described in RFC 1176. + + This information may not be complete; it reflects current knowledge + of server and client implementations as well as "folklore" acquired + in the evolution of the protocol. + + + + + + + + + + + + + + + + +Crispin [Page 1] + +RFC 1732 IMAP4 - Compatibility December 1994 + + +IMAP4 client interoperability with old servers + + In general, a client should be able to discover whether an IMAP2 + server supports a facility by trial-and-error; if an attempt to use a + facility generates a BAD response, the client can assume that the + server does not support the facility. + + A quick way to check whether a server implementation supports the + IMAP4 specification is to try the CAPABILITY command. An OK response + that includes the IMAP4 capability value indicates a server that + supports IMAP4; a BAD response or one without the IMAP4 capability + value indicates an older server. + + The following is a list of facilities that are only in IMAP4, and + suggestions for how new clients might interoperate with old servers: + + CAPABILITY command + A BAD response to this command indicates that the server + implements IMAP2 (or IMAP2bis) and not IMAP4. + + AUTHENTICATE command. + Use the LOGIN command. + + LSUB and LIST commands + Try the RFC 1176 FIND command. + + * in a sequence + Use the number of messages in the mailbox from the EXISTS + unsolicited response. + + SEARCH extensions (character set, additional criteria) + Reformulate the search request using only the searching + options listed in search_old in the IMAP4 grammar. This may + entail doing multiple searches to achieve the desired + results. + + BODYSTRUCTURE fetch data item + Try to fetch the non-extensible BODY data item. + + body section number 0 + Fetch the entire message and extract the header. + + RFC822.HEADER.LINES and RFC822.HEADER.LINES.NOT fetch data items + Use RFC822.HEADER and remove the unwanted information. + + BODY.PEEK[section], RFC822.PEEK, and RFC822.TEXT.PEEK fetch data + items Use the corresponding non-PEEK versions and manually + clear the \Seen flag as necessary. + + + +Crispin [Page 2] + +RFC 1732 IMAP4 - Compatibility December 1994 + + + UID fetch data item and the UID commands + No equivalent capabilitity exists in older servers. + + FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items + Use the corresponding non-SILENT versions and ignore the + untagged FETCH responses which com eback. + + + The following IMAP4 facilities were introduced in the experimental + IMAP2bis revisions to RFC-1176, and may be present in a server that + does not support the CAPABILITY command: + + CREATE, DELETE, and RENAME commands + To test whether these commands are present, try a CREATE + INBOX command. If the response is NO, these commands are + supported by the server. If the response is BAD, they are + not. Older servers without the CREATE capability may sup- + port implicit creation of a mailbox by a COPY command with a + non-existant name as the destination. + + APPEND command + To test whether this command is present, try to append a + zero-length stream to a mailbox name that is known not to + exist (or at least, highly unlikely to exist) on the remote + system. + + SUBSCRIBE and UNSUBSCRIBE commands + Try the form of these commands with the optional MAILBOX + keyword. + + EXAMINE command + Use the SELECT command instead. + + flags and internal date argument to APPEND command + Try the APPEND without any flag list and internal date argu- + ments. + + BODY, BODY[section], and FULL fetch data items + Use RFC822.TEXT and ALL instead. Server does not support + MIME. + + PARTIAL command + Use the appropriate FETCH command and ignore the unwanted + data. + + + IMAP4 client implementations must accept all responses and data for- + mats documented in the IMAP4 specification, including those labeled + + + +Crispin [Page 3] + +RFC 1732 IMAP4 - Compatibility December 1994 + + + as obsolete. This includes the COPY and STORE unsolicited responses + and the old format of dates and times. In particular, client imple- + mentations must not treat a date/time as a fixed format string; nor + may they assume that the time begins at a particular octet. + + IMAP4 client implementations must not depend upon the presence of any + server extensions that are not in the base IMAP4 specification. + + The experimental IMAP2bis version specified that the TRYCREATE spe- + cial information token is sent as a separate unsolicited OK response + instead of inside the NO response. + + The FIND BBOARDS, FIND ALL.BBOARDS, and BBOARD commands of RFC 1176 + are removed from IMAP4. There is no equivalent to the bboard com- + mands, which provided a separate namespace with implicit restrictions + on what may be done in that namespace. + + Older server implementations may automatically create the destination + mailbox on COPY if that mailbox does not already exist. This was how + a new mailbox was created in older specifications. If the server + does not support the CREATE command (see above for how to test for + this), it will probably create a mailbox on COPY. + + Older server implementations may not preserve flags or internal dates + on COPY. Some server implementations may not permit the preservation + of certain flags on COPY or their setting with APPEND as site policy. + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin [Page 4] + +RFC 1732 IMAP4 - Compatibility December 1994 + + +IMAP4 server interoperability with old clients + + In general, there should be no interoperation problem between a + server conforming to the IMAP4 specification and a well-written + client that conforms to an earlier specification. Known problems are + noted below: + + Poor wording in the description of the CHECK command in earlier + specifications implied that a CHECK command is the way to get the + current number of messages in the mailbox. This is incorrect. A + CHECK command does not necessarily result in an EXISTS response. + Clients must remember the most recent EXISTS value sent from the + server, and should not generate unnecessary CHECK commands. + + An incompatibility exists with COPY in IMAP4. COPY in IMAP4 + servers does not automatically create the destination mailbox if + that mailbox does not already exist. This may cause problems with + old clients that expect automatic mailbox creation in COPY. + + The PREAUTH unsolicited response is new in IMAP4. It is highly + unlikely that an old client would ever see this response. + + The format of dates and times has changed due to the impending end + of the century. Clients that fail to accept a four-digit year or + a signed four-digit timezone value will not work properly with + IMAP4. + + An incompatibility exists with the use of "\" in quoted strings. + This is best avoided by using literals instead of quoted strings + if "\" or <"> is embedded in the string. + +Security Considerations + + Security issues are not discussed in this memo. + +Author's Address: + + Mark R. Crispin + Networks and Distributed Computing, JE-30 + University of Washington + Seattle, WA 98195 + + Phone: (206) 543-5762 + + EMail: MRC@CAC.Washington.EDU + + + + + + +Crispin [Page 5] + diff --git a/RFC/rfc1734.txt b/RFC/rfc1734.txt new file mode 100644 index 00000000..f37f29e0 --- /dev/null +++ b/RFC/rfc1734.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group J. Myers +Request for Comments: 1734 Carnegie Mellon +Category: Standards Track December 1994 + + + POP3 AUTHentication command + +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. Introduction + + This document describes the optional AUTH command, for indicating an + authentication mechanism to the server, performing an authentication + protocol exchange, and optionally negotiating a protection mechanism + for subsequent protocol interactions. The authentication and + protection mechanisms used by the POP3 AUTH command are those used by + IMAP4. + + +2. The AUTH command + + AUTH mechanism + + Arguments: + a string identifying an IMAP4 authentication mechanism, + such as defined by [IMAP4-AUTH]. Any use of the string + "imap" used in a server authentication identity in the + definition of an authentication mechanism is replaced with + the string "pop". + + Restrictions: + may only be given in the AUTHORIZATION state + + Discussion: + The AUTH command indicates an authentication mechanism to + the server. If the server supports the requested + authentication mechanism, it performs an authentication + protocol exchange to authenticate and identify the user. + Optionally, it also negotiates a protection mechanism for + subsequent protocol interactions. If the requested + authentication mechanism is not supported, the server + + + +Myers [Page 1] + +RFC 1734 POP3 AUTH December 1994 + + + should reject the AUTH command by sending a negative + response. + + The authentication protocol exchange consists of a series + of server challenges and client answers that are specific + to the authentication mechanism. A server challenge, + otherwise known as a ready response, is a line consisting + of a "+" character followed by a single space and a BASE64 + encoded string. The client answer consists of a line + containing a BASE64 encoded string. If the client wishes + to cancel an authentication exchange, it should issue a + line with a single "*". If the server receives such an + answer, it must reject the AUTH command by sending a + negative response. + + A protection mechanism provides integrity and privacy + protection to the protocol session. If a protection + mechanism is negotiated, it is applied to all subsequent + data sent over the connection. The protection mechanism + takes effect immediately following the CRLF that concludes + the authentication exchange for the client, and the CRLF of + the positive response for the server. Once the protection + mechanism is in effect, the stream of command and response + octets is processed into buffers of ciphertext. Each + buffer is transferred over the connection as a stream of + octets prepended with a four octet field in network byte + order that represents the length of the following data. + The maximum ciphertext buffer length is defined by the + protection mechanism. + + The server is not required to support any particular + authentication mechanism, nor are authentication mechanisms + required to support any protection mechanisms. If an AUTH + command fails with a negative response, the session remains + in the AUTHORIZATION state and client may try another + authentication mechanism by issuing another AUTH command, + or may attempt to authenticate by using the USER/PASS or + APOP commands. In other words, the client may request + authentication types in decreasing order of preference, + with the USER/PASS or APOP command as a last resort. + + Should the client successfully complete the authentication + exchange, the POP3 server issues a positive response and + the POP3 session enters the TRANSACTION state. + + Possible Responses: + +OK maildrop locked and ready + -ERR authentication exchange failed + + + +Myers [Page 2] + +RFC 1734 POP3 AUTH December 1994 + + + + Examples: + S: +OK POP3 server ready + C: AUTH KERBEROS_V4 + S: + AmFYig== + C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT + +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd + WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh + S: + or//EoAADZI= + C: DiAF5A4gA+oOIALuBkAAmw== + S: +OK Kerberos V4 authentication successful + ... + C: AUTH FOOBAR + S: -ERR Unrecognized authentication type + + Note: the line breaks in the first client answer are + for editorial clarity and are not in real authentica- + tors. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Myers [Page 3] + +RFC 1734 POP3 AUTH December 1994 + + +3. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in RFC 822. + + Except as noted otherwise, all alphabetic characters are case- + insensitive. The use of upper or lower case characters to define + token strings is for editorial clarity only. Implementations MUST + accept these strings in a case-insensitive fashion. + + ATOM_CHAR ::= + + atom_specials ::= "(" / ")" / "{" / SPACE / CTLs / "%" / "*" / + <"> / "\" + + auth ::= "AUTH" 1*(SPACE / TAB) auth_type *(CRLF base64) + CRLF + + auth_type ::= 1*ATOM_CHAR + + base64 ::= *(4base64_CHAR) [base64_terminal] + + base64_char ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / + "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / + "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / + "Y" / "Z" / + "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / + "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / + "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / + "y" / "z" / + "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / + "8" / "9" / "+" / "/" + ;; Case-sensitive + + base64_terminal ::= (2base64_char "==") / (3base64_char "=") + + CHAR ::= + + continue_req ::= "+" SPACE base64 CRLF + + CR ::= + + CRLF ::= CR LF + + CTL ::= + + + + +Myers [Page 4] + +RFC 1734 POP3 AUTH December 1994 + + + LF ::= + + SPACE ::= + + TAB ::= + + + +4. References + + [IMAP4-AUTH] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, + Carnegie Mellon, December 1994. + + + +5. Security Considerations + + Security issues are discussed throughout this memo. + + + +6. Author's Address + + John G. Myers + Carnegie-Mellon University + 5000 Forbes Ave + Pittsburgh, PA 15213 + + EMail: jgm+@cmu.edu + + + + + + + + + + + + + + + + + + + + + + +Myers [Page 5] + diff --git a/RFC/rfc1870.txt b/RFC/rfc1870.txt new file mode 100644 index 00000000..e24ccec6 --- /dev/null +++ b/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: + C: + 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: SIZE=500000 + S: 250 Address Ok. + C: RCPT TO: + S: 250 ned@innosoft.com OK; can accomodate 500000 byte message + C: RCPT TO: + S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU + C: RCPT TO: + 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] + diff --git a/RFC/rfc1891.txt b/RFC/rfc1891.txt new file mode 100644 index 00000000..23b58ba9 --- /dev/null +++ b/RFC/rfc1891.txt @@ -0,0 +1,1739 @@ + + + + + + +Network Working Group K. Moore +Request for Comments: 1891 University of Tennessee +Category: Standards Track January 1996 + + + SMTP Service Extension + for Delivery Status Notifications + +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, which allows an + SMTP client to specify (a) that delivery status notifications (DSNs) + should be generated under certain conditions, (b) whether such + notifications should return the contents of the message, and (c) + additional information, to be returned with a DSN, that allows the + sender to identify both the recipient(s) for which the DSN was + issued, and the transaction in which the original message was sent. + + Any questions, comments, and reports of defects or ambiguities in + this specification may be sent to the mailing list for the NOTARY + working group of the IETF, using the address + . Requests to subscribe to the mailing + list should be addressed to . + Implementors of this specification are encouraged to subscribe to the + mailing list, so that they will quickly be informed of any problems + which might hinder interoperability. + + NOTE: This document is a Proposed Standard. If and when this + protocol is submitted for Draft Standard status, any normative text + (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in + this document will be re-evaluated in light of implementation + experience, and are thus subject to change. + +2. Introduction + + The SMTP protocol [1] requires that an SMTP server provide + notification of delivery failure, if it determines that a message + cannot be delivered to one or more recipients. Traditionally, such + notification consists of an ordinary Internet mail message (format + defined by [2]), sent to the envelope sender address (the argument of + + + +Moore Standards Track [Page 1] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + the SMTP MAIL command), containing an explanation of the error and at + least the headers of the failed message. + + Experience with large mail distribution lists [3] indicates that such + messages are often insufficient to diagnose problems, or even to + determine at which host or for which recipients a problem occurred. + In addition, the lack of a standardized format for delivery + notifications in Internet mail makes it difficult to exchange such + notifications with other message handling systems. + + Such experience has demonstrated a need for a delivery status + notification service for Internet electronic mail, which: + +(a) is reliable, in the sense that any DSN request will either be + honored at the time of final delivery, or result in a response + that indicates that the request cannot be honored, + +(b) when both success and failure notifications are requested, + provides an unambiguous and nonconflicting indication of whether + delivery of a message to a recipient succeeded or failed, + +(c) is stable, in that a failed attempt to deliver a DSN should never + result in the transmission of another DSN over the network, + +(d) preserves sufficient information to allow the sender to identify + both the mail transaction and the recipient address which caused + the notification, even when mail is forwarded or gatewayed to + foreign environments, and + +(e) interfaces acceptably with non-SMTP and non-822-based mail + systems, both so that notifications returned from foreign mail + systems may be useful to Internet users, and so that the + notification requests from foreign environments may be honored. + Among the requirements implied by this goal are the ability to + request non-return-of-content, and the ability to specify whether + positive delivery notifications, negative delivery notifications, + both, or neither, should be issued. + + In an attempt to provide such a service, this memo uses the mechanism + defined in [4] to define an extension to the SMTP protocol. Using + this mechanism, an SMTP client may request that an SMTP server issue + or not issue a delivery status notification (DSN) under certain + conditions. The format of a DSN is defined in [5]. + + + + + + + + +Moore Standards Track [Page 2] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +3. Framework for the Delivery Status Notification Extension + + The following service extension is therefore defined: + +(1) The name of the SMTP service extension is "Delivery Status + Notification"; + +(2) the EHLO keyword value associated with this extension is "DSN", + the meaning of which is defined in section 4 of this memo; + +(3) no parameters are allowed with this EHLO keyword value; + +(4) two optional parameters are added to the RCPT command, and two + optional parameters are added to the MAIL command: + + An optional parameter for the RCPT command, using the + esmtp-keyword "NOTIFY", (to specify the conditions under which a + delivery status notification should be generated), is defined in + section 5.1, + + An optional parameter for the RCPT command, using the + esmtp-keyword "ORCPT", (used to convey the "original" + (sender-specified) recipient address), is defined in section 5.2, + and + + An optional parameter for the MAIL command, using the + esmtp-keyword "RET", (to request that DSNs containing an + indication of delivery failure either return the entire contents + of a message or only the message headers), is defined in section + 5.3, + + An optional parameter for the MAIL command, using the + esmtp-keyword "ENVID", (used to propagate an identifier for this + message transmission envelope, which is also known to the sender + and will, if present, be returned in any DSNs issued for this + transmission), is defined in section 5.4; + +(5) no additional SMTP verbs are defined by this extension. + + The remainder of this memo specifies how support for the extension + effects the behavior of a message transfer agent. + +4. The Delivery Status Notification service extension + + An SMTP client wishing to request a DSN for a message 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 + + + +Moore Standards Track [Page 3] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + keyword DSN, then the Delivery Status Notification extension (as + described in this memo) is supported. + + Ordinarily, when an SMTP server returns a positive (2xx) reply code + in response to a RCPT command, it agrees to accept responsibility for + either delivering the message to the named recipient, or sending a + notification to the sender of the message indicating that delivery + has failed. However, an extended SMTP ("ESMTP") server which + implements this service extension will accept an optional NOTIFY + parameter with the RCPT command. If present, the NOTIFY parameter + alters the conditions for generation of delivery status notifications + from the default (issue notifications only on failure) specified in + [1]. The ESMTP client may also request (via the RET parameter) + whether the entire contents of the original message should be + returned (as opposed to just the headers of that message), along with + the DSN. + + In general, an ESMTP server which implements this service extension + will propagate delivery status notification requests when relaying + mail to other SMTP-based MTAs which also support this extension, and + make a "best effort" to ensure that such requests are honored when + messages are passed into other environments. + + In order that any delivery status notifications thus generated will + be meaningful to the sender, any ESMTP server which supports this + extension will attempt to propagate the following information to any + other MTAs that are used to relay the message, for use in generating + DSNs: + +(a) for each recipient, a copy of the original recipient address, as + used by the sender of the message. + + This address need not be the same as the mailbox specified in the + RCPT command. For example, if a message was originally addressed + to A@B.C and later forwarded to A@D.E, after such forwarding has + taken place, the RCPT command will specify a mailbox of A@D.E. + However, the original recipient address remains A@B.C. + + Also, if the message originated from an environment which does not + use Internet-style user@domain addresses, and was gatewayed into + SMTP, the original recipient address will preserve the original + form of the recipient address. + +(b) for the entire SMTP transaction, an envelope identification + string, which may be used by the sender to associate any delivery + status notifications with the transaction used to send the + original message. + + + + +Moore Standards Track [Page 4] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +5. Additional parameters for RCPT and MAIL commands + + The extended RCPT and MAIL commands are issued by a client when it + wishes to request a DSN from the server, under certain conditions, + for a particular recipient. The extended RCPT and MAIL commands are + identical to the RCPT and MAIL commands defined in [1], except that + one or more of the following parameters appear after the sender or + recipient address, respectively. The general syntax for extended + SMTP commands is defined in [4]. + + NOTE: Although RFC 822 ABNF is used to describe the syntax of these + parameters, they are not, in the language of that document, + "structured field bodies". Therefore, while parentheses MAY appear + within an emstp-value, they are not recognized as comment delimiters. + + The syntax for "esmtp-value" in [4] does not allow SP, "=", control + characters, or characters outside the traditional ASCII range of 1- + 127 decimal to be transmitted in an esmtp-value. Because the ENVID + and ORCPT parameters may need to convey values outside this range, + the esmtp-values for these parameters are encoded as "xtext". + "xtext" is formally defined as follows: + + xtext = *( xchar / hexchar ) + + xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, + except for "+" and "=". + +; "hexchar"s are intended to encode octets that cannot appear +; as ASCII characters within an esmtp-value. + + hexchar = ASCII "+" immediately followed by two upper case + hexadecimal digits + +When encoding an octet sequence as xtext: + ++ Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=", + MAY be encoded as itself. (A CHAR in this range MAY instead be + encoded as a "hexchar", at the implementor's discretion.) + ++ ASCII CHARs that fall outside the range above must be encoded as + "hexchar". + +5.1 The NOTIFY parameter of the ESMTP RCPT command + + A RCPT command issued by a client may contain the optional esmtp- + keyword "NOTIFY", to specify the conditions under which the SMTP + server should generate DSNs for that recipient. If the NOTIFY + esmtp-keyword is used, it MUST have an associated esmtp-value, + + + +Moore Standards Track [Page 5] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + formatted according to the following rules, using the ABNF of RFC + 822: + + notify-esmtp-value = "NEVER" / 1#notify-list-element + + notify-list-element = "SUCCESS" / "FAILURE" / "DELAY" + +Notes: + +a. Multiple notify-list-elements, separated by commas, MAY appear in a + NOTIFY parameter; however, the NEVER keyword MUST appear by itself. + +b. Any of the keywords NEVER, SUCCESS, FAILURE, or DELAY may be spelled + in any combination of upper and lower case letters. + +The meaning of the NOTIFY parameter values is generally as follows: + ++ A NOTIFY parameter value of "NEVER" requests that a DSN not be + returned to the sender under any conditions. + ++ A NOTIFY parameter value containing the "SUCCESS" or "FAILURE" + keywords requests that a DSN be issued on successful delivery or + delivery failure, respectively. + ++ A NOTIFY parameter value containing the keyword "DELAY" indicates the + sender's willingness to receive "delayed" DSNs. Delayed DSNs may be + issued if delivery of a message has been delayed for an unusual amount + of time (as determined by the MTA at which the message is delayed), + but the final delivery status (whether successful or failure) cannot + be determined. The absence of the DELAY keyword in a NOTIFY parameter + requests that a "delayed" DSN NOT be issued under any conditions. + + The actual rules governing interpretation of the NOTIFY parameter are + given in section 6. + + For compatibility with SMTP clients that do not use the NOTIFY + facility, the absence of a NOTIFY parameter in a RCPT command may be + interpreted as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY. + +5.2 The ORCPT parameter to the ESMTP RCPT command + + The ORCPT esmtp-keyword of the RCPT command is used to specify an + "original" recipient address that corresponds to the actual recipient + to which the message is to be delivered. If the ORCPT esmtp-keyword + is used, it MUST have an associated esmtp-value, which consists of + the original recipient address, encoded according to the rules below. + The ABNF for the ORCPT parameter is: + + + + +Moore Standards Track [Page 6] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + orcpt-parameter = "ORCPT=" original-recipient-address + + original-recipient-address = addr-type ";" xtext + + addr-type = atom + + The "addr-type" portion MUST be an IANA-registered electronic mail + address-type (as defined in [5]), while the "xtext" portion contains + an encoded representation of the original recipient address using the + rules in section 5 of this document. The entire ORCPT parameter MAY + be up to 500 characters in length. + + When initially submitting a message via SMTP, if the ORCPT parameter + is used, it MUST contain the same address as the RCPT TO address + (unlike the RCPT TO address, the ORCPT parameter will be encoded as + xtext). Likewise, when a mailing list submits a message via SMTP to + be distributed to the list subscribers, if ORCPT is used, the ORCPT + parameter MUST match the new RCPT TO address of each recipient, not + the address specified by the original sender of the message.) + + The "addr-type" portion of the original-recipient-address is used to + indicate the "type" of the address which appears in the ORCPT + parameter value. However, the address associated with the ORCPT + keyword is NOT constrained to conform to the syntax rules for that + "addr-type". + + Ideally, the "xtext" portion of the original-recipient-address should + contain, in encoded form, the same sequence of characters that the + sender used to specify the recipient. However, for a message + gatewayed from an environment (such as X.400) in which a recipient + address is not a simple string of printable characters, the + representation of recipient address must be defined by a + specification for gatewaying between DSNs and that environment. + +5.3 The RET parameter of the ESMTP MAIL command + + The RET esmtp-keyword on the extended MAIL command specifies whether + or not the message should be included in any failed DSN issued for + this message transmission. If the RET esmtp-keyword is used, it MUST + have an associated esmtp-value, which is one of the following + keywords: + + FULL requests that the entire message be returned in any "failed" + delivery status notification issued for this recipient. + + HDRS requests that only the headers of the message be returned. + + + + + +Moore Standards Track [Page 7] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + The FULL and HDRS keywords may be spelled in any combination of upper + and lower case letters. + + If no RET parameter is supplied, the MTA MAY return either the + headers of the message or the entire message for any DSN containing + indication of failed deliveries. + + Note that the RET parameter only applies to DSNs that indicate + delivery failure for at least one recipient. If a DSN contains no + indications of delivery failure, only the headers of the message + should be returned. + +5.4 The ENVID parameter to the ESMTP MAIL command + + The ENVID esmtp-keyword of the SMTP MAIL command is used to specify + an "envelope identifier" to be transmitted along with the message and + included in any DSNs issued for any of the recipients named in this + SMTP transaction. The purpose of the envelope identifier is to allow + the sender of a message to identify the transaction for which the DSN + was issued. + + The ABNF for the ENVID parameter is: + + envid-parameter = "ENVID=" xtext + + The ENVID esmtp-keyword MUST have an associated esmtp-value. No + meaning is assigned by the mail system to the presence or absence of + this parameter or to any esmtp-value associated with this parameter; + the information is used only by the sender or his user agent. The + ENVID parameter MAY be up to 100 characters in length. + +5.5 Restrictions on the use of Delivery Status Notification parameters + + The RET and ENVID parameters MUST NOT appear more than once each in + any single MAIL command. If more than one of either of these + parameters appears in a MAIL command, the ESMTP server SHOULD respond + with "501 syntax error in parameters or arguments". + + The NOTIFY and ORCPT parameters MUST NOT appear more than once in any + RCPT command. If more than one of either of these parameters appears + in a RCPT command, the ESMTP server SHOULD respond with "501 syntax + error in parameters or arguments". + +6. Conformance requirements + + The Simple Mail Transfer Protocol (SMTP) is used by Message Transfer + Agents (MTAs) when accepting, relaying, or gatewaying mail, as well + as User Agents (UAs) when submitting mail to the mail transport + + + +Moore Standards Track [Page 8] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + system. The DSN extension to SMTP may be used to allow UAs to convey + the sender's requests as to when DSNs should be issued. A UA which + claims to conform to this specification must meet certain + requirements as described below. + + Typically, a message transfer agent (MTA) which supports SMTP will + assume, at different times, both the role of a SMTP client and an + SMTP server, and may also provide local delivery, gatewaying to + foreign environments, forwarding, and mailing list expansion. An MTA + which, when acting as an SMTP server, issues the DSN keyword in + response to the EHLO command, MUST obey the rules below for a + "conforming SMTP client" when acting as a client, and a "conforming + SMTP server" when acting as a server. The term "conforming MTA" + refers to an MTA which conforms to this specification, independent of + its role of client or server. + +6.1 SMTP protocol interactions + + The following rules apply to SMTP transactions in which any of the + ENVID, NOTIFY, RET, or ORCPT keywords are used: + +(a) If an SMTP client issues a MAIL command containing a valid ENVID + parameter and associated esmtp-value and/or a valid RET parameter + and associated esmtp-value, a conforming SMTP server MUST return + the same reply-code as it would to the same MAIL command without + the ENVID and/or RET parameters. A conforming SMTP server MUST + NOT refuse a MAIL command based on the absence or presence of + valid ENVID or RET parameters, or on their associated + esmtp-values. + + However, if the associated esmtp-value is not valid (i.e. contains + illegal characters), or if there is more than one ENVID or RET + parameter in a particular MAIL command, the server MUST issue the + reply-code 501 with an appropriate message (e.g. "syntax error in + parameter"). + +(b) If an SMTP client issues a RCPT command containing any valid + NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST + return the same response as it would to the same RCPT command + without those NOTIFY and/or ORCPT parameters. A conforming SMTP + server MUST NOT refuse a RCPT command based on the presence or + absence of any of these parameters. + + However, if any of the associated esmtp-values are not valid, or + if there is more than one of any of these parameters in a + particular RCPT command, the server SHOULD issue the response "501 + syntax error in parameter". + + + + +Moore Standards Track [Page 9] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +6.2 Handling of messages received via SMTP + + This section describes how a conforming MTA should handle any + messages received via SMTP. + + NOTE: A DSN MUST NOT be returned to the sender for any message for + which the return address from the SMTP MAIL command was NULL ("<>"), + even if the sender's address is available from other sources (e.g. + the message header). However, the MTA which would otherwise issue a + DSN SHOULD inform the local postmaster of delivery failures through + some appropriate mechanism that will not itself result in the + generation of DSNs. + + DISCUSSION: RFC 1123, section 2.3.3 requires error notifications to + be sent with a NULL return address ("reverse-path"). This creates an + interesting situation when a message arrives with one or more + nonfunctional recipient addresses in addition to a nonfunctional + return address. When delivery to one of the recipient addresses + fails, the MTA will attempt to send a nondelivery notification to the + return address, setting the return address on the notification to + NULL. When the delivery of this notification fails, the MTA + attempting delivery of that notification sees a NULL return address. + If that MTA were not to inform anyone of the situation, the original + message would be silently lost. Furthermore, a nonfunctional return + address is often indicative of a configuration problem in the + sender's MTA. Reporting the condition to the local postmaster may + help to speed correction of such errors. + +6.2.1 Relay of messages to other conforming SMTP servers + + The following rules govern the behavior of a conforming MTA, when + relaying a message which was received via the SMTP protocol, to an + SMTP server that supports the Delivery Status Notification service + extension: + +(a) Any ENVID parameter included in the MAIL command when a message was + received, MUST also appear on the MAIL command with which the + message is relayed, with the same associated esmtp-value. If no + ENVID parameter was included in the MAIL command when the message + was received, the ENVID parameter MUST NOT be supplied when the + message is relayed. + +(b) Any RET parameter included in the MAIL command when a message was + received, MUST also appear on the MAIL command with which the + message is relayed, with the same associated esmtp-value. If no RET + parameter was included in the MAIL command when the message was + received, the RET parameter MUST NOT supplied when the message is + relayed. + + + +Moore Standards Track [Page 10] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +(c) If the NOTIFY parameter was supplied for a recipient when the + message was received, the RCPT command issued when the message is + relayed MUST also contain the NOTIFY parameter along with its + associated esmtp-value. If the NOTIFY parameter was not supplied + for a recipient when the message was received, the NOTIFY parameter + MUST NOT be supplied for that recipient when the message is relayed. + +(d) If any ORCPT parameter was present in the RCPT command for a + recipient when the message was received, an ORCPT parameter with the + identical original-recipient-address MUST appear in the RCPT command + issued for that recipient when relaying the message. (For example, + the MTA therefore MUST NOT change the case of any alphabetic + characters in an ORCPT parameter.) + + If no ORCPT parameter was present in the RCPT command when the + message was received, an ORCPT parameter MAY be added to the RCPT + command when the message is relayed. If an ORCPT parameter is added + by the relaying MTA, it MUST contain the recipient address from the + RCPT command used when the message was received by that MTA. + +6.2.2 Relay of messages to non-conforming SMTP servers + + The following rules govern the behavior of a conforming MTA (in the + role of client), when relaying a message which was received via the + SMTP protocol, to an SMTP server that does not support the Delivery + Status Notification service extension: + +(a) ENVID, NOTIFY, RET, or ORCPT parameters MUST NOT be issued when + relaying the message. + +(b) If the NOTIFY parameter was supplied for a recipient, with an esmtp- + value containing the keyword SUCCESS, and the SMTP server returns a + success (2xx) reply-code in response to the RCPT command, the client + MUST issue a "relayed" DSN for that recipient. + +(c) If the NOTIFY parameter was supplied for a recipient with an esmtp- + value containing the keyword FAILURE, and the SMTP server returns a + permanent failure (5xx) reply-code in response to the RCPT command, + the client MUST issue a "failed" DSN for that recipient. + +(d) If the NOTIFY parameter was supplied for a recipient with an esmtp- + value of NEVER, the client MUST NOT issue a DSN for that recipient, + regardless of the reply-code returned by the SMTP server. However, + if the server returned a failure (5xx) reply-code, the client MAY + inform the local postmaster of the delivery failure via an + appropriate mechanism that will not itself result in the generation + of DSNs. + + + + +Moore Standards Track [Page 11] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + When attempting to relay a message to an SMTP server that does not + support this extension, and if NOTIFY=NEVER was specified for some + recipients of that message, a conforming SMTP client MAY relay the + message for those recipients in a separate SMTP transaction, using + an empty reverse-path in the MAIL command. This will prevent DSNs + from being issued for those recipients by MTAs that conform to [1]. + +(e) If a NOTIFY parameter was not supplied for a recipient, and the SMTP + server returns a success (2xx) reply-code in response to a RCPT + command, the client MUST NOT issue any DSN for that recipient. + +(f) If a NOTIFY parameter was not supplied for a recipient, and the SMTP + server returns a permanent failure (5xx) reply-code in response to a + RCPT command, the client MUST issue a "failed" DSN for that + recipient. + +6.2.3 Local delivery of messages + + The following rules govern the behavior of a conforming MTA upon + successful delivery of a message that was received via the SMTP + protocol, to a local recipient's mailbox: + + "Delivery" means that the message has been placed in the recipient's + mailbox. For messages which are transmitted to a mailbox for later + retrieval via IMAP [6], POP [7] or a similar message access protocol, + "delivery" occurs when the message is made available to the IMAP + (POP, etc.) service, rather than when the message is retrieved by the + recipient's user agent. + + Similarly, for a recipient address which corresponds to a mailing + list exploder, "delivery" occurs when the message is made available + to that list exploder, even though the list exploder might refuse to + deliver that message to the list recipients. + +(a) If the NOTIFY parameter was supplied for that recipient, with an + esmtp-value containing the SUCCESS keyword, the MTA MUST issue a + "delivered" DSN for that recipient. + +(b) If the NOTIFY parameter was supplied for that recipient which did + not contain the SUCCESS keyword, the MTA MUST NOT issue a DSN for + that recipient. + +(c) If the NOTIFY parameter was not supplied for that recipient, the MTA + MUST NOT issue a DSN. + + + + + + + +Moore Standards Track [Page 12] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +6.2.4 Gatewaying a message into a foreign environment + + The following rules govern the behavior of a conforming MTA, when + gatewaying a message that was received via the SMTP protocol, into a + foreign (non-SMTP) environment: + +(a) If the the foreign environment is capable of issuing appropriate + notifications under the conditions requested by the NOTIFY + parameter, and the conforming MTA can ensure that any notification + thus issued will be translated into a DSN and delivered to the + original sender, then the MTA SHOULD gateway the message into the + foreign environment, requesting notification under the desired + conditions, without itself issuing a DSN. + +(b) If a NOTIFY parameter was supplied with the SUCCESS keyword, but the + destination environment cannot return an appropriate notification on + successful delivery, the MTA SHOULD issue a "relayed" DSN for that + recipient. + +(c) If a NOTIFY parameter was supplied with an esmtp-keyword of NEVER, a + DSN MUST NOT be issued. If possible, the MTA SHOULD direct the + destination environment to not issue delivery notifications for that + recipient. + +(d) If the NOTIFY parameter was not supplied for a particular recipient, + a DSN SHOULD NOT be issued by the gateway. The gateway SHOULD + attempt to ensure that appropriate notification will be provided by + the foreign mail environment if eventual delivery failure occurs, + and that no notification will be issued on successful delivery. + +(e) When gatewaying a message into a foreign environment, the return-of- + content conditions specified by any RET parameter are nonbinding; + however, the MTA SHOULD attempt to honor the request using whatever + mechanisms exist in the foreign environment. + +6.2.5 Delays in delivery + + If a conforming MTA receives a message via the SMTP protocol, and is + unable to deliver or relay the message to one or more recipients for + an extended length of time (to be determined by the MTA), it MAY + issue a "delayed" DSN for those recipients, subject to the following + conditions: + +(a) If the NOTIFY parameter was supplied for a recipient and its value + included the DELAY keyword, a "delayed" DSN MAY be issued. + +(b) If the NOTIFY parameter was not supplied for a recipient, a + "delayed" DSN MAY be issued. + + + +Moore Standards Track [Page 13] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +(c) If the NOTIFY parameter was supplied which did not contain the DELAY + keyword, a "delayed" DSN MUST NOT be issued. + + NOTE: Although delay notifications are common in present-day + electronic mail, a conforming MTA is never required to issue + "delayed" DSNs. The DELAY keyword of the NOTIFY parameter is + provided to allow the SMTP client to specifically request (by + omitting the DELAY parameter) that "delayed" DSNs NOT be issued. + +6.2.6 Failure of a conforming MTA to deliver a message + + The following rules govern the behavior of a conforming MTA which + received a message via the SMTP protocol, and is unable to deliver a + message to a recipient specified in the SMTP transaction: + +(a) If a NOTIFY parameter was supplied for the recipient with an esmtp- + keyword containing the value FAILURE, a "failed" DSN MUST be issued + by the MTA. + +(b) If a NOTIFY parameter was supplied for the recipient which did not + contain the value FAILURE, a DSN MUST NOT be issued for that + recipient. However, the MTA MAY inform the local postmaster of the + delivery failure via some appropriate mechanism which does not + itself result in the generation of DSNs. + +(c) If no NOTIFY parameter was supplied for the recipient, a "failed" + DSN MUST be issued. + + NOTE: Some MTAs are known to forward undeliverable messages to the + local postmaster or "dead letter" mailbox. This is still considered + delivery failure, and does not diminish the requirement to issue a + "failed" DSN under the conditions defined elsewhere in this memo. If + a DSN is issued for such a recipient, the Action value MUST be + "failed". + +6.2.7 Forwarding, aliases, and mailing lists + + Delivery of a message to a local email address usually causes the + message to be stored in the recipient's mailbox. However, MTAs + commonly provide a facility where a local email address can be + designated as an "alias" or "mailing list"; delivery to that address + then causes the message to be forwarded to each of the (local or + remote) recipient addresses associated with the alias or list. It is + also common to allow a user to optionally "forward" her mail to one + or more alternate addresses. If this feature is enabled, her mail is + redistributed to those addresses instead of being deposited in her + mailbox. + + + + +Moore Standards Track [Page 14] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + Following the example of [9] (section 5.3.6), this document defines + the difference between an "alias" and "mailing list" as follows: When + forwarding a message to the addresses associated with an "alias", the + envelope return address (e.g. SMTP MAIL FROM) remains intact. + However, when forwarding a message to the addresses associated with a + "mailing list", the envelope return address is changed to that of the + administrator of the mailing list. This causes DSNs and other + nondelivery reports resulting from delivery to the list members to be + sent to the list administrator rather than the sender of the original + message. + + The DSN processing for aliases and mailing lists is as follows: + +6.2.7.1 mailing lists + + When a message is delivered to a list submission address (i.e. placed + in the list's mailbox for incoming mail, or accepted by the process + that redistributes the message to the list subscribers), this is + considered final delivery for the original message. If the NOTIFY + parameter for the list submission address contained the SUCCESS + keyword, a "delivered" DSN MUST be returned to the sender of the + original message. + + NOTE: Some mailing lists are able to reject message submissions, + based on the content of the message, the sender's address, or some + other criteria. While the interface between such a mailing list and + its MTA is not well-defined, it is important that DSNs NOT be issued + by both the MTA (to report successful delivery to the list), and the + list (to report message rejection using a "failure" DSN.) + + However, even if a "delivered" DSN was issued by the MTA, a mailing + list which rejects a message submission MAY notify the sender that + the message was rejected using an ordinary message instead of a DSN. + + Whenever a message is redistributed to an mailing list, + +(a) The envelope return address is rewritten to point to the list + maintainer. This address MAY be that of a process that recognizes + DSNs and processes them automatically, but it MUST forward + unrecognized messages to the human responsible for the list. + +(b) The ENVID, NOTIFY, RET, and ORCPT parameters which accompany the + redistributed message MUST NOT be derived from those of the original + message. + +(c) The NOTIFY and RET parameters MAY be specified by the local + postmaster or the list administrator. If ORCPT parameters are + supplied during redistribution to the list subscribers, they SHOULD + + + +Moore Standards Track [Page 15] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + contain the addresses of the list subscribers in the format used by + the mailing list. + +6.2.7.2 single-recipient aliases + + Under normal circumstances, when a message arrives for an "alias" + which has a single forwarding address, a DSN SHOULD NOT be issued. + Any ENVID, NOTIFY, RET, or ORCPT parameters SHOULD be propagated with + the message as it is redistributed to the forwarding address. + +6.2.7.3 multiple-recipient aliases + + An "alias" with multiple recipient addresses may be handled in any of + the following ways: + +(a) Any ENVID, NOTIFY, RET, or ORCPT parameters are NOT propagated when + relaying the message to any of the forwarding addresses. If the + NOTIFY parameter for the alias contained the SUCCESS keyword, the + MTA issues a "relayed" DSN. (In effect, the MTA treats the message + as if it were being relayed into an environment that does not + support DSNs.) + +(b) Any ENVID, NOTIFY, RET, or ORCPT parameters (or the equivalent + requests if the message is gatewayed) are propagated to EXACTLY one + of the forwarding addresses. No DSN is issued. (This is + appropriate when aliasing is used to forward a message to a + "vacation" auto-responder program in addition to the local mailbox.) + +(c) Any ENVID, RET, or ORCPT parameters are propagated to all forwarding + addresses associated with that alias. The NOTIFY parameter is + propagated to the forwarding addresses, except that it any SUCCESS + keyword is removed. If the original NOTIFY parameter for the alias + contained the SUCCESS keyword, an "expanded" DSN is issued for the + alias. If the NOTIFY parameter for the alias did not contain the + SUCCESS keyword, no DSN is issued for the alias. + +6.2.7.4 confidential forwarding addresses + + If it is desired to maintain the confidentiality of a recipient's + forwarding address, the forwarding may be treated as if it were a + mailing list. A DSN will be issued, if appropriate, upon "delivery" + to the recipient address specified by the sender. When the message + is forwarded it will have a new envelope return address. Any DSNs + which result from delivery failure of the forwarded message will not + be returned to the original sender of the message and thus not expose + the recipient's forwarding address. + + + + + +Moore Standards Track [Page 16] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +6.2.8 DSNs describing delivery to multiple recipients + + A single DSN may describe attempts to deliver a message to multiple + recipients of that message. If a DSN is issued for some recipients + in an SMTP transaction and not for others according to the rules + above, the DSN SHOULD NOT contain information for recipients for whom + DSNs would not otherwise have been issued. + +6.3 Handling of messages from other sources + + For messages which originated from "local" users (whatever that + means), the specifications under which DSNs should be generated can + be communicated to the MTA via any protocol agreed on between the + sender's mail composer (user agent) and the MTA. The local MTA can + then either relay the message, or issue appropriate delivery status + notifications. However, if such requests are transmitted within the + message itself (for example in the message headers), the requests + MUST be removed from the message before it is transmitted via SMTP. + + For messages gatewayed from non-SMTP sources and further relayed by + SMTP, the gateway SHOULD, using the SMTP extensions described here, + attempt to provide the delivery reporting conditions expected by the + source mail environment. If appropriate, any DSNs returned to the + source environment SHOULD be translated into the format expected in + that environment. + +6.4 Implementation limits + + A conforming MTA MUST accept ESMTP parameters of at least the + following sizes: + + (a) ENVID parameter: 100 characters. + + (b) NOTIFY parameter: 28 characters. + + (c) ORCPT parameter: 500 characters. + + (d) RET parameter: 8 characters. + + The maximum sizes for the ENVID and ORCPT parameters are intended to + be adequate for the transmission of "foreign" envelope identifier and + original recipient addresses. However, user agents which use SMTP as + a message submission protocol SHOULD NOT generate ENVID parameters + which are longer than 38 characters in length. + + A conforming MTA MUST be able to accept SMTP command-lines which are + at least 1036 characters long (530 characters for the ORCPT and + NOTIFY parameters of the RCPT command, in addition to the 512 + + + +Moore Standards Track [Page 17] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + characters required by [1]). If other SMTP extensions are supported + by the MTA, the MTA MUST be able to accept a command-line large + enough for each SMTP command and any combination of ESMTP parameters + which may be used with that command. + +7. Format of delivery notifications + + The format of delivery status notifications is defined in [5], which + uses the framework defined in [8]. Delivery status notifications are + to be returned to the sender of the original message as outlined + below. + +7.1 SMTP Envelope to be used with delivery status notifications + + The DSN sender address (in the SMTP MAIL command) MUST be a null + reverse-path ("<>"), as required by section 5.3.3 of [9]. The DSN + recipient address (in the RCPT command) is copied from the MAIL + command which accompanied the message for which the DSN is being + issued. When transmitting a DSN via SMTP, the RET parameter MUST NOT + be used. The NOTIFY parameter MAY be used, but its value MUST be + NEVER. The ENVID parameter (with a newly generated envelope-id) + and/or ORCPT parameter MAY be used. + +7.2 Contents of the DSN + + A DSN is transmitted as a MIME message with a top-level content-type + of multipart/report (as defined in [5]). + + The multipart/report content-type may be used for any of several + kinds of reports generated by the mail system. When multipart/report + is used to convey a DSN, the report-type parameter of the + multipart/report content-type is "delivery-status". + + As described in [8], the first component of a multipart/report + content-type is a human readable explanation of the report. For a + DSN, the second component of the multipart/report is of content-type + message/delivery-status (defined in [5]). The third component of the + multipart/report consists of the original message or some portion + thereof. When the value of the RET parameter is FULL, the full + message SHOULD be returned for any DSN which conveys notification of + delivery failure. (However, if the length of the message is greater + than some implementation-specified length, the MTA MAY return only + the headers even if the RET parameter specified FULL.) If a DSN + contains no notifications of delivery failure, the MTA SHOULD return + only the headers. + + The third component must have an appropriate content-type label. + Issues concerning selection of the content-type are discussed in [8]. + + + +Moore Standards Track [Page 18] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +7.3 Message/delivery-status fields + + The message/delivery-status content-type defines a number of fields, + with general specifications for their contents. The following + requirements for any DSNs generated in response to a message received + by the SMTP protocol by a conforming SMTP server, are in addition to + the requirements defined in [5] for the message/delivery-status type. + + When generating a DSN for a message which was received via the SMTP + protocol, a conforming MTA will generate the following fields of the + message/delivery-status body part: + +(a) if an ENVID parameter was present on the MAIL command, an Original- + Envelope-ID field MUST be supplied, and the value associated with + the ENVID parameter must appear in that field. If the message was + received via SMTP with no ENVID parameter, the Original-Envelope-ID + field MUST NOT be supplied. + + Since the ENVID parameter is encoded as xtext, but the Original- + Envelope-ID header is NOT encoded as xtext, the MTA must decode the + xtext encoding when copying the ENVID value to the Original- + Envelope-ID field. + +(b) The Reporting-MTA field MUST be supplied. If Reporting MTA can + determine its fully-qualified Internet domain name, the MTA-name- + type subfield MUST be "dns", and the field MUST contain the fully- + qualified domain name of the Reporting MTA. If the fully-qualified + Internet domain name of the Reporting MTA is not known (for example, + for an SMTP server which is not directly connected to the Internet), + the Reporting-MTA field may contain any string identifying the MTA, + however, in this case the MTA-name-type subfield MUST NOT be "dns". + A MTA-name-type subfield value of "x-local-hostname" is suggested. + +(c) Other per-message fields as defined in [5] MAY be supplied as + appropriate. + +(d) If the ORCPT parameter was provided for this recipient, the + Original-Recipient field MUST be supplied, with its value taken from + the ORCPT parameter. If no ORCPT parameter was provided for this + recipient, the Original-Recipient field MUST NOT appear. + +(e) The Final-Recipient field MUST be supplied. It MUST contain the + recipient address from the message envelope. If the message was + received via SMTP, the address-type will be "rfc822". + +(f) The Action field MUST be supplied. + + + + + +Moore Standards Track [Page 19] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +(g) The Status field MUST be supplied, using a status-code from [10]. + If there is no specific code which suitably describes a delivery + failure, either 4.0.0 (temporary failure), or 5.0.0 (permanent + failure) MUST be used. + +(h) For DSNs resulting from attempts to relay a message to one or more + recipients via SMTP, the Remote-MTA field MUST be supplied for each + of those recipients. The mta-name-type subfields of those Remote- + MTA fields will be "dns". + +(i) For DSNs resulting from attempts to relay a message to one or more + recipients via SMTP, the Diagnostic-Code MUST be supplied for each + of those recipients. The diagnostic-type subfield will be "smtp". + See section 9.2(a) of this document for a description of the "smtp" + diagnostic-code. + +(j) For DSNs resulting from attempts to relay a message to one or more + recipients via SMTP, an SMTP-Remote-Recipient extension field MAY be + supplied for each recipient, which contains the address of that + recpient which was presented to the remote SMTP server. + +(k) Other per-recipient fields defined in [5] MAY appear, as + appropriate. + +8. Acknowledgments + + The author wishes to thank Eric Allman, Harald Alvestrand, Jim + Conklin, Bryan Costales, Peter Cowen, Dave Crocker, Roger Fajman, Ned + Freed, Marko Kaittola, Steve Kille, John Klensin, Anastasios + Kotsikonas, John Gardiner Myers, Julian Onions, Jacob Palme, Marshall + Rose, Greg Vaudreuil, and Klaus Weide for their suggestions for + improvement of this document. + + + + + + + + + + + + + + + + + + + +Moore Standards Track [Page 20] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +9. Appendix - Type-Name Definitions + + The following type names are defined for use in DSN fields generated + by conforming SMTP-based MTAs: + +9.1 "rfc822" address-type + + The "rfc822" address-type is to be used when reporting Internet + electronic mail address in the Original-Recipient and Final-Recipient + DSN fields. + +(a) address-type name: rfc822 + +(b) syntax for mailbox addresses + + RFC822 mailbox addresses are generally expected to be of the form + + [route] addr-spec + + where "route" and "addr-spec" are defined in [2], and the "domain" + portions of both "route" and "addr-spec" are fully-qualified domain + names that are registered in the DNS. However, an MTA MUST NOT + modify an address obtained from the message envelope to force it to + conform to syntax rules. + +(c) If addresses of this type are not composed entirely of graphic +characters from the US-ASCII repertoire, a specification for how they +are to be encoded as graphic US-ASCII characters in a DSN Original- +Recipient or Final-Recipient DSN field. + + RFC822 addresses consist entirely of graphic characters from the US- + ASCII repertoire, so no translation is necessary. + +9.2 "smtp" diagnostic-type + + The "smtp" diagnostic-type is to be used when reporting SMTP reply- + codes in Diagnostic-Code DSN fields. + +(a) diagnostic-type name: SMTP + +(b) A description of the syntax to be used for expressing diagnostic +codes of this type as graphic characters from the US-ASCII repertoire. + + An SMTP diagnostic-code is of the form + + *( 3*DIGIT "-" *text ) 3*DIGIT SPACE *text + + + + + +Moore Standards Track [Page 21] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + For a single-line SMTP reply to an SMTP command, the diagnostic-code + SHOULD be an exact transcription of the reply. For multi-line SMTP + replies, it is necessary to insert a SPACE before each line after + the first. For example, an SMTP reply of: + + 550-mailbox unavailable + 550 user has moved with no forwarding address + + could appear as follows in a Diagnostic-Code DSN field: + + Diagnostic-Code: smtp ; 550-mailbox unavailable + 550 user has moved with no forwarding address + +(c) A list of valid diagnostic codes of this type and the meaning of +each code. + + SMTP reply-codes are currently defined in [1], [4], and [9]. + Additional codes may be defined by other RFCs. + +9.3 "dns" MTA-name-type + + The "dns" MTA-name-type should be used in the Reporting-MTA field. + An MTA-name of type "dns" is a fully-qualified domain name. The name + must be registered in the DNS, and the address Postmaster@{mta-name} + must be valid. + +(a) MTA-name-type name: dns + +(b) A description of the syntax of MTA names of this type, using BNF, +regular expressions, ASN.1, or other non-ambiguous language. + + MTA names of type "dns" SHOULD be valid Internet domain names. If + such domain names are not available, a domain-literal containing the + internet protocol address is acceptable. Such domain names + generally conform to the following syntax: + + domain = real-domain / domain-literal + + real-domain = sub-domain *("." sub-domain) + + sub-domain = atom + + domain-literal = "[" 1*3DIGIT 3("." 1*3DIGIT) "]" + + where "atom" and "DIGIT" are defined in [2]. + + + + + + +Moore Standards Track [Page 22] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +(c) If MTA names of this type do not consist entirely of graphic +characters from the US-ASCII repertoire, a specification for how an MTA +name of this type should be expressed as a sequence of graphic US-ASCII +characters. + + MTA names of type "dns" consist entirely of graphic US-ASCII + characters, so no translation is needed. + +10. Appendix - Example + + This example traces the flow of a single message addressed to + multiple recipients. The message is sent by Alice@Pure-Heart.ORG to + Bob@Big-Bucks.COM, Carol@Ivory.EDU, Dana@Ivory.EDU, + Eric@Bombs.AF.MIL, Fred@Bombs.AF.MIL, and George@Tax-ME.GOV, with a + variety of per-recipient options. The message is successfully + delivered to Bob, Dana (via a gateway), Eric, and Fred. Delivery + fails for Carol and George. + + NOTE: Formatting rules for RFCs require that no line be longer than + 72 characters. Therefore, in the following examples, some SMTP + commands longer than 72 characters are printed on two lines, with the + first line ending in "\". In an actual SMTP transaction, such a + command would be sent as a single line (i.e. with no embedded CRLFs), + and without the "\" character that appears in these examples. + +10.1 Submission + + Alice's user agent sends the message to the SMTP server at Pure- + Heart.ORG. Note that while this example uses SMTP as a mail + submission protocol, other protocols could also be used. + +<<< 220 Pure-Heart.ORG SMTP server here +>>> EHLO Pure-Heart.ORG +<<< 250-Pure-Heart.ORG +<<< 250-DSN +<<< 250-EXPN +<<< 250 SIZE +>>> MAIL FROM: RET=HDRS ENVID=QQ314159 +<<< 250 sender ok +>>> RCPT TO: NOTIFY=SUCCESS \ + ORCPT=rfc822;Bob@Big-Bucks.COM +<<< 250 recipient ok +>>> RCPT TO: NOTIFY=FAILURE \ + ORCPT=rfc822;Carol@Ivory.EDU +<<< 250 recipient ok +>>> RCPT TO: NOTIFY=SUCCESS,FAILURE \ + ORCPT=rfc822;Dana@Ivory.EDU +<<< 250 recipient ok + + + +Moore Standards Track [Page 23] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +>>> RCPT TO: NOTIFY=FAILURE \ + ORCPT=rfc822;Eric@Bombs.AF.MIL +<<< 250 recipient ok +>>> RCPT TO: NOTIFY=NEVER +<<< 250 recipient ok +>>> RCPT TO: NOTIFY=FAILURE \ + ORCPT=rfc822;George@Tax-ME.GOV +<<< 250 recipient ok +>>> DATA +<<< 354 okay, send message +>>> (message goes here) +>>> . +<<< 250 message accepted +>>> QUIT +<<< 221 goodbye + +10.2 Relay to Big-Bucks.COM + + The SMTP at Pure-Heart.ORG then relays the message to Big-Bucks.COM. + (For the purpose of this example, mail.Big-Bucks.COM is the primary + mail exchanger for Big-Bucks.COM). + +<<< 220 mail.Big-Bucks.COM says hello +>>> EHLO Pure-Heart.ORG +<<< 250-mail.Big-Bucks.COM +<<< 250 DSN +>>> MAIL FROM: RET=HDRS ENVID=QQ314159 +<<< 250 sender okay +>>> RCPT TO: NOTIFY=SUCCESS \ + ORCPT=rfc822;Bob@Big-Bucks.COM +<<< 250 recipient okay +>>> DATA +<<< 354 send message +>>> (message goes here) +>>> . +<<< 250 message received +>>> QUIT +<<< 221 bcnu + +10.3 Relay to Ivory.EDU + + The SMTP at Pure-Heart.ORG relays the message to Ivory.EDU, which (as + it happens) is a gateway to a LAN-based mail system that accepts SMTP + mail and supports the DSN extension. + +<<< 220 Ivory.EDU gateway to FooMail(tm) here +>>> EHLO Pure-Heart.ORG +<<< 250-Ivory.EDU + + + +Moore Standards Track [Page 24] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +<<< 250 DSN +>>> MAIL FROM: RET=HDRS ENVID=QQ314159 +<<< 250 ok +>>> RCPT TO: NOTIFY=FAILURE \ + ORCPT=rfc822;Carol@Ivory.EDU +<<< 550 error - no such recipient +>>> RCPT TO: NOTIFY=SUCCESS,FAILURE \ + ORCPT=rfc822;Dana@Ivory.EDU +<<< 250 recipient ok +>>> DATA +<<< 354 send message, end with '.' +>>> (message goes here) +>>> . +<<< 250 message received +>>> QUIT +<<< 221 bye + + Note that since the Ivory.EDU refused to accept mail for + Carol@Ivory.EDU, and the sender specified NOTIFY=FAILURE, the + sender-SMTP (in this case Pure-Heart.ORG) must generate a DSN. + +10.4 Relay to Bombs.AF.MIL + + The SMTP at Pure-Heart.ORG relays the message to Bombs.AF.MIL, which + does not support the SMTP extension. Because the sender specified + NOTIFY=NEVER for recipient Fred@Bombs.AF.MIL, the SMTP at Pure- + Heart.ORG chooses to send the message for that recipient in a + separate transaction with a reverse-path of <>. + +<<< 220-Bombs.AF.MIL reporting for duty. +<<< 220 Electronic mail is to be used for official business only. +>>> EHLO Pure-Heart.ORG +<<< 502 command not implemented +>>> RSET +<<< 250 reset +>>> HELO Pure-Heart.ORG +<<< 250 Bombs.AF.MIL +>>> MAIL FROM: +<<< 250 ok +>>> RCPT TO: +<<< 250 ok +>>> DATA +<<< 354 send message +>>> (message goes here) +>>> . +<<< 250 message accepted +>>> MAIL FROM:<> +<<< 250 ok + + + +Moore Standards Track [Page 25] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +>>> RCPT TO: +<<< 250 ok +>>> DATA +<<< 354 send message +>>> (message goes here) +>>> . +<<< 250 message accepted +>>> QUIT +<<< 221 Bombs.AF.MIL closing connection + +10.5 Forward from George@Tax-ME.GOV to Sam@Boondoggle.GOV + + The SMTP at Pure-Heart.ORG relays the message to Tax-ME.GOV. (this + step is not shown). MTA Tax-ME.GOV then forwards the message to + Sam@Boondoggle.GOV (shown below). Both Tax-ME.GOV and Pure-Heart.ORG + support the SMTP DSN extension. Note that RET, ENVID, and ORCPT all + retain their original values. + +<<< 220 BoonDoggle.GOV says hello +>>> EHLO Pure-Heart.ORG +<<< 250-mail.Big-Bucks.COM +<<< 250 DSN +>>> MAIL FROM: RET=HDRS ENVID=QQ314159 +<<< 250 sender okay +>>> RCPT TO: NOTIFY=SUCCESS \ + ORCPT=rfc822;George@Tax-ME.GOV +<<< 250 recipient okay +>>> DATA +<<< 354 send message +>>> (message goes here) +>>> . +<<< 250 message received +>>> QUIT +<<< 221 bcnu + + + + + + + + + + + + + + + + + +Moore Standards Track [Page 26] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +10.6 "Delivered" DSN for Bob@Big-Bucks.COM + + MTA mail.Big-Bucks.COM successfully delivers the message to Bob@Big- + Bucks.COM. Because the sender specified NOTIFY=SUCCESS, mail.Big- + Bucks.COM issues the following DSN, and sends it to Alice@Pure- + Heart.ORG. + +To: Alice@Pure-Heart.ORG +From: postmaster@mail.Big-Bucks.COM +Subject: Delivery Notification (success) for Bob@Big-Bucks.COM +Content-Type: multipart/report; report-type=delivery-status; + boundary=abcde +MIME-Version: 1.0 + +--abcde +Content-type: text/plain; charset=us-ascii + +Your message (id QQ314159) was successfully delivered to +Bob@Big-Bucks.COM. + +--abcde +Content-type: message/delivery-status + +Reporting-MTA: dns; mail.Big-Bucks.COM +Original-Envelope-ID: QQ314159 + +Original-Recipient: rfc822;Bob@Big-Bucks.COM +Final-Recipient: rfc822;Bob@Big-Bucks.COM +Action: delivered +Status: 2.0.0 + +--abcde +Content-type: message/rfc822 + +(headers of returned message go here) + +--abcde-- + + + + + + + + + + + + + + +Moore Standards Track [Page 27] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +10.7 Failed DSN for Carol@Ivory.EDU + + Because delivery to Carol failed and the sender specified + NOTIFY=FAILURE for Carol@Ivory.EDU, MTA Pure-Heart.ORG (the SMTP + client to which the failure was reported via SMTP) issues the + following DSN. + +To: Alice@Pure-Heart.ORG +From: postmaster@Pure-Heart.ORG +Subject: Delivery Notification (failure) for Carol@Ivory.EDU +Content-Type: multipart/report; report-type=delivery-status; + boundary=bcdef +MIME-Version: 1.0 + +--bcdef +Content-type: text/plain; charset=us-ascii + +Your message (id QQ314159) could not be delivered to +Carol@Ivory.EDU. + +A transcript of the session follows: + +(while talking to Ivory.EDU) +>>> RCPT TO: NOTIFY=FAILURE +<<< 550 error - no such recipient + +--bcdef +Content-type: message/delivery-status + +Reporting-MTA: dns; Pure-Heart.ORG +Original-Envelope-ID: QQ314159 + +Original-Recipient: rfc822;Carol@Ivory.EDU +Final-Recipient: rfc822;Carol@Ivory.EDU +SMTP-Remote-Recipient: Carol@Ivory.EDU +Diagnostic-Code: smtp; 550 error - no such recipient +Action: failed +Status: 5.0.0 + +--bcdef +Content-type: message/rfc822 + +(headers of returned message go here) + +--bcdef-- + + + + + + +Moore Standards Track [Page 28] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +10.8 Relayed DSN For Dana@Ivory.EDU + + Although the mail gateway Ivory.EDU supports the DSN SMTP extension, + the LAN mail system attached to its other side does not generate + positive delivery confirmations. So Ivory.EDU issues a "relayed" + DSN: + +To: Alice@Pure-Heart.ORG +From: postmaster@Ivory.EDU +Subject: mail relayed for Dana@Ivory.EDU +Content-Type: multipart/report; report-type=delivery-status; + boundary=cdefg +MIME-Version: 1.0 + +--cdefg +Content-type: text/plain; charset=us-ascii + +Your message (addressed to Dana@Ivory.EDU) was successfully +relayed to: + +ymail!Dana + +by the FooMail gateway at Ivory.EDU. + +Unfortunately, the remote mail system does not support +confirmation of actual delivery. Unless delivery to ymail!Dana +fails, this will be the only delivery status notification sent. + +--cdefg +Content-type: message/delivery-status + +Reporting-MTA: dns; Ivory.EDU +Original-Envelope-ID: QQ314159 + +Original-Recipient: rfc822;Dana@Ivory.EDU +Final-Recipient: rfc822;Dana@Ivory.EDU +Action: relayed +Status: 2.0.0 + +--cdefg +Content-type: message/rfc822 + +(headers of returned message go here) + +--cdefg-- + + + + + + +Moore Standards Track [Page 29] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +10.9 Failure notification for Sam@Boondoggle.GOV + + The message originally addressed to George@Tax-ME.GOV was forwarded + to Sam@Boondoggle.GOV, but the MTA for Boondoggle.GOV was unable to + deliver the message due to a lack of disk space in Sam's mailbox. + After trying for several days, Boondoggle.GOV returned the following + DSN: + +To: Alice@BigHeart.ORG +From: Postmaster@Boondoggle.GOV +Subject: Delivery failure for Sam@Boondoggle.GOV +Content-Type: multipart/report; report-type=delivery-status; + boundary=defgh +MIME-Version: 1.0 + +--defgh +Your message, originally addressed to George@Tax-ME.GOV, and forwarded +from there to Sam@Boondoggle.GOV could not be delivered, for the +following reason: + +write error to mailbox, disk quota exceeded + +--defgh +Content-type: message/delivery-status + +Reporting-MTA: Boondoggle.GOV +Original-Envelope-ID: QQ314159 + +Original-Recipient: rfc822;George@Tax-ME.GOV +Final-Recipient: rfc822;Sam@Boondoggle.GOV +Action: failed +Status: 4.2.2 (disk quota exceeded) + +--defgh +Content-type: message/rfc822 + +(headers of returned message go here) + +--defgh-- + + + + + + + + + + + + +Moore Standards Track [Page 30] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +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] Westine, A., and J. Postel, "Problems with the Maintenance of + Large Mailing Lists.", RFC 1211, USC/Information Sciences + Institute, March 1991. + + [4] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, + "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach + Consulting, Inc., Network Management Associates, Inc., Silicon + Graphics, Inc., July 1994. + + [5] Moore, K., and G. Vaudreuil, "An Extensible Message Format for + Delivery Status Notifications", RFC 1894, University of Tennessee, + Octel Network Services, January 1996. + + [6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC + 1730, University of Washington, 20 December 1994. + + [7] Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC + 1725, Carnegie Mellon, Dover Beach Consulting, November 1994. + + [8] Vaudreuil, G., "The Multipart/Report Content Type for the + Reporting of Mail System Administrative Messages", RFC 1892, Octel + Network Services, January 1996. + + [9] Braden, R., Editor, "Requirements for Internet Hosts - Application + and Support", STD 3, RFC 1123, IETF, October 1989. + + [10] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, + Octel Network Services, January 1996. + +12. Author's Address + + Keith Moore + University of Tennessee + 107 Ayres Hall + Knoxville, TN 37996-1301 + USA + + EMail: moore@cs.utk.edu + + + + + +Moore Standards Track [Page 31] + diff --git a/RFC/rfc1892.txt b/RFC/rfc1892.txt new file mode 100644 index 00000000..c4bdbd5f --- /dev/null +++ b/RFC/rfc1892.txt @@ -0,0 +1,227 @@ + + + + + + +Network Working Group G. Vaudreuil +Request for Comments: 1892 Octel Network Services +Category: Standards Track January 1996 + + + The Multipart/Report Content Type + for the Reporting of + Mail System Administrative Messages + +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. The Multipart/Report MIME content-type + + The Multipart/Report MIME content-type is a general "family" or + "container" type for electronic mail reports of any kind. Although + this memo defines only the use of the Multipart/Report content-type + with respect to delivery status reports, mail processing programs + will benefit if a single content-type is used to for all kinds of + reports. + + The Multipart/Report content-type is defined as follows: + + MIME type name: multipart + MIME subtype name: report + Required parameters: boundary, report-type + Optional parameters: none + Encoding considerations: 7bit should always be adequate + Security considerations: see section 4 of this memo. + + The syntax of Multipart/Report is identical to the Multipart/Mixed + content type defined in [MIME]. When used to send a report, the + Multipart/Report content-type must be the top-level MIME content type + for any report message. The report-type parameter identifies the + type of report. The parameter is the MIME content sub-type of the + second body part of the Multipart/Report. + + User agents and gateways must be able to automatically determine + that a message is a mail system report and should be processed as + such. Placing the Multipart/Report as the outermost content + provides a mechanism whereby an auto-processor may detect through + parsing the RFC 822 headers that the message is a report. + + + + +Vaudreuil Standards Track [Page 1] + +RFC 1892 Multipart/Report January 1996 + + + The Multipart/Report content-type contains either two or three sub- + parts, in the following order: + + (1) [required] The first body part contains human readable message. + The purpose of this message is to provide an easily-understood + description of the condition(s) that caused the report to be + generated, for a human reader who may not have an user agent + capable of interpreting the second section of the + Multipart/Report. + + The text in the first section may be in any MIME standards-track + content-type, charset, or language. Where a description of the + error is desired in several languages or several media, a + Multipart/Alternative construct may be used. + + This body part may also be used to send detailed information + that cannot be easily formatted into a Message/Report body part. + + (2) [required] A machine parsable body part containing an account + of the reported message handling event. The purpose of this body + part is to provide a machine-readable description of the + condition(s) which caused the report to be generated, along with + details not present in the first body part that may be useful to + human experts. An initial body part, Message/delivery-status is + defined in [DSN] + + (3) [optional] A body part containing the returned message or a + portion thereof. This information may be useful to aid human + experts in diagnosing problems. (Although it may also be useful + to allow the sender to identify the message which the report was + issued, it is hoped that the envelope-id and original-recipient- + address returned in the Message/Report body part will replace + the traditional use of the returned content for this purpose.) + + Return of content may be wasteful of network bandwidth and a variety + of implementation strategies can be used. Generally the sender + should choose the appropriate strategy and inform the recipient of + the required level of returned content required. In the absence of + an explicit request for level of return of content such as that + provided in [DRPT], the agent which generated the delivery service + report should return the full message content. + + When data not encoded in 7 bits is to be returned, and the return + path is not guaranteed to be 8-bit capable, two options are + available. The origional message MAY be reencoded into a legal 7 bit + MIME message or the Text/RFC822-Headers content-type MAY be used to + return only the origional message headers. + + + + +Vaudreuil Standards Track [Page 2] + +RFC 1892 Multipart/Report January 1996 + + +2. The Text/RFC822-Headers MIME content-type + + The Text/RFC822-Headers MIME content-type provides a mechanism to + label and return only the RFC 822 headers of a failed message. These + headers are not the complete message and should not be returned as a + Message/RFC822. The returned headers are useful for identifying the + failed message and for diagnostics based on the received: lines. + + The Text/RFC822-Headers content-type is defined as follows: + + MIME type name: Text + MIME subtype name: RFC822-Headers + Required parameters: None + Optional parameters: none + Encoding considerations: 7 bit is sufficient for normal RFC822 + headers, however, if the headers are broken and require + encoding, they may be encoded in quoted-printable. + Security considerations: see section 4 of this memo. + + The Text/RFC822-headers body part should contain all the RFC822 + header lines from the message which caused the report. The RFC822 + headers include all lines prior to the blank line in the message. + They include the MIME-Version and MIME Content- headers. + +3. References + + [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for + Delivery Status Notifications", RFC 1894, University of + Tennessee, Octel Network Services, January 1996. + + [RFC822] Crocker, D., "Standard for the format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail + Extensions", RFC 1521, Bellcore, Innosoft, June 1992. + + [DRPT] Moore, K., "SMTP Service Extension for Delivery Status + Notifications", RFC 1891, University of Tennessee, January 1996. + +4. Security Considerations + + Automated use of report types without authentication presents several + security issues. Forging negative reports presents the opportunity + for denial-of-service attacks when the reports are used for automated + maintenance of directories or mailing lists. Forging positive + reports may cause the sender to incorrectly believe a message was + delivered when it was not. + + + + +Vaudreuil Standards Track [Page 3] + +RFC 1892 Multipart/Report January 1996 + + +5. Author's Address + + Gregory M. Vaudreuil + Octel Network Services + 17060 Dallas Parkway + Dallas, TX 75248-1905 + + Phone: +1-214-733-2722 + EMail: Greg.Vaudreuil@Octel.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vaudreuil Standards Track [Page 4] + diff --git a/RFC/rfc1893.txt b/RFC/rfc1893.txt new file mode 100644 index 00000000..9ca4efb5 --- /dev/null +++ b/RFC/rfc1893.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group G. Vaudreuil +Request for Comments: 1893 Octel Network Services +Category: Standards Track January 1996 + + + Enhanced Mail System Status Codes + +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. Overview + + There currently is not a standard mechanism for the reporting of mail + system errors except for the limited set offered by SMTP and the + system specific text descriptions sent in mail messages. There is a + pressing need for a rich machine readable status code for use in + delivery status notifications [DSN]. This document proposes a new + set of status codes for this purpose. + + SMTP [SMTP] error codes have historically been used for reporting + mail system errors. Because of limitations in the SMTP code design, + these are not suitable for use in delivery status notifications. + SMTP provides about 12 useful codes for delivery reports. The + majority of the codes are protocol specific response codes such as + the 354 response to the SMTP data command. Each of the 12 useful + codes are each overloaded to indicate several error conditions each. + SMTP suffers some scars from history, most notably the unfortunate + damage to the reply code extension mechanism by uncontrolled use. + This proposal facilitates future extensibility by requiring the + client to interpret unknown error codes according to the theory of + codes while requiring servers to register new response codes. + + The SMTP theory of reply codes partitioned in the number space such a + manner that the remaining available codes will not provide the space + needed. The most critical example is the existence of only 5 + remaining codes for mail system errors. The mail system + classification includes both host and mailbox error conditions. The + remaining third digit space would be completely consumed as needed to + indicate MIME and media conversion errors and security system errors. + + A revision to the SMTP theory of reply codes to better distribute the + error conditions in the number space will necessarily be incompatible + with SMTP. Further, consumption of the remaining reply-code number + + + +Vaudreuil Standards Track [Page 1] + +RFC 1893 Mail System Status Codes January 1996 + + + space for delivery notification reporting will reduce the available + codes for new ESMTP extensions. + + The following proposal is based on the SMTP theory of reply codes. + It adopts the success, permanent error, and transient error semantics + of the first value, with a further description and classification in + the second. This proposal re-distributes the classifications to + better distribute the error conditions, such as separating mailbox + from host errors. + +2. Status Codes + + This document defines a new set of status codes to report mail system + conditions. These status codes are intended to be used for media and + language independent status reporting. They are not intended for + system specific diagnostics. + + The syntax of the new status codes is defined as: + + status-code = class "." subject "." detail + class = "2"/"4"/"5" + subject = 1*3digit + detail = 1*3digit + + White-space characters and comments are NOT allowed within a status- + code. Each numeric sub-code within the status-code MUST be expressed + without leading zero digits. + + Status codes consist of three numerical fields separated by ".". The + first sub-code indicates whether the delivery attempt was successful. + The second sub-code indicates the probable source of any delivery + anomalies, and the third sub-code indicates a precise error + condition. + + The codes space defined is intended to be extensible only by + standards track documents. Mail system specific status codes should + be mapped as close as possible to the standard status codes. Servers + should send only defined, registered status codes. System specific + errors and diagnostics should be carried by means other than status + codes. + + New subject and detail codes will be added over time. Because the + number space is large, it is not intended that published status codes + will ever be redefined or eliminated. Clients should preserve the + extensibility of the code space by reporting the general error + described in the subject sub-code when the specific detail is + unrecognized. + + + + +Vaudreuil Standards Track [Page 2] + +RFC 1893 Mail System Status Codes January 1996 + + + The class sub-code provides a broad classification of the status. + The enumerated values the class are defined as: + + 2.X.X Success + + Success specifies that the DSN is reporting a positive delivery + action. Detail sub-codes may provide notification of + transformations required for delivery. + + 4.X.X Persistent Transient Failure + + A persistent transient failure is one in which the message as + sent is valid, but some temporary event prevents the successful + sending of the message. Sending in the future may be successful. + + 5.X.X Permanent Failure + + A permanent failure is one which is not likely to be resolved by + resending the message in the current form. Some change to the + message or the destination must be made for successful delivery. + + A client must recognize and report class sub-code even where + subsequent subject sub-codes are unrecognized. + + The subject sub-code classifies the status. This value applies to + each of the three classifications. The subject sub-code, if + recognized, must be reported even if the additional detail provided + by the detail sub-code is not recognized. The enumerated values for + the subject sub-code are: + + X.0.X Other or Undefined Status + + There is no additional subject information available. + + X.1.X Addressing Status + + The address status reports on the originator or destination + address. It may include address syntax or validity. These + errors can generally be corrected by the sender and retried. + + X.2.X Mailbox Status + + Mailbox status indicates that something having to do with the + mailbox has cause this DSN. Mailbox issues are assumed to be + under the general control of the recipient. + + + + + + +Vaudreuil Standards Track [Page 3] + +RFC 1893 Mail System Status Codes January 1996 + + + X.3.X Mail System Status + + Mail system status indicates that something having to do + with the destination system has caused this DSN. System + issues are assumed to be under the general control of the + destination system administrator. + + X.4.X Network and Routing Status + + The networking or routing codes report status about the + delivery system itself. These system components include any + necessary infrastructure such as directory and routing + services. Network issues are assumed to be under the + control of the destination or intermediate system + administrator. + + X.5.X Mail Delivery Protocol Status + + The mail delivery protocol status codes report failures + involving the message delivery protocol. These failures + include the full range of problems resulting from + implementation errors or an unreliable connection. Mail + delivery protocol issues may be controlled by many parties + including the originating system, destination system, or + intermediate system administrators. + + X.6.X Message Content or Media Status + + The message content or media status codes report failures + involving the content of the message. These codes report + failures due to translation, transcoding, or otherwise + unsupported message media. Message content or media issues + are under the control of both the sender and the receiver, + both of whom must support a common set of supported + content-types. + + X.7.X Security or Policy Status + + The security or policy status codes report failures + involving policies such as per-recipient or per-host + filtering and cryptographic operations. Security and policy + status issues are assumed to be under the control of either + or both the sender and recipient. Both the sender and + recipient must permit the exchange of messages and arrange + the exchange of necessary keys and certificates for + cryptographic operations. + + + + + +Vaudreuil Standards Track [Page 4] + +RFC 1893 Mail System Status Codes January 1996 + + +3. Enumerated Status Codes + + The following section defines and describes the detail sub-code. The + detail value provides more information about the status and is + defined relative to the subject of the status. + + 3.1 Other or Undefined Status + + X.0.0 Other undefined Status + + Other undefined status is the only undefined error code. It + should be used for all errors for which only the class of the + error is known. + + 3.2 Address Status + + X.1.0 Other address status + + Something about the address specified in the message caused + this DSN. + + X.1.1 Bad destination mailbox address + + The mailbox specified in the address does not exist. For + Internet mail names, this means the address portion to the + left of the "@" sign is invalid. This code is only useful + for permanent failures. + + X.1.2 Bad destination system address + + The destination system specified in the address does not + exist or is incapable of accepting mail. For Internet mail + names, this means the address portion to the right of the + "@" is invalid for mail. This codes is only useful for + permanent failures. + + X.1.3 Bad destination mailbox address syntax + + The destination address was syntactically invalid. This can + apply to any field in the address. This code is only useful + for permanent failures. + + X.1.4 Destination mailbox address ambiguous + + The mailbox address as specified matches one or more + recipients on the destination system. This may result if a + heuristic address mapping algorithm is used to map the + specified address to a local mailbox name. + + + +Vaudreuil Standards Track [Page 5] + +RFC 1893 Mail System Status Codes January 1996 + + + X.1.5 Destination address valid + + This mailbox address as specified was valid. This status + code should be used for positive delivery reports. + + X.1.6 Destination mailbox has moved, No forwarding address + + The mailbox address provided was at one time valid, but mail + is no longer being accepted for that address. This code is + only useful for permanent failures. + + X.1.7 Bad sender's mailbox address syntax + + The sender's address was syntactically invalid. This can + apply to any field in the address. + + X.1.8 Bad sender's system address + + The sender's system specified in the address does not exist + or is incapable of accepting return mail. For domain names, + this means the address portion to the right of the "@" is + invalid for mail. + + 3.3 Mailbox Status + + X.2.0 Other or undefined mailbox status + + The mailbox exists, but something about the destination + mailbox has caused the sending of this DSN. + + X.2.1 Mailbox disabled, not accepting messages + + The mailbox exists, but is not accepting messages. This may + be a permanent error if the mailbox will never be re-enabled + or a transient error if the mailbox is only temporarily + disabled. + + X.2.2 Mailbox full + + The mailbox is full because the user has exceeded a + per-mailbox administrative quota or physical capacity. The + general semantics implies that the recipient can delete + messages to make more space available. This code should be + used as a persistent transient failure. + + + + + + + +Vaudreuil Standards Track [Page 6] + +RFC 1893 Mail System Status Codes January 1996 + + + X.2.3 Message length exceeds administrative limit + + A per-mailbox administrative message length limit has been + exceeded. This status code should be used when the + per-mailbox message length limit is less than the general + system limit. This code should be used as a permanent + failure. + + X.2.4 Mailing list expansion problem + + The mailbox is a mailing list address and the mailing list + was unable to be expanded. This code may represent a + permanent failure or a persistent transient failure. + + 3.4 Mail system status + + X.3.0 Other or undefined mail system status + + The destination system exists and normally accepts mail, but + something about the system has caused the generation of this + DSN. + + X.3.1 Mail system full + + Mail system storage has been exceeded. The general + semantics imply that the individual recipient may not be + able to delete material to make room for additional + messages. This is useful only as a persistent transient + error. + + X.3.2 System not accepting network messages + + The host on which the mailbox is resident is not accepting + messages. Examples of such conditions include an immanent + shutdown, excessive load, or system maintenance. This is + useful for both permanent and permanent transient errors. + + X.3.3 System not capable of selected features + + Selected features specified for the message are not + supported by the destination system. This can occur in + gateways when features from one domain cannot be mapped onto + the supported feature in another. + + + + + + + + +Vaudreuil Standards Track [Page 7] + +RFC 1893 Mail System Status Codes January 1996 + + + X.3.4 Message too big for system + + The message is larger than per-message size limit. This + limit may either be for physical or administrative reasons. + This is useful only as a permanent error. + + X.3.5 System incorrectly configured + + The system is not configured in a manner which will permit + it to accept this message. + + 3.5 Network and Routing Status + + X.4.0 Other or undefined network or routing status + + Something went wrong with the networking, but it is not + clear what the problem is, or the problem cannot be well + expressed with any of the other provided detail codes. + + X.4.1 No answer from host + + The outbound connection attempt was not answered, either + because the remote system was busy, or otherwise unable to + take a call. This is useful only as a persistent transient + error. + + X.4.2 Bad connection + + The outbound connection was established, but was otherwise + unable to complete the message transaction, either because + of time-out, or inadequate connection quality. This is + useful only as a persistent transient error. + + X.4.3 Directory server failure + + The network system was unable to forward the message, + because a directory server was unavailable. This is useful + only as a persistent transient error. + + The inability to connect to an Internet DNS server is one + example of the directory server failure error. + + X.4.4 Unable to route + + The mail system was unable to determine the next hop for the + message because the necessary routing information was + unavailable from the directory server. This is useful for + both permanent and persistent transient errors. + + + +Vaudreuil Standards Track [Page 8] + +RFC 1893 Mail System Status Codes January 1996 + + + A DNS lookup returning only an SOA (Start of Administration) + record for a domain name is one example of the unable to + route error. + + X.4.5 Mail system congestion + + The mail system was unable to deliver the message because + the mail system was congested. This is useful only as a + persistent transient error. + + X.4.6 Routing loop detected + + A routing loop caused the message to be forwarded too many + times, either because of incorrect routing tables or a user + forwarding loop. This is useful only as a persistent + transient error. + + X.4.7 Delivery time expired + + The message was considered too old by the rejecting system, + either because it remained on that host too long or because + the time-to-live value specified by the sender of the + message was exceeded. If possible, the code for the actual + problem found when delivery was attempted should be returned + rather than this code. This is useful only as a persistent + transient error. + + 3.6 Mail Delivery Protocol Status + + X.5.0 Other or undefined protocol status + + Something was wrong with the protocol necessary to deliver + the message to the next hop and the problem cannot be well + expressed with any of the other provided detail codes. + + X.5.1 Invalid command + + A mail transaction protocol command was issued which was + either out of sequence or unsupported. This is useful only + as a permanent error. + + X.5.2 Syntax error + + A mail transaction protocol command was issued which could + not be interpreted, either because the syntax was wrong or + the command is unrecognized. This is useful only as a + permanent error. + + + + +Vaudreuil Standards Track [Page 9] + +RFC 1893 Mail System Status Codes January 1996 + + + X.5.3 Too many recipients + + More recipients were specified for the message than could + have been delivered by the protocol. This error should + normally result in the segmentation of the message into two, + the remainder of the recipients to be delivered on a + subsequent delivery attempt. It is included in this list in + the event that such segmentation is not possible. + + X.5.4 Invalid command arguments + + A valid mail transaction protocol command was issued with + invalid arguments, either because the arguments were out of + range or represented unrecognized features. This is useful + only as a permanent error. + + X.5.5 Wrong protocol version + + A protocol version mis-match existed which could not be + automatically resolved by the communicating parties. + + 3.7 Message Content or Message Media Status + + X.6.0 Other or undefined media error + + Something about the content of a message caused it to be + considered undeliverable and the problem cannot be well + expressed with any of the other provided detail codes. + + X.6.1 Media not supported + + The media of the message is not supported by either the + delivery protocol or the next system in the forwarding path. + This is useful only as a permanent error. + + X.6.2 Conversion required and prohibited + + The content of the message must be converted before it can + be delivered and such conversion is not permitted. Such + prohibitions may be the expression of the sender in the + message itself or the policy of the sending host. + + X.6.3 Conversion required but not supported + + The message content must be converted to be forwarded but + such conversion is not possible or is not practical by a + host in the forwarding path. This condition may result when + an ESMTP gateway supports 8bit transport but is not able to + + + +Vaudreuil Standards Track [Page 10] + +RFC 1893 Mail System Status Codes January 1996 + + + downgrade the message to 7 bit as required for the next hop. + + X.6.4 Conversion with loss performed + + This is a warning sent to the sender when message delivery + was successfully but when the delivery required a conversion + in which some data was lost. This may also be a permanant + error if the sender has indicated that conversion with loss + is prohibited for the message. + + X.6.5 Conversion Failed + + A conversion was required but was unsuccessful. This may be + useful as a permanent or persistent temporary notification. + + 3.8 Security or Policy Status + + X.7.0 Other or undefined security status + + Something related to security caused the message to be + returned, and the problem cannot be well expressed with any + of the other provided detail codes. This status code may + also be used when the condition cannot be further described + because of security policies in force. + + X.7.1 Delivery not authorized, message refused + + The sender is not authorized to send to the destination. + This can be the result of per-host or per-recipient + filtering. This memo does not discuss the merits of any + such filtering, but provides a mechanism to report such. + This is useful only as a permanent error. + + X.7.2 Mailing list expansion prohibited + + The sender is not authorized to send a message to the + intended mailing list. This is useful only as a permanent + error. + + X.7.3 Security conversion required but not possible + + A conversion from one secure messaging protocol to another + was required for delivery and such conversion was not + possible. This is useful only as a permanent error. + + + + + + + +Vaudreuil Standards Track [Page 11] + +RFC 1893 Mail System Status Codes January 1996 + + + X.7.4 Security features not supported + + A message contained security features such as secure + authentication which could not be supported on the delivery + protocol. This is useful only as a permanent error. + + X.7.5 Cryptographic failure + + A transport system otherwise authorized to validate or + decrypt a message in transport was unable to do so because + necessary information such as key was not available or such + information was invalid. + + X.7.6 Cryptographic algorithm not supported + + A transport system otherwise authorized to validate or + decrypt a message was unable to do so because the necessary + algorithm was not supported. + + X.7.7 Message integrity failure + + A transport system otherwise authorized to validate a + message was unable to do so because the message was + corrupted or altered. This may be useful as a permanent, + transient persistent, or successful delivery code. + +4. References + + [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + + [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for + Delivery Status Notifications", RFC 1894, University of + Tennessee, Octel Network Services, January 1996. + +5. Security Considerations + + This document describes a status code system with increased + precision. Use of these status codes may disclose additional + information about how an internal mail system is implemented beyond + that currently available. + +6. Acknowledgments + + The author wishes to offer special thanks to Harald Alvestrand, Marko + Kaittola, and Keith Moore for their extensive review and constructive + suggestions. + + + + +Vaudreuil Standards Track [Page 12] + +RFC 1893 Mail System Status Codes January 1996 + + +7. Author's Address + + Gregory M. Vaudreuil + Octel Network Services + 17060 Dallas Parkway + Suite 214 + Dallas, TX 75248-1905 + + Voice/Fax: +1-214-733-2722 + EMail: Greg.Vaudreuil@Octel.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vaudreuil Standards Track [Page 13] + +RFC 1893 Mail System Status Codes January 1996 + + +8. Appendix - Collected Status Codes + + X.1.0 Other address status + X.1.1 Bad destination mailbox address + X.1.2 Bad destination system address + X.1.3 Bad destination mailbox address syntax + X.1.4 Destination mailbox address ambiguous + X.1.5 Destination mailbox address valid + X.1.6 Mailbox has moved + X.1.7 Bad sender's mailbox address syntax + X.1.8 Bad sender's system address + + X.2.0 Other or undefined mailbox status + X.2.1 Mailbox disabled, not accepting messages + X.2.2 Mailbox full + X.2.3 Message length exceeds administrative limit. + X.2.4 Mailing list expansion problem + + X.3.0 Other or undefined mail system status + X.3.1 Mail system full + X.3.2 System not accepting network messages + X.3.3 System not capable of selected features + X.3.4 Message too big for system + + X.4.0 Other or undefined network or routing status + X.4.1 No answer from host + X.4.2 Bad connection + X.4.3 Routing server failure + X.4.4 Unable to route + X.4.5 Network congestion + X.4.6 Routing loop detected + X.4.7 Delivery time expired + + X.5.0 Other or undefined protocol status + X.5.1 Invalid command + X.5.2 Syntax error + X.5.3 Too many recipients + X.5.4 Invalid command arguments + X.5.5 Wrong protocol version + + X.6.0 Other or undefined media error + X.6.1 Media not supported + X.6.2 Conversion required and prohibited + X.6.3 Conversion required but not supported + X.6.4 Conversion with loss performed + X.6.5 Conversion failed + + + + + +Vaudreuil Standards Track [Page 14] + +RFC 1893 Mail System Status Codes January 1996 + + + X.7.0 Other or undefined security status + X.7.1 Delivery not authorized, message refused + X.7.2 Mailing list expansion prohibited + X.7.3 Security conversion required but not possible + X.7.4 Security features not supported + X.7.5 Cryptographic failure + X.7.6 Cryptographic algorithm not supported + X.7.7 Message integrity failure + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vaudreuil Standards Track [Page 15] + diff --git a/RFC/rfc1894.txt b/RFC/rfc1894.txt new file mode 100644 index 00000000..f1fc90d4 --- /dev/null +++ b/RFC/rfc1894.txt @@ -0,0 +1,2187 @@ + + + + + + +Network Working Group K. Moore +Request for Comments: 1894 University of Tennessee +Category: Standards Track G. Vaudreuil + Octel Network Services + January 1996 + + + An Extensible Message Format for Delivery Status Notifications + +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 + + This memo defines a MIME content-type that may be used by a message + transfer agent (MTA) or electronic mail gateway to report the result + of an attempt to deliver a message to one or more recipients. This + content-type is intended as a machine-processable replacement for the + various types of delivery status notifications currently used in + Internet electronic mail. + + Because many messages are sent between the Internet and other + messaging systems (such as X.400 or the so-called "LAN-based" + systems), the DSN protocol is designed to be useful in a multi- + protocol messaging environment. To this end, the protocol described + in this memo provides for the carriage of "foreign" addresses and + error codes, in addition to those normally used in Internet mail. + Additional attributes may also be defined to support "tunneling" of + foreign notifications through Internet mail. + + Any questions, comments, and reports of defects or ambiguities in + this specification may be sent to the mailing list for the NOTARY + working group of the IETF, using the address + . Requests to subscribe to the mailing + list should be addressed to . + Implementors of this specification are encouraged to subscribe to the + mailing list, so that they will quickly be informed of any problems + which might hinder interoperability. + + NOTE: This document is a Proposed Standard. If and when this + protocol is submitted for Draft Standard status, any normative text + (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in + this document will be re-evaluated in light of implementation + + + +Moore & Vaudreuil Standards Track [Page 1] + +RFC 1894 Delivery Status Notifications January 1996 + + + experience, and are thus subject to change. + +1. Introduction + + This memo defines a MIME [1] content-type for delivery status + notifications (DSNs). A DSN can be used to notify the sender of a + message of any of several conditions: failed delivery, delayed + delivery, successful delivery, or the gatewaying of a message into an + environment that may not support DSNs. The "message/delivery-status" + content-type defined herein is intended for use within the framework + of the "multipart/report" content type defined in [2]. + + This memo defines only the format of the notifications. An extension + to the Simple Message Transfer Protocol (SMTP) [3] to fully support + such notifications is the subject of a separate memo [4]. + +1.1 Purposes + + The DSNs defined in this memo are expected to serve several purposes: + +(a) Inform human beings of the status of message delivery processing, as + well as the reasons for any delivery problems or outright failures, + in a manner which is largely independent of human language; + +(b) Allow mail user agents to keep track of the delivery status of + messages sent, by associating returned DSNs with earlier message + transmissions; + +(c) Allow mailing list exploders to automatically maintain their + subscriber lists when delivery attempts repeatedly fail; + +(d) Convey delivery and non-delivery notifications resulting from + attempts to deliver messages to "foreign" mail systems via a + gateway; + +(e) Allow "foreign" notifications to be tunneled through a MIME-capable + message system and back into the original messaging system that + issued the original notification, or even to a third messaging + system; + +(f) Allow language-independent, yet reasonably precise, indications of + the reason for the failure of a message to be delivered (once status + codes of sufficient precision are defined); and + +(g) Provide sufficient information to remote MTA maintainers (via + "trouble tickets") so that they can understand the nature of + reported errors. This feature is used in the case that failure to + deliver a message is due to the malfunction of a remote MTA and the + + + +Moore & Vaudreuil Standards Track [Page 2] + +RFC 1894 Delivery Status Notifications January 1996 + + + sender wants to report the problem to the remote MTA administrator. + +1.2 Requirements + + These purposes place the following constraints on the notification + protocol: + +(a) It must be readable by humans as well as being machine-parsable. + +(b) It must provide enough information to allow message senders (or the + user agents) to unambiguously associate a DSN with the message that + was sent and the original recipient address for which the DSN is + issued (if such information is available), even if the message was + forwarded to another recipient address. + +(c) It must be able to preserve the reason for the success or failure of + a delivery attempt in a remote messaging system, using the + "language" (mailbox addresses and status codes) of that remote + system. + +(d) It must also be able to describe the reason for the success or + failure of a delivery attempt, independent of any particular human + language or of the "language" of any particular mail system. + +(e) It must preserve enough information to allow the maintainer of a + remote MTA to understand (and if possible, reproduce) the conditions + that caused a delivery failure at that MTA. + +(f) For any notifications issued by foreign mail systems, which are + translated by a mail gateway to the DSN format, the DSN must + preserve the "type" of the foreign addresses and error codes, so + that these may be correctly interpreted by gateways. + + A DSN contains a set of per-message fields which identify the message + and the transaction during which the message was submitted, along + with other fields that apply to all delivery attempts described by + the DSN. The DSN also includes a set of per-recipient fields to + convey the result of the attempt to deliver the message to each of + one or more recipients. + +1.3 Terminology + + A message may be transmitted through several message transfer agents + (MTAs) on its way to a recipient. For a variety of reasons, + recipient addresses may be rewritten during this process, so each MTA + may potentially see a different recipient address. Depending on the + purpose for which a DSN is used, different formats of a particular + recipient address will be needed. + + + +Moore & Vaudreuil Standards Track [Page 3] + +RFC 1894 Delivery Status Notifications January 1996 + + + Several DSN fields are defined in terms of the view from a particular + MTA in the transmission. The MTAs are assigned the following names: + + (a) Original MTA + + The Original MTA is the one to which the message is submitted for + delivery by the sender of the message. + + (b) Reporting MTA + + For any DSN, the Reporting MTA is the one which is reporting the + results of delivery attempts described in the DSN. + + If the delivery attempts described occurred in a "foreign" (non- + Internet) mail system, and the DSN was produced by translating the + foreign notice into DSN format, the Reporting MTA will still identify + the "foreign" MTA where the delivery attempts occurred. + + (c) Received-From MTA + + The Received-From MTA is the MTA from which the Reporting MTA + received the message, and accepted responsibility for delivery of the + message. + + (d) Remote MTA + + If an MTA determines that it must relay a message to one or more + recipients, but the message cannot be transferred to its "next hop" + MTA, or if the "next hop" MTA refuses to accept responsibility for + delivery of the message to one or more of its intended recipients, + the relaying MTA may need to issue a DSN on behalf of the recipients + for whom the message cannot be delivered. In this case the relaying + MTA is the Reporting MTA, and the "next hop" MTA is known as the + Remote MTA. + + + + + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 4] + +RFC 1894 Delivery Status Notifications January 1996 + + +Figure 1 illustrates the relationship between the various MTAs. + + ++-----+ +--------+ +---------+ +---------+ +------+ +| | | | |Received-| | | | | +| | => |Original| => ... => | From | => |Reporting| ===> |Remote| +| user| | MTA | | MTA | | MTA | ". + + A particular DSN describes the delivery status for exactly one + message. However, an MTA MAY report on the delivery status for + several recipients of the same message in a single DSN. Due to the + nature of the mail transport system (where responsibility for + delivery of a message to its recipients may be split among several + MTAs, and delivery to any particular recipient may be delayed), + multiple DSNs may be still be issued in response to a single message + submission. + + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 7] + +RFC 1894 Delivery Status Notifications January 1996 + + +2.1 The message/delivery-status content-type + + The message/delivery-status content-type is defined as follows: + + MIME type name: message + MIME subtype name: delivery-status + Optional parameters: none + Encoding considerations: "7bit" encoding is sufficient and + MUST be used to maintain readability + when viewed by non-MIME mail + readers. + Security considerations: discussed in section 4 of this memo. + + The message/delivery-status report type for use in the + multipart/report is "delivery-status". + + The body of a message/delivery-status consists of one or more + "fields" formatted according to the ABNF of RFC 822 header "fields" + (see [6]). The per-message fields appear first, followed by a blank + line. Following the per-message fields are one or more groups of + per-recipient fields. Each group of per-recipient fields is preceded + by a blank line. Using the ABNF of RFC 822, the syntax of the + message/delivery-status content is as follows: + + delivery-status-content = + per-message-fields 1*( CRLF per-recipient-fields ) + + The per-message fields are described in section 2.2. The per- + recipient fields are described in section 2.3. + + +2.1.1 General conventions for DSN fields + + Since these fields are defined according to the rules of RFC 822, the + same conventions for continuation lines and comments apply. + Notification fields may be continued onto multiple lines by beginning + each additional line with a SPACE or HTAB. Text which appears in + parentheses is considered a comment and not part of the contents of + that notification field. Field names are case-insensitive, so the + names of notification fields may be spelled in any combination of + upper and lower case letters. Comments in DSN fields may use the + "encoded-word" construct defined in [7]. + + A number of DSN fields are defined to have a portion of a field body + of "xtext". "xtext" is used to allow encoding sequences of octets + which contain values outside the range [1-127 decimal] of traditional + ASCII characters, and also to allow comments to be inserted in the + data. Any octet may be encoded as "+" followed by two upper case + + + +Moore & Vaudreuil Standards Track [Page 8] + +RFC 1894 Delivery Status Notifications January 1996 + + + hexadecimal digits. (The "+" character MUST be encoded as "+2B".) + With certain exceptions, octets that correspond to ASCII characters + may be represented as themselves. SPACE and HTAB characters are + ignored. Comments may be included by enclosing them in parenthesis. + Except within comments, encoded-words such as defined in [7] may NOT + be used in xtext. + + "xtext" is formally defined as follows: + + xtext = *( xchar / hexchar / linear-white-space / comment ) + + xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, + except for "+", "\" and "(". + + "hexchar"s are intended to encode octets that cannot be represented + as plain text, either because they are reserved, or because they are + non-printable. However, any octet value may be represented by a + "hexchar". + + hexchar = ASCII "+" immediately followed by two upper case + hexadecimal digits + + When encoding an octet sequence as xtext: + + + Any ASCII CHAR between "!" and "~" inclusive, except for "+", "\", + and "(", MAY be encoded as itself. (Some CHARs in this range may + also be encoded as "hexchar"s, at the implementor's discretion.) + + + ASCII CHARs that fall outside the range above must be encoded as + "hexchar". + + + Line breaks (CR LF SPACE) MAY be inserted as necessary to keep line + lengths from becoming excessive. + + + Comments MAY be added to clarify the meaning for human readers. + +2.1.2 "*-type" subfields + + Several DSN fields consist of a "-type" subfield, followed by a + semicolon, followed by "*text". For these fields, the keyword used + in the address-type, diagnostic-type, or MTA-name-type subfield + indicates the expected format of the address, status-code, or MTA- + name which follows. + + + + + + + + +Moore & Vaudreuil Standards Track [Page 9] + +RFC 1894 Delivery Status Notifications January 1996 + + + The "-type" subfields are defined as follows: + +(a) An "address-type" specifies the format of a mailbox address. For + example, Internet mail addresses use the "rfc822" address-type. + + address-type = atom + +(b) A "diagnostic-type" specifies the format of a status code. For + example, when a DSN field contains a reply code reported via the + Simple Mail Transfer Protocol [3], the "smtp" diagnostic-type is + used. + + diagnostic-type = atom + +(c) An "MTA-name-type" specifies the format of an MTA name. For + example, for an SMTP server on an Internet host, the MTA name is the + domain name of that host, and the "dns" MTA-name-type is used. + + mta-name-type = atom + + Values for address-type, diagnostic-type, and MTA-name-type are + case-insensitive. Thus address-type values of "RFC822" and "rfc822" + are equivalent. + + The Internet Assigned Numbers Authority (IANA) will maintain a + registry of address-types, diagnostic-types, and MTA-name-types, + along with descriptions of the meanings and acceptable values of + each, or a reference to a one or more specifications that provide + such descriptions. (The "rfc822" address-type, "smtp" diagnostic- + type, and "dns" MTA-name-type are defined in [4].) Registration + forms for address-type, diagnostic-type, and MTA-name-type appear in + section 8 of this document. + + IANA will not accept registrations for any address-type, diagnostic- + type, or MTA-name-type name that begins with "X-". These type names + are reserved for experimental use. + +2.1.3 Lexical tokens imported from RFC 822 + + The following lexical tokens, defined in [6], are used in the ABNF + grammar for DSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear- + white-space, SPACE, text. The date-time lexical token is defined in + [8]. + + + + + + + + +Moore & Vaudreuil Standards Track [Page 10] + +RFC 1894 Delivery Status Notifications January 1996 + + +2.2 Per-Message DSN Fields + + Some fields of a DSN apply to all of the delivery attempts described + by that DSN. These fields may appear at most once in any DSN. These + fields are used to correlate the DSN with the original message + transaction and to provide additional information which may be useful + to gateways. + + per-message-fields = + [ original-envelope-id-field CRLF ] + reporting-mta-field CRLF + [ dsn-gateway-field CRLF ] + [ received-from-mta-field CRLF ] + [ arrival-date-field CRLF ] + *( extension-field CRLF ) + +2.2.1 The Original-Envelope-Id field + + The optional Original-Envelope-Id field contains an "envelope + identifier" which uniquely identifies the transaction during which + the message was submitted, and was either (a) specified by the sender + and supplied to the sender's MTA, or (b) generated by the sender's + MTA and made available to the sender when the message was submitted. + Its purpose is to allow the sender (or her user agent) to associate + the returned DSN with the specific transaction in which the message + was sent. + + If such an envelope identifier was present in the envelope which + accompanied the message when it arrived at the Reporting MTA, it + SHOULD be supplied in the Original-Envelope-Id field of any DSNs + issued as a result of an attempt to deliver the message. Except when + a DSN is issued by the sender's MTA, an MTA MUST NOT supply this + field unless there is an envelope-identifier field in the envelope + which accompanied this message on its arrival at the Reporting MTA. + + The Original-Envelope-Id field is defined as follows: + + original-envelope-id-field = + "Original-Envelope-Id" ":" envelope-id + + envelope-id = *text + + There may be at most one Original-Envelope-Id field per DSN. + + The envelope-id is CASE-SENSITIVE. The DSN MUST preserve the + original case and spelling of the envelope-id. + + + + + +Moore & Vaudreuil Standards Track [Page 11] + +RFC 1894 Delivery Status Notifications January 1996 + + + NOTE: The Original-Envelope-Id is NOT the same as the Message-Id from + the message header. The Message-Id identifies the content of the + message, while the Original-Envelope-Id identifies the transaction in + which the message is sent. + +2.2.2 The Reporting-MTA DSN field + + reporting-mta-field = + "Reporting-MTA" ":" mta-name-type ";" mta-name + + mta-name = *text + + The Reporting-MTA field is defined as follows: + + A DSN describes the results of attempts to deliver, relay, or gateway + a message to one or more recipients. In all cases, the Reporting-MTA + is the MTA which attempted to perform the delivery, relay, or gateway + operation described in the DSN. This field is required. + + Note that if an SMTP client attempts to relay a message to an SMTP + server and receives an error reply to a RCPT command, the client is + responsible for generating the DSN, and the client's domain name will + appear in the Reporting-MTA field. (The server's domain name will + appear in the Remote-MTA field.) + + Note that the Reporting-MTA is not necessarily the MTA which actually + issued the DSN. For example, if an attempt to deliver a message + outside of the Internet resulted in a nondelivery notification which + was gatewayed back into Internet mail, the Reporting-MTA field of the + resulting DSN would be that of the MTA that originally reported the + delivery failure, not that of the gateway which converted the foreign + notification into a DSN. See Figure 2. + + + + + + + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 12] + +RFC 1894 Delivery Status Notifications January 1996 + + +sender's environment recipient's environment +............................ .......................................... + : : + (1) : : (2) + +-----+ +--------+ +--------+ +---------+ +---------+ +------+ + | | | | | | |Received-| | | | | + | |=>|Original|=>| |->| From |->|Reporting|-->|Remote| + | user| | MTA | | | | MTA | | MTA |") (so that no DSNs would be sent from a downstream + MTA to the original sender), + +(e) for messages forwarded to a confidential address, disabling delivery + notifications for the forwarded message (e.g. if the "next-hop" MTA + uses ESMTP and supports the DSN extension, by using the NOTIFY=NEVER + parameter to the RCPT command), or + +(f) when forwarding mail to a confidential address, having the + forwarding MTA rewrite the envelope return address for the forwarded + message and attempt delivery of that message as if the forwarding + MTA were the originator. On its receipt of final delivery status, + the forwarding MTA would issue a DSN to the original sender. + + In general, any optional DSN field may be omitted if the Reporting + MTA site determines that inclusion of the field would impose too + great a compromise of site confidentiality. The need for such + confidentiality must be balanced against the utility of the omitted + information in trouble reports and DSNs gatewayed to foreign + environments. + + Implementors are cautioned that many existing MTAs will send + nondelivery notifications to a return address in the message header + (rather than to the one in the envelope), in violation of SMTP and + other protocols. If a message is forwarded through such an MTA, no + reasonable action on the part of the forwarding MTA will prevent the + downstream MTA from compromising the forwarding address. Likewise, + if the recipient's MTA automatically responds to messages based on a + request in the message header (such as the nonstandard, but widely + used, Return-Receipt-To extension header), it will also compromise + the forwarding address. + +4.3 Non-Repudiation + + Within the framework of today's internet mail, the DSNs defined in + this memo provide valuable information to the mail user; however, + even a "failed" DSN can not be relied upon as a guarantee that a + message was not received by the recipient. Even if DSNs are not + actively forged, conditions exist under which a message can be + delivered despite the fact that a failure DSN was issued. + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 24] + +RFC 1894 Delivery Status Notifications January 1996 + + + For example, a race condition in the SMTP protocol allows for the + duplication of messages if the connection is dropped following a + completed DATA command, but before a response is seen by the SMTP + client. This will cause the SMTP client to retransmit the message, + even though the SMTP server has already accepted it.[9] If one of + those delivery attempts succeeds and the other one fails, a "failed" + DSN could be issued even though the message actually reached the + recipient. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 25] + +RFC 1894 Delivery Status Notifications January 1996 + + +5. Appendix - collected grammar + + NOTE: The following lexical tokens are defined in RFC 822: atom, + CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text. + The date-time lexical token is defined in [8]. + +action-field = "Action" ":" action-value + +action-value = + "failed" / "delayed" / "delivered" / "relayed" / "expanded" + +address-type = atom + +arrival-date-field = "Arrival-Date" ":" date-time + +delivery-status-content = + per-message-fields 1*( CRLF per-recipient-fields ) + +diagnostic-code-field = + "Diagnostic-Code" ":" diagnostic-type ";" *text + +diagnostic-type = atom + +dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name + +envelope-id = *text + +extension-field = extension-field-name ":" *text + +extension-field-name = atom + +final-recipient-field = + "Final-Recipient" ":" address-type ";" generic-address + +generic-address = *text + +last-attempt-date-field = "Last-Attempt-Date" ":" date-time + +mta-name = *text + +mta-name-type = atom + +original-envelope-id-field = + "Original-Envelope-Id" ":" envelope-id + +original-recipient-field = + "Original-Recipient" ":" address-type ";" generic-address + + + + +Moore & Vaudreuil Standards Track [Page 26] + +RFC 1894 Delivery Status Notifications January 1996 + + +per-message-fields = + [ original-envelope-id-field CRLF ] + reporting-mta-field CRLF + [ dsn-gateway-field CRLF ] + [ received-from-mta-field CRLF ] + [ arrival-date-field CRLF ] + *( extension-field CRLF ) + +per-recipient-fields = + [ original-recipient-field CRLF ] + final-recipient-field CRLF + action-field CRLF + status-field CRLF + [ remote-mta-field CRLF ] + [ diagnostic-code-field CRLF ] + [ last-attempt-date-field CRLF ] + [ will-retry-until-field CRLF ] + *( extension-field CRLF ) + +received-from-mta-field = + "Received-From-MTA" ":" mta-name-type ";" mta-name + +remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name + +reporting-mta-field = + "Reporting-MTA" ":" mta-name-type ";" mta-name + +status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT + + ; White-space characters and comments are NOT allowed within a + ; status-code, though a comment enclosed in parentheses MAY follow + ; the last numeric subfield of the status-code. Each numeric + ; subfield within the status-code MUST be expressed without + ; leading zero digits. + +status-field = "Status" ":" status-code + +will-retry-until-field = "Will-Retry-Until" ":" date-time + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 27] + +RFC 1894 Delivery Status Notifications January 1996 + + +6. Appendix - Guidelines for gatewaying DSNs + + NOTE: This section provides non-binding recommendations for the + construction of mail gateways that wish to provide semi-transparent + delivery reports between the Internet and another electronic mail + system. Specific DSN gateway requirements for a particular pair of + mail systems may be defined by other documents. + +6.1 Gatewaying from other mail systems to DSNs + + A mail gateway may issue a DSN to convey the contents of a "foreign" + delivery or non-delivery notification over Internet mail. When there + are appropriate mappings from the foreign notification elements to + DSN fields, the information may be transmitted in those DSN fields. + Additional information (such as might be useful in a trouble ticket + or needed to tunnel the foreign notification through the Internet) + may be defined in extension DSN fields. (Such fields should be given + names that identify the foreign mail protocol, e.g. X400-* for X.400 + NDN or DN protocol elements) + + The gateway must attempt to supply reasonable values for the + Reporting-MTA, Final-Recipient, Action, and Status fields. These + will normally be obtained by translating the values from the remote + delivery or non-delivery notification into their Internet-style + equivalents. However, some loss of information is to be expected. + For example, the set of status-codes defined for DSNs may not be + adequate to fully convey the delivery diagnostic code from the + foreign system. The gateway should assign the most precise code + which describes the failure condition, falling back on "generic" + codes such as 2.0.0 (success), 4.0.0 (temporary failure), and 5.0.0 + (permanent failure) when necessary. The actual foreign diagnostic + code should be retained in the Diagnostic-Code field (with an + appropriate diagnostic-type value) for use in trouble tickets or + tunneling. + + The sender-specified recipient address, and the original envelope-id, + if present in the foreign transport envelope, should be preserved in + the Original-Recipient and Original-Envelope-ID fields. + + The gateway should also attempt to preserve the "final" recipient + addresses and MTA names from the foreign system. Whenever possible, + foreign protocol elements should be encoded as meaningful printable + ASCII strings. + + For DSNs produced from foreign delivery or nondelivery notifications, + the name of the gateway MUST appear in the DSN-Gateway field of the + DSN. + + + + +Moore & Vaudreuil Standards Track [Page 28] + +RFC 1894 Delivery Status Notifications January 1996 + + +6.2 Gatewaying from DSNs to other mail systems + + It may be possible to gateway DSNs from the Internet into a foreign + mail system. The primary purpose of such gatewaying is to convey + delivery status information in a form that is usable by the + destination system. A secondary purpose is to allow "tunneling" of + DSNs through foreign mail systems, in case the DSN may be gatewayed + back into the Internet. + + In general, the recipient of the DSN (i.e., the sender of the + original message) will want to know, for each recipient: the closest + available approximation to the original recipient address, the + delivery status (success, failure, or temporary failure), and for + failed deliveries, a diagnostic code that describes the reason for + the failure. + + If possible, the gateway should attempt to preserve the Original- + Recipient address and Original-Envelope-ID (if present), in the + resulting foreign delivery status report. + + When reporting delivery failures, if the diagnostic-type subfield of + the Diagnostic-Code field indicates that the original diagnostic code + is understood by the destination environment, the information from + the Diagnostic-Code field should be used. Failing that, the + information in the Status field should be mapped into the closest + available diagnostic code used in the destination environment. + + If it is possible to tunnel a DSN through the destination + environment, the gateway specification may define a means of + preserving the DSN information in the delivery status reports used by + that environment. + + + + + + + + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 29] + +RFC 1894 Delivery Status Notifications January 1996 + + +7. Appendix - Guidelines for use of DSNs by mailing list exploders + + NOTE: This section pertains only to the use of DSNs by "mailing + lists" as defined in [4], section 7.2.7. + + DSNs are designed to be used by mailing list exploders to allow them + to detect and automatically delete recipients for whom mail delivery + fails repeatedly. + + When forwarding a message to list subscribers, the mailing list + exploder should always set the envelope return address (e.g. SMTP + MAIL FROM address) to point to a special address which is set up to + received nondelivery reports. A "smart" mailing list exploder can + therefore intercept such nondelivery reports, and if they are in the + DSN format, automatically examine them to determine for which + recipients a message delivery failed or was delayed. + + The Original-Recipient field should be used if available, since it + should exactly match the subscriber address known to the list. If + the Original-Recipient field is not available, the recipient field + may resemble the list subscriber address. Often, however, the list + subscriber will have forwarded his mail to a different address, or + the address may be subject to some re-writing, so heuristics may be + required to successfully match an address from the recipient field. + Care is needed in this case to minimize the possibility of false + matches. + + The reason for delivery failure can be obtained from the Status and + Action fields, and from the Diagnostic-Code field (if the status-type + is recognized). Reports for recipients with action values other than + "failed" can generally be ignored; in particular, subscribers should + not be removed from a list due to "delayed" reports. + + In general, almost any failure status code (even a "permanent" one) + can result from a temporary condition. It is therefore recommended + that a list exploder not delete a subscriber based on any single + failure DSN (regardless of the status code), but only on the + persistence of delivery failure over a period of time. + + However, some kinds of failures are less likely than others to have + been caused by temporary conditions, and some kinds of failures are + more likely to be noticed and corrected quickly than others. Once + more precise status codes are defined, it may be useful to + differentiate between the status codes when deciding whether to + delete a subscriber. For example, on a list with a high message + volume, it might be desirable to temporarily suspend delivery to a + recipient address which causes repeated "temporary" failures, rather + than simply deleting the recipient. The duration of the suspension + + + +Moore & Vaudreuil Standards Track [Page 30] + +RFC 1894 Delivery Status Notifications January 1996 + + + might depend on the type of error. On the other hand, a "user + unknown" error which persisted for several days could be considered a + reliable indication that address were no longer valid. + +8. Appendix - IANA registration forms for DSN types + + The forms below are for use when registering a new address-type, + diagnostic-type, or MTA-name-type with the Internet Assigned Numbers + Authority (IANA). Each piece of information requested by a + registration form may be satisfied either by providing the + information on the form itself, or by including a reference to a + published, publicly available specification which includes the + necessary information. IANA MAY reject DSN type registrations + because of incomplete registration forms, imprecise specifications, + or inappropriate type names. + + To register a DSN type, complete the applicable form below and send + it via Internet electronic mail to . + +8.1 IANA registration form for address-type + + A registration for a DSN address-type MUST include the following + information: + +(a) The proposed address-type name. + +(b) The syntax for mailbox addresses of this type, specified using BNF, + regular expressions, ASN.1, or other non-ambiguous language. + +(c) If addresses of this type are not composed entirely of graphic + characters from the US-ASCII repertoire, a specification for how + they are to be encoded as graphic US-ASCII characters in a DSN + Original-Recipient or Final-Recipient DSN field. + +(d) [optional] A specification for how addresses of this type are to be + translated to and from Internet electronic mail addresses. + +8.2 IANA registration form for diagnostic-type + + A registration for a DSN address-type MUST include the following + information: + +(a) The proposed diagnostic-type name. + +(b) A description of the syntax to be used for expressing diagnostic + codes of this type as graphic characters from the US-ASCII + repertoire. + + + + +Moore & Vaudreuil Standards Track [Page 31] + +RFC 1894 Delivery Status Notifications January 1996 + + +(c) A list of valid diagnostic codes of this type and the meaning of + each code. + +(d) [optional] A specification for mapping from diagnostic codes of this + type to DSN status codes (as defined in [5]). + +8.3 IANA registration form for MTA-name-type + + A registration for a DSN MTA-name-type must include the following + information: + +(a) The proposed MTA-name-type name. + +(b) A description of the syntax of MTA names of this type, using BNF, + regular expressions, ASN.1, or other non-ambiguous language. + +(c) If MTA names of this type do not consist entirely of graphic + characters from the US-ASCII repertoire, a specification for how an + MTA name of this type should be expressed as a sequence of graphic + US-ASCII characters. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 32] + +RFC 1894 Delivery Status Notifications January 1996 + + +9. Appendix - Examples + + NOTE: These examples are provided as illustration only, and are not + considered part of the DSN protocol specification. If an example + conflicts with the protocol definition above, the example is wrong. + + Likewise, the use of *-type subfield names or extension fields in + these examples is not to be construed as a definition for those type + names or extension fields. + + These examples were manually translated from bounced messages using + whatever information was available. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 33] + +RFC 1894 Delivery Status Notifications January 1996 + + +9.1 This is a simple DSN issued after repeated attempts + to deliver a message failed. In this case, the DSN is + issued by the same MTA from which the message was originated. + + + Date: Thu, 7 Jul 1994 17:16:05 -0400 + From: Mail Delivery Subsystem + Message-Id: <199407072116.RAA14128@CS.UTK.EDU> + Subject: Returned mail: Cannot send message for 5 days + To: + MIME-Version: 1.0 + Content-Type: multipart/report; report-type=delivery-status; + boundary="RAA14128.773615765/CS.UTK.EDU" + + --RAA14128.773615765/CS.UTK.EDU + + The original message was received at Sat, 2 Jul 1994 17:10:28 -0400 + from root@localhost + + ----- The following addresses had delivery problems ----- + (unrecoverable error) + + ----- Transcript of session follows ----- + ... Deferred: Connection timed out + with larry.slip.umd.edu. + Message could not be delivered for 5 days + Message will be deleted from queue + + --RAA14128.773615765/CS.UTK.EDU + content-type: message/delivery-status + + Reporting-MTA: dns; cs.utk.edu + + Original-Recipient: rfc822;louisl@larry.slip.umd.edu + Final-Recipient: rfc822;louisl@larry.slip.umd.edu + Action: failed + Status: 4.0.0 + Diagnostic-Code: smtp; 426 connection timed out + Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400 + + --RAA14128.773615765/CS.UTK.EDU + content-type: message/rfc822 + + [original message goes here] + --RAA14128.773615765/CS.UTK.EDU-- + + + + + + +Moore & Vaudreuil Standards Track [Page 34] + +RFC 1894 Delivery Status Notifications January 1996 + + +9.2 This is another DSN issued by the sender's MTA, which + contains details of multiple delivery attempts. Some of + these were detected locally, and others by a remote MTA. + + + Date: Fri, 8 Jul 1994 09:21:47 -0400 + From: Mail Delivery Subsystem + Subject: Returned mail: User unknown + To: + MIME-Version: 1.0 + Content-Type: multipart/report; report-type=delivery-status; + boundary="JAA13167.773673707/CS.UTK.EDU" + + --JAA13167.773673707/CS.UTK.EDU + content-type: text/plain; charset=us-ascii + + ----- The following addresses had delivery problems ----- + (unrecoverable error) + (unrecoverable error) + + --JAA13167.773673707/CS.UTK.EDU + content-type: message/delivery-status + + Reporting-MTA: dns; cs.utk.edu + + Original-Recipient: rfc822;arathib@vnet.ibm.com + Final-Recipient: rfc822;arathib@vnet.ibm.com + Action: failed + Status: 5.0.0 (permanent failure) + Diagnostic-Code: smtp; + 550 'arathib@vnet.IBM.COM' is not a registered gateway user + Remote-MTA: dns; vnet.ibm.com + + Original-Recipient: rfc822;johnh@hpnjld.njd.hp.com + Final-Recipient: rfc822;johnh@hpnjld.njd.hp.com + Action: delayed + Status: 4.0.0 (hpnjld.njd.jp.com: host name lookup failure) + + Original-Recipient: rfc822;wsnell@sdcc13.ucsd.edu + Final-Recipient: rfc822;wsnell@sdcc13.ucsd.edu + Action: failed + Status: 5.0.0 + Diagnostic-Code: smtp; 550 user unknown + Remote-MTA: dns; sdcc13.ucsd.edu + + --JAA13167.773673707/CS.UTK.EDU + content-type: message/rfc822 + + + + +Moore & Vaudreuil Standards Track [Page 35] + +RFC 1894 Delivery Status Notifications January 1996 + + + [original message goes here] + --JAA13167.773673707/CS.UTK.EDU-- + + +9.3 A delivery report generated by Message Router (MAILBUS) and + gatewayed by PMDF_MR to a DSN. In this case the gateway did not + have sufficient information to supply an original-recipient address. + + + + Disclose-recipients: prohibited + Date: Fri, 08 Jul 1994 09:21:25 -0400 (EDT) + From: Message Router Submission Agent + Subject: Status of : Re: Battery current sense + To: owner-ups-mib@CS.UTK.EDU + Message-id: <01HEGJ0WNBY28Y95LN@mr.timeplex.com> + MIME-version: 1.0 + content-type: multipart/report; report-type=delivery-status; + boundary="84229080704991.122306.SYS30" + + --84229080704991.122306.SYS30 + content-type: text/plain + + Invalid address - nair_s + %DIR-E-NODIRMTCH, No matching Directory Entry found + + --84229080704991.122306.SYS30 + content-type: message/delivery-status + + Reporting-MTA: mailbus; SYS30 + + Final-Recipient: unknown; nair_s + Status: 5.0.0 (unknown permanent failure) + Action: failed + + --84229080704991.122306.SYS30-- + + + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 36] + +RFC 1894 Delivery Status Notifications January 1996 + + +9.4 A delay report from a multiprotocol MTA. Note that there is no + returned content, so no third body part appears in the DSN. + + From: + Message-Id: <199407092338.TAA23293@CS.UTK.EDU> + Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk + id ; + Sun, 10 Jul 1994 00:36:51 +0100 + To: owner-info-mime@cs.utk.edu + Date: Sun, 10 Jul 1994 00:36:51 +0100 + Subject: WARNING: message delayed at "nsfnet-relay.ac.uk" + content-type: multipart/report; report-type=delivery-status; + boundary=foobar + + --foobar + content-type: text/plain + + The following message: + + UA-ID: Reliable PC (... + Q-ID: sun2.nsf:77/msg.11820-0 + + has not been delivered to the intended recipient: + + thomas@de-montfort.ac.uk + + despite repeated delivery attempts over the past 24 hours. + + The usual cause of this problem is that the remote system is + temporarily unavailable. + + Delivery will continue to be attempted up to a total elapsed + time of 168 hours, ie 7 days. + + You will be informed if delivery proves to be impossible + within this time. + + Please quote the Q-ID in any queries regarding this mail. + + --foobar + content-type: message/delivery-status + + Reporting-MTA: dns; sun2.nsfnet-relay.ac.uk + + Final-Recipient: rfc822;thomas@de-montfort.ac.uk + Status: 4.0.0 (unknown temporary failure) + Action: delayed + + + + +Moore & Vaudreuil Standards Track [Page 37] + +RFC 1894 Delivery Status Notifications January 1996 + + + --foobar-- + +10. Acknowledgments + + The authors wish to thank the following people for their reviews of + earlier drafts of this document and their suggestions for + improvement: Eric Allman, Harald Alvestrand, Allan Cargille, Jim + Conklin, Peter Cowen, Dave Crocker, Roger Fajman, Ned Freed, Marko + Kaittola, Steve Kille, John Klensin, John Gardiner Myers, Mark + Nahabedian, Julian Onions, Jacob Palme, Jean Charles Roy, and Gregory + Sheehan. + +11. References + +[1] Borenstein, N., Freed, N. "Multipurpose Internet Mail Extensions", + RFC 1521, Bellcore, Innosoft, September 1993. + +[2] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting + of Mail System Administrative Messages", RFC 1892, Octal Network + Services, January 1996. + +[3] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + +[4] Moore, K., "SMTP Service Extension for Delivery Status + Notifications", RFC 1891, University of Tennessee, January 1996. + +[5] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, Octal + Network Services, January 1996. + +[6] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + +[7] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part Two: + Message Header Extensions for Non-Ascii Text", RFC 1522, University + of Tennessee, September 1993. + +[8] Braden, R. (ed.) "Requirements for Internet Hosts - Application and + Support", STD 3, RFC 1123, USC/Information Sciences Institute, + October 1989. + +[9] Partridge, C., "Duplicate Messages and SMTP", RFC 1047, BBN, + February 1988. + + + + + + + + +Moore & Vaudreuil Standards Track [Page 38] + +RFC 1894 Delivery Status Notifications January 1996 + + +11. Authors' Addresses + + Keith Moore + University of Tennessee + 107 Ayres Hall + Knoxville, TN 37996-1301 + USA + + EMail: moore@cs.utk.edu + Phone: +1 615 974 3126 + Fax: +1 615 974 8296 + + + Gregory M. Vaudreuil + Octel Network Services + 17080 Dallas Parkway + Dallas, TX 75248-1905 + USA + + EMail: Greg.Vaudreuil@Octel.Com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 39] + diff --git a/RFC/rfc1938.txt b/RFC/rfc1938.txt new file mode 100644 index 00000000..5d3a9002 --- /dev/null +++ b/RFC/rfc1938.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group N. Haller +Request for Comments: 1938 Bellcore +Category: Standards Track C. Metz + Kaman Sciences Corporation + May 1996 + + + A One-Time Password System + +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.0 ABSTRACT + + This document describes a one-time password authentication system + (OTP). The system provides authentication for system access (login) + and other applications requiring authentication that is secure + against passive attacks based on replaying captured reusable + passwords. OTP evolved from the S/KEY (S/KEY is a trademark of + Bellcore) One-Time Password System that was released by Bellcore and + is described in references [3] and [5]. + +2.0 OVERVIEW + + One form of attack on networked computing systems is eavesdropping on + network connections to obtain authentication information such as the + login IDs and passwords of legitimate users. Once this information is + captured, it can be used at a later time to gain access to the + system. One-time password systems are designed to counter this type + of attack, called a "replay attack" [4]. + + The authentication system described in this document uses a secret + pass-phrase to generate a sequence of one-time (single use) + passwords. With this system, the user's secret pass-phrase never + needs to cross the network at any time such as during authentication + or during pass-phrase changes. Thus, it is not vulnerable to replay + attacks. Added security is provided by the property that no secret + information need be stored on any system, including the server being + protected. + + The OTP system protects against external passive attacks against the + authentication subsystem. It does not prevent a network eavesdropper + from gaining access to private information and does not provide + + + +Haller & Metz Standards Track [Page 1] + +RFC 1938 A One-Time Password System May 1996 + + + protection against either "social engineering" or active attacks [9]. + +3.0 INTRODUCTION + + There are two entities in the operation of the OTP one-time password + system. The generator must produce the appropriate one-time password + from the user's secret pass-phrase and from information provided in + the challenge from the server. The server must send a challenge that + includes the appropriate generation parameters to the generator, must + verify the one-time password received, must store the last valid + one-time password it received, and must store the corresponding one- + time password sequence number. The server must also facilitate the + changing of the user's secret pass-phrase in a secure manner. + + The OTP system generator passes the user's secret pass-phrase, along + with a seed received from the server as part of the challenge, + through multiple iterations of a secure hash function to produce a + one-time password. After each successful authentication, the number + of secure hash function iterations is reduced by one. Thus, a unique + sequence of passwords is generated. The server verifies the one-time + password received from the generator by computing the secure hash + function once and comparing the result with the previously accepted + one-time password. This technique was first suggested by Leslie + Lamport [1]. + +4.0 REQUIREMENTS TERMINOLOGY + + In this document, the words that are used to define the significance + of each particular requirement are usually capitalized. These words + are: + + - MUST + + This word or the adjective "REQUIRED" means that the item is an + absolute requirement of the specification. + + - SHOULD + + This word or the adjective "RECOMMENDED" means that there might + exist valid reasons in particular circumstances to ignore this + item, but the full implications should be understood and the + case carefully weighed before taking a different course. + + - MAY + + This word or the adjective "OPTIONAL" means that this item is + truly optional. One vendor might choose to include the item + because a particular marketplace requires it or because it + + + +Haller & Metz Standards Track [Page 2] + +RFC 1938 A One-Time Password System May 1996 + + + enhances the product, for example; another vendor may omit the + same item. + +5.0 SECURE HASH FUNCTION + + The security of the OTP system is based on the non-invertability of a + secure hash function. Such a function must be tractable to compute in + the forward direction, but computationally infeasible to invert. + + The interfaces are currently defined for three such hash algorithms, + MD4 [2] and MD5 [6] by Ronald Rivest, and SHA [7] by NIST. All + conforming implementations of both server and generators MUST support + MD5. They SHOULD support SHA and MAY also support MD4. Clearly, the + generator and server must use the same algorithm in order to + interoperate. Other hash algorithms may be specified for use with + this system by publishing the appropriate interfaces. + + The secure hash algorithms listed above have the property that they + accept an input that is arbitrarily long and produce a fixed size + output. The OTP system folds this output to 64 bits using the + algorithms in the Appendix A. 64 bits is also the length of the one- + time passwords. This is believed to be long enough to be secure and + short enough to be entered manually (see below, Form of Output) when + necessary. + +6.0 GENERATION OF ONE-TIME PASSWORDS + + This section describes the generation of the one-time passwords. + This process consists of an initial step in which all inputs are + combined, a computation step where the secure hash function is + applied a specified number of times, and an output function where the + 64 bit one-time password is converted to a human readable form. + + Initial Step + + In principle, the user's secret pass-phrase may be of any length. + To reduce the risk from techniques such as exhaustive search or + dictionary attacks, character string pass-phrases MUST contain at + least 10 characters (see Form of Inputs below). All + implementations MUST support a pass-phrases of at least 63 + characters. The secret pass-phrase is frequently, but is not + required to be, textual information provided by a user. + + In this step, the pass phrase is concatenated with a seed that is + transmitted from the server in clear text. This non-secret seed + allows clients to use the same secret pass-phrase on multiple + machines (using different seeds) and to safely recycle their + secret pass-phrases by changing the seed. + + + +Haller & Metz Standards Track [Page 3] + +RFC 1938 A One-Time Password System May 1996 + + + The result of the concatenation is passed through the secure hash + function and then is reduced to 64 bits using one of the function + dependent algorithms shown in Appendix A. + + Computation Step + + A sequence of one-time passwords is produced by applying the + secure hash function multiple times to the output of the initial + step (called S). That is, the first one-time password to be used + is produced by passing S through the secure hash function a number + of times (N) specified by the user. The next one-time password to + be used is generated by passing S though the secure hash function + N-1 times. An eavesdropper who has monitored the transmission of a + one- time password would not be able to generate the next required + password because doing so would mean inverting the hash function. + + Form of Inputs + + The secret pass-phrase is seen only by the OTP generator. To allow + interchangeability of generators, all generators MUST support a + secret pass-phrase of 10 to 63 characters. Implementations MAY + support a longer pass-phrase, but such implementations risk the + loss of interchangeability with implementations supporting only + the minimum. + + The seed MUST consist of purely alphanumeric characters and MUST + be of one to 16 characters in length. The seed is a string of + characters that MUST not contain any blanks and SHOULD consist of + strictly alphanumeric characters from the ISO-646 Invariant Code + Set. The seed MUST be case insensitive and MUST be internally + converted to lower case before it is processed. + + The sequence number and seed together constitute a larger unit of + data called the challenge. The challenge gives the generator the + parameters it needs to calculate the correct one-time password + from the secret pass-phrase. The challenge MUST be in a standard + syntax so that automated generators can recognize the challenge in + context and extract these parameters. The syntax of the challenge + is: + + otp- + + The three tokens MUST be separated by a white space (defined as + any number of spaces and/or tabs) and the entire challenge string + MUST be terminated with either a space or a new line. The string + "otp-" MUST be in lower case. The algorithm identifier is case + sensitive (the existing identifiers are all lower case), and the + seed is case insensitive and converted before use to lower case. + + + +Haller & Metz Standards Track [Page 4] + +RFC 1938 A One-Time Password System May 1996 + + + If additional algorithms are defined, appropriate identifiers + (short, but not limited to three or four characters) must be + defined. The currently defined algorithm identifiers are: + + md4 MD4 Message Digest + md5 MD5 Message Digest + sha1 NIST Secure Hash Algorithm Revision 1 + + An example of an OTP challenge is: otp-md5 487 dog2 + + Form of Output + + The one-time password generated by the above procedure is 64 bits + in length. Entering a 64 bit number is a difficult and error prone + process. Some generators insert this password into the input + stream and some others make it available for system "cut and + paste." Still other arrangements require the one-time password to + be entered manually. The OTP system is designed to facilitate this + manual entry without impeding automatic methods. The one-time + password therefore MAY be converted to, and all servers MUST be + capable of accepting it as, a sequence of six short (1 to 4 + letter) easily typed words that only use characters from ISO-646 + IVCS. Each word is chosen from a dictionary of 2048 words; at 11 + bits per word, all one-time passwords may be encoded. + + The two extra bits in this encoding are used to store a checksum. + The 64 bits of key are broken down into pairs of bits, then these + pairs are summed together. The two least significant bits of this + sum are encoded in the last two bits of the six word sequence with + the least significant bit of the sum as the last bit encoded. All + OTP generators MUST calculate this checksum and all OTP servers + MUST verify this checksum explicitly as part of the operation of + decoding this representation of the one-time password. + + Generators that produce the six-word format MUST present the words + in upper case with single spaces used as separators. All servers + MUST accept six-word format without regard to case and white space + used as a separator. The two lines below represent the same one- + time password. The first is valid as output from a generator and + as input a server, the second is valid only as human input to a + server. + + OUST COAT FOAL MUG BEAK TOTE + oust coat foal mug beak tote + + Interoperability requires that all OTP servers and generators use + the same dictionary. The standard dictionary was originally + specified in the "S/KEY One Time Password System" that is + + + +Haller & Metz Standards Track [Page 5] + +RFC 1938 A One-Time Password System May 1996 + + + described in RFC 1760 [5]. This dictionary is included in this + document as Appendix C. + + To facilitate the implementation of smaller generators, + hexadecimal output is an acceptable alternative for the + presentation of the one-time password. All implementations of the + server software MUST accept case-insensitive hexadecimal as well + as six-word format. The hexadecimal digits may be separated by + white space so servers are REQUIRED to ignore all white space. If + the representation is partitioned by white space, leading zeros + must be retained. Examples of hexadecimal format are: + + Representation Value + + 3503785b369cda8b 0x3503785b369cda8b + e5cc a1b8 7c13 096b 0xe5cca1b87c13096b + C7 48 90 F4 27 7B A1 CF 0xc74890f4277ba1cf + 47 9 A68 28 4C 9D 0 1BC 0x479a68284c9d01bc + + In addition to accepting six-word and hexadecimal encodings of the + 64 bit one-time password, servers SHOULD accept the alternate + dictionary encoding described in Appendix B. The six words in + this encoding MUST not overlap the set of words in the standard + dictionary. To avoid ambiguity with the hexadecimal + representation, words in the alternate dictionary MUST not be + comprised solely of the letters A-F. Decoding words thus encoded + does not require any knowledge of the alternative dictionary used + so the acceptance of any alternate dictionary implies the + acceptance of all alternate dictionaries. Words in the + alternative dictionaries are case sensitive. Generators and + servers MUST preserve the case in the processing of these words. + + In summary, all conforming servers MUST accept six-word input that + uses the Standard Dictionary (RFC 1760 and Appendix C), MUST + accept hexadecimal encoding, and SHOULD accept six-word input that + uses the Alternative Dictionary technique (Appendix B). As there + is a remote possibility that a hexadecimal encoding of a one-time + password will look like a valid six-word standard dictionary + encoding, all implementations MUST use the following scheme. If a + six-word encoded one-time password is valid, it is accepted. + Otherwise, if the one-time password can be interpreted as + hexadecimal, and with that decoding it is valid, then it is + accepted. + + + + + + + + +Haller & Metz Standards Track [Page 6] + +RFC 1938 A One-Time Password System May 1996 + + +7.0 VERIFICATION OF ONE-TIME PASSWORDS + + An application on the server system that requires OTP authentication + is expected to issue an OTP challenge as described above. Given the + parameters from this challenge and the secret pass-phrase, the + generator can compute (or lookup) the one-time password that is + passed to the server to be verified. + + The server system has a database containing, for each user, the one- + time password from the last successful authentication or the first + OTP of a newly initialized sequence. To authenticate the user, the + server decodes the one-time password received from the generator into + a 64-bit key and then runs this key through the secure hash function + once. If the result of this operation matches the stored previous + OTP, the authentication is successful and the accepted one-time + password is stored for future use. + +8.0 PASS-PHRASE CHANGES + + Because the number of hash function applications executed by the + generator decreases by one each time, at some point the user must + reinitialize the system or be unable to authenticate. + + Although some installations may not permit users to initialize + remotely, implementations MUST provide a means to do so that does not + reveal the user's secret pass-phrase. One way is to provide a means + to reinitialize the sequence through explicit specification of the + first one-time password. + + When the sequence of one-time passwords is reinitialized, + implementations MUST verify that the seed or the pass-phrase is + changed. Installations SHOULD discourage any operation that sends + the secret pass-phrase over a network in clear-text as such practice + defeats the concept of a one-time password. + + Implementations MAY use the following technique for + [re]initialization: + + o The user picks a new seed and hash count (default values may + be offered). The user provides these, along with the + corresponding generated one-time password, to the host system. + + o The user MAY also provide the corresponding generated one + time password for count-1 as an error check. + + o The user SHOULD provide the generated one-time password for + the old seed and old hash count to protect an idle terminal + or workstation (this implies that when the count is 1, the + + + +Haller & Metz Standards Track [Page 7] + +RFC 1938 A One-Time Password System May 1996 + + + user can login but cannot then change the seed or count). + + In the future a specific protocol may be defined for reinitialization + that will permit smooth and possibly automated interoperation of all + hosts and generators. + +9.0 PROTECTION AGAINST RACE ATTACK + + All conforming server implementations MUST protect against the race + condition described in this section. A defense against this attack + is outlined; implementations MAY use this approach or MAY select an + alternative defense. + + It is possible for an attacker to listen to most of a one-time + password, guess the remainder, and then race the legitimate user to + complete the authentication. Multiple guesses against the last word + of the six-word format are likely to succeed. + + One possible defense is to prevent a user from starting multiple + simultaneous authentication sessions. This means that once the + legitimate user has initiated authentication, an attacker would be + blocked until the first authentication process has completed. In + this approach, a timeout is necessary to thwart a denial of service + attack. + +10.0 SECURITY CONSIDERATIONS + + This entire document discusses an authentication system that improves + security by limiting the danger of eavesdropping/replay attacks that + have been used against simple password systems [4]. + + The use of the OTP system only provides protections against passive + eavesdropping/replay attacks. It does not provide for the privacy of + transmitted data, and it does not provide protection against active + attacks. Active attacks against TCP connections are known to be + present in the current Internet [9]. + + The success of the OTP system to protect host systems is dependent on + the non-invertability of the secure hash functions used. To our + knowledge, none of the hash algorithms have been broken, but it is + generally believed [6] that MD4 is not as strong as MD5. If a server + supports multiple hash algorithms, it is only as secure as the + weakest algorithm. + + + + + + + + +Haller & Metz Standards Track [Page 8] + +RFC 1938 A One-Time Password System May 1996 + + +11.0 ACKNOWLEDGMENTS + + The idea behind OTP authentication was first proposed by Leslie + Lamport [1]. Bellcore's S/KEY system, from which OTP is derived, was + proposed by Phil Karn, who also wrote most of the Bellcore reference + implementation. + +12.0 REFERENCES + + [1] Leslie Lamport, "Password Authentication with Insecure + Communication", Communications of the ACM 24.11 (November + 1981), 770-772 + + [2] Rivest, R., "The MD4 Message-Digest Algorithm, RFC 1320", + MIT and RSA Data Security, Inc., April 1992. + + [3] Neil Haller, "The S/KEY One-Time Password System", Proceedings + of the ISOC Symposium on Network and Distributed System + Security, February 1994, San Diego, CA + + [4] Haller, N., and R. Atkinson, "On Internet Authentication", + RFC 1704, Bellcore and Naval Research Laboratory, October 1994. + + [5] Haller, N., "The S/KEY One-Time Password System", RFC 1760, + Bellcore, February 1995. + + [6] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + MIT and RSA Data Security, Inc., April 1992. + + [7] National Institute of Standards and Technology (NIST), + "Announcing the Secure Hash Standard", FIPS 180-1, U.S. + Department of Commerce, April 1995. + + [8] International Standard - Information Processing -- ISO 7-bit + coded character set for information interchange (Invariant Code + Set), ISO-646, International Standards Organization, Geneva, + Switzerland, 1983 + + [9] Computer Emergency Response Team (CERT), "IP Spoofing and + Hijacked Terminal Connections", CA-95:01, January 1995. + Available via anonymous ftp from info.cert.org in + /pub/cert_advisories. + + + + + + + + + +Haller & Metz Standards Track [Page 9] + +RFC 1938 A One-Time Password System May 1996 + + +13.0 AUTHORS' ADDRESSES + + Neil Haller + Bellcore + MCC 1C-265B + 445 South Street + Morristown, NJ, 07960-6438, USA + + Phone: +1 201 829-4478 + Fax: +1 201 829-2504 + EMail: nmh@bellcore.com + + + Craig Metz + Kaman Sciences Corporation + For NRL Code 5544 + 4555 Overlook Avenue, S.W. + Washington, DC, 20375-5337, USA + + Phone: +1 202 404-7122 + Fax: +1 202 404-7942 + EMail: cmetz@cs.nrl.navy.mil + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Haller & Metz Standards Track [Page 10] + +RFC 1938 A One-Time Password System May 1996 + + +Appendix A - Interfaces to Secure Hash Algorithms + +MD4 Message Digest (see reference [2]) + + strcpy(buf,seed); + strcat(buf,passwd); + MDbegin(&md) + MDupdate(&md,(unsigned char *)buf,8*buflen); + + /* Fold result to 64 bits */ + md.buffer[0] ^= md.buffer[2]; + md.buffer[1] ^= md.buffer[3]; + + +MD5 Message Digest (see reference [6]) + + MD5_CTX mdCxt; + + strcpy(buf,seed); + strcat(buf,passwd); + + /* Crunch the key through MD5 */ + MD5Init(&mdCxt); + MD5Update(&mdCxt,(unsigned char *)bits,strlen(bits)); + MD5Update(&mdCxt,(unsigned char *)buf,buflen); + MD5Final(&mdCxt); + + /* Fold result to 64 bits */ + for( i = 0; i < 8; i++ ) + result[i] = mdCxt.digest[i] ^ mdCxt.digest[i+8]; + + +SHA Secure Hash Algorithm (see reference [7]) + + + /* Fold 160 bit result to 64 bits */ + md.buffer[0] ^= md.buffer[2]; + md.buffer[1] ^= md.buffer[3]; + md.buffer[0] ^= md.buffer[4]; + +Appendix B - Alternative Dictionary Algorithm + + The purpose of alternative dictionary encoding of the OTP one-time + password is to allow the use of language specific or friendly words. + As case translation is not always well defined, the alternative + dictionary encoding is case insensitive. Servers SHOULD accept this + encoding in addition to the standard 6-word and hexadecimal + encodings. + + + +Haller & Metz Standards Track [Page 11] + +RFC 1938 A One-Time Password System May 1996 + + +GENERATOR ENCODING USING AN ALTERNATE DICTIONARY + + The standard 6-word encoding uses the placement of a word in the + dictionary to represent an 11-bit number. The 64-bit one-time + password can then be represented by six words. + + An alternative dictionary of 2048 words may be created such that + each word W and position of the word in the dictionary N obey the + relationship: + + alg( W ) % 2048 == N + where + alg is the hash algorithm used (e.g. MD4, MD5, SHA1). + + In addition, no words in the standard dictionary may be chosen. + + The generator expands the 64-bit one-time password to 66 bits by + computing parity as with the standard 6-word encoding. The six 11- + bit numbers are then converted to words using the dictionary that + was created such that the above relationship holds. + + +SERVER DECODING OF ALTERNATE DICTIONARY ONE-TIME PASSWORDS + + The server accepting alternative dictionary encoding converts each + word to an 11-bit number using the above encoding. These numbers are + then used in the same way as the decoded standard dictionary words + to form the 66-bit one-time password. + + The server does not need to have access to the alternate dictionary + that was used to create the one-time password it is authenticating. + This is because the decoding from word to 11-bit number does not + make any use of the dictionary. As a result of the independence of + the dictionary, a server accepting one alternate dictionary accept + all alternate dictionaries. + +Appendix C - Dictionary for Converting Between 6-Word and Binary +Formats + + This dictionary is from the module put.c in the original Bellcore + reference distribution. + +{ "A", "ABE", "ACE", "ACT", "AD", "ADA", "ADD", +"AGO", "AID", "AIM", "AIR", "ALL", "ALP", "AM", "AMY", +"AN", "ANA", "AND", "ANN", "ANT", "ANY", "APE", "APS", +"APT", "ARC", "ARE", "ARK", "ARM", "ART", "AS", "ASH", +"ASK", "AT", "ATE", "AUG", "AUK", "AVE", "AWE", "AWK", +"AWL", "AWN", "AX", "AYE", "BAD", "BAG", "BAH", "BAM", + + + +Haller & Metz Standards Track [Page 12] + +RFC 1938 A One-Time Password System May 1996 + + +"BAN", "BAR", "BAT", "BAY", "BE", "BED", "BEE", "BEG", +"BEN", "BET", "BEY", "BIB", "BID", "BIG", "BIN", "BIT", +"BOB", "BOG", "BON", "BOO", "BOP", "BOW", "BOY", "BUB", +"BUD", "BUG", "BUM", "BUN", "BUS", "BUT", "BUY", "BY", +"BYE", "CAB", "CAL", "CAM", "CAN", "CAP", "CAR", "CAT", +"CAW", "COD", "COG", "COL", "CON", "COO", "COP", "COT", +"COW", "COY", "CRY", "CUB", "CUE", "CUP", "CUR", "CUT", +"DAB", "DAD", "DAM", "DAN", "DAR", "DAY", "DEE", "DEL", +"DEN", "DES", "DEW", "DID", "DIE", "DIG", "DIN", "DIP", +"DO", "DOE", "DOG", "DON", "DOT", "DOW", "DRY", "DUB", +"DUD", "DUE", "DUG", "DUN", "EAR", "EAT", "ED", "EEL", +"EGG", "EGO", "ELI", "ELK", "ELM", "ELY", "EM", "END", +"EST", "ETC", "EVA", "EVE", "EWE", "EYE", "FAD", "FAN", +"FAR", "FAT", "FAY", "FED", "FEE", "FEW", "FIB", "FIG", +"FIN", "FIR", "FIT", "FLO", "FLY", "FOE", "FOG", "FOR", +"FRY", "FUM", "FUN", "FUR", "GAB", "GAD", "GAG", "GAL", +"GAM", "GAP", "GAS", "GAY", "GEE", "GEL", "GEM", "GET", +"GIG", "GIL", "GIN", "GO", "GOT", "GUM", "GUN", "GUS", +"GUT", "GUY", "GYM", "GYP", "HA", "HAD", "HAL", "HAM", +"HAN", "HAP", "HAS", "HAT", "HAW", "HAY", "HE", "HEM", +"HEN", "HER", "HEW", "HEY", "HI", "HID", "HIM", "HIP", +"HIS", "HIT", "HO", "HOB", "HOC", "HOE", "HOG", "HOP", +"HOT", "HOW", "HUB", "HUE", "HUG", "HUH", "HUM", "HUT", +"I", "ICY", "IDA", "IF", "IKE", "ILL", "INK", "INN", +"IO", "ION", "IQ", "IRA", "IRE", "IRK", "IS", "IT", +"ITS", "IVY", "JAB", "JAG", "JAM", "JAN", "JAR", "JAW", +"JAY", "JET", "JIG", "JIM", "JO", "JOB", "JOE", "JOG", +"JOT", "JOY", "JUG", "JUT", "KAY", "KEG", "KEN", "KEY", +"KID", "KIM", "KIN", "KIT", "LA", "LAB", "LAC", "LAD", +"LAG", "LAM", "LAP", "LAW", "LAY", "LEA", "LED", "LEE", +"LEG", "LEN", "LEO", "LET", "LEW", "LID", "LIE", "LIN", +"LIP", "LIT", "LO", "LOB", "LOG", "LOP", "LOS", "LOT", +"LOU", "LOW", "LOY", "LUG", "LYE", "MA", "MAC", "MAD", +"MAE", "MAN", "MAO", "MAP", "MAT", "MAW", "MAY", "ME", +"MEG", "MEL", "MEN", "MET", "MEW", "MID", "MIN", "MIT", +"MOB", "MOD", "MOE", "MOO", "MOP", "MOS", "MOT", "MOW", +"MUD", "MUG", "MUM", "MY", "NAB", "NAG", "NAN", "NAP", +"NAT", "NAY", "NE", "NED", "NEE", "NET", "NEW", "NIB", +"NIL", "NIP", "NIT", "NO", "NOB", "NOD", "NON", "NOR", +"NOT", "NOV", "NOW", "NU", "NUN", "NUT", "O", "OAF", +"OAK", "OAR", "OAT", "ODD", "ODE", "OF", "OFF", "OFT", +"OH", "OIL", "OK", "OLD", "ON", "ONE", "OR", "ORB", +"ORE", "ORR", "OS", "OTT", "OUR", "OUT", "OVA", "OW", +"OWE", "OWL", "OWN", "OX", "PA", "PAD", "PAL", "PAM", +"PAN", "PAP", "PAR", "PAT", "PAW", "PAY", "PEA", "PEG", +"PEN", "PEP", "PER", "PET", "PEW", "PHI", "PI", "PIE", +"PIN", "PIT", "PLY", "PO", "POD", "POE", "POP", "POT", +"POW", "PRO", "PRY", "PUB", "PUG", "PUN", "PUP", "PUT", + + + +Haller & Metz Standards Track [Page 13] + +RFC 1938 A One-Time Password System May 1996 + + +"QUO", "RAG", "RAM", "RAN", "RAP", "RAT", "RAW", "RAY", +"REB", "RED", "REP", "RET", "RIB", "RID", "RIG", "RIM", +"RIO", "RIP", "ROB", "ROD", "ROE", "RON", "ROT", "ROW", +"ROY", "RUB", "RUE", "RUG", "RUM", "RUN", "RYE", "SAC", +"SAD", "SAG", "SAL", "SAM", "SAN", "SAP", "SAT", "SAW", +"SAY", "SEA", "SEC", "SEE", "SEN", "SET", "SEW", "SHE", +"SHY", "SIN", "SIP", "SIR", "SIS", "SIT", "SKI", "SKY", +"SLY", "SO", "SOB", "SOD", "SON", "SOP", "SOW", "SOY", +"SPA", "SPY", "SUB", "SUD", "SUE", "SUM", "SUN", "SUP", +"TAB", "TAD", "TAG", "TAN", "TAP", "TAR", "TEA", "TED", +"TEE", "TEN", "THE", "THY", "TIC", "TIE", "TIM", "TIN", +"TIP", "TO", "TOE", "TOG", "TOM", "TON", "TOO", "TOP", +"TOW", "TOY", "TRY", "TUB", "TUG", "TUM", "TUN", "TWO", +"UN", "UP", "US", "USE", "VAN", "VAT", "VET", "VIE", +"WAD", "WAG", "WAR", "WAS", "WAY", "WE", "WEB", "WED", +"WEE", "WET", "WHO", "WHY", "WIN", "WIT", "WOK", "WON", +"WOO", "WOW", "WRY", "WU", "YAM", "YAP", "YAW", "YE", +"YEA", "YES", "YET", "YOU", "ABED", "ABEL", "ABET", "ABLE", +"ABUT", "ACHE", "ACID", "ACME", "ACRE", "ACTA", "ACTS", "ADAM", +"ADDS", "ADEN", "AFAR", "AFRO", "AGEE", "AHEM", "AHOY", "AIDA", +"AIDE", "AIDS", "AIRY", "AJAR", "AKIN", "ALAN", "ALEC", "ALGA", +"ALIA", "ALLY", "ALMA", "ALOE", "ALSO", "ALTO", "ALUM", "ALVA", +"AMEN", "AMES", "AMID", "AMMO", "AMOK", "AMOS", "AMRA", "ANDY", +"ANEW", "ANNA", "ANNE", "ANTE", "ANTI", "AQUA", "ARAB", "ARCH", +"AREA", "ARGO", "ARID", "ARMY", "ARTS", "ARTY", "ASIA", "ASKS", +"ATOM", "AUNT", "AURA", "AUTO", "AVER", "AVID", "AVIS", "AVON", +"AVOW", "AWAY", "AWRY", "BABE", "BABY", "BACH", "BACK", "BADE", +"BAIL", "BAIT", "BAKE", "BALD", "BALE", "BALI", "BALK", "BALL", +"BALM", "BAND", "BANE", "BANG", "BANK", "BARB", "BARD", "BARE", +"BARK", "BARN", "BARR", "BASE", "BASH", "BASK", "BASS", "BATE", +"BATH", "BAWD", "BAWL", "BEAD", "BEAK", "BEAM", "BEAN", "BEAR", +"BEAT", "BEAU", "BECK", "BEEF", "BEEN", "BEER", "BEET", "BELA", +"BELL", "BELT", "BEND", "BENT", "BERG", "BERN", "BERT", "BESS", +"BEST", "BETA", "BETH", "BHOY", "BIAS", "BIDE", "BIEN", "BILE", +"BILK", "BILL", "BIND", "BING", "BIRD", "BITE", "BITS", "BLAB", +"BLAT", "BLED", "BLEW", "BLOB", "BLOC", "BLOT", "BLOW", "BLUE", +"BLUM", "BLUR", "BOAR", "BOAT", "BOCA", "BOCK", "BODE", "BODY", +"BOGY", "BOHR", "BOIL", "BOLD", "BOLO", "BOLT", "BOMB", "BONA", +"BOND", "BONE", "BONG", "BONN", "BONY", "BOOK", "BOOM", "BOON", +"BOOT", "BORE", "BORG", "BORN", "BOSE", "BOSS", "BOTH", "BOUT", +"BOWL", "BOYD", "BRAD", "BRAE", "BRAG", "BRAN", "BRAY", "BRED", +"BREW", "BRIG", "BRIM", "BROW", "BUCK", "BUDD", "BUFF", "BULB", +"BULK", "BULL", "BUNK", "BUNT", "BUOY", "BURG", "BURL", "BURN", +"BURR", "BURT", "BURY", "BUSH", "BUSS", "BUST", "BUSY", "BYTE", +"CADY", "CAFE", "CAGE", "CAIN", "CAKE", "CALF", "CALL", "CALM", +"CAME", "CANE", "CANT", "CARD", "CARE", "CARL", "CARR", "CART", +"CASE", "CASH", "CASK", "CAST", "CAVE", "CEIL", "CELL", "CENT", +"CERN", "CHAD", "CHAR", "CHAT", "CHAW", "CHEF", "CHEN", "CHEW", + + + +Haller & Metz Standards Track [Page 14] + +RFC 1938 A One-Time Password System May 1996 + + +"CHIC", "CHIN", "CHOU", "CHOW", "CHUB", "CHUG", "CHUM", "CITE", +"CITY", "CLAD", "CLAM", "CLAN", "CLAW", "CLAY", "CLOD", "CLOG", +"CLOT", "CLUB", "CLUE", "COAL", "COAT", "COCA", "COCK", "COCO", +"CODA", "CODE", "CODY", "COED", "COIL", "COIN", "COKE", "COLA", +"COLD", "COLT", "COMA", "COMB", "COME", "COOK", "COOL", "COON", +"COOT", "CORD", "CORE", "CORK", "CORN", "COST", "COVE", "COWL", +"CRAB", "CRAG", "CRAM", "CRAY", "CREW", "CRIB", "CROW", "CRUD", +"CUBA", "CUBE", "CUFF", "CULL", "CULT", "CUNY", "CURB", "CURD", +"CURE", "CURL", "CURT", "CUTS", "DADE", "DALE", "DAME", "DANA", +"DANE", "DANG", "DANK", "DARE", "DARK", "DARN", "DART", "DASH", +"DATA", "DATE", "DAVE", "DAVY", "DAWN", "DAYS", "DEAD", "DEAF", +"DEAL", "DEAN", "DEAR", "DEBT", "DECK", "DEED", "DEEM", "DEER", +"DEFT", "DEFY", "DELL", "DENT", "DENY", "DESK", "DIAL", "DICE", +"DIED", "DIET", "DIME", "DINE", "DING", "DINT", "DIRE", "DIRT", +"DISC", "DISH", "DISK", "DIVE", "DOCK", "DOES", "DOLE", "DOLL", +"DOLT", "DOME", "DONE", "DOOM", "DOOR", "DORA", "DOSE", "DOTE", +"DOUG", "DOUR", "DOVE", "DOWN", "DRAB", "DRAG", "DRAM", "DRAW", +"DREW", "DRUB", "DRUG", "DRUM", "DUAL", "DUCK", "DUCT", "DUEL", +"DUET", "DUKE", "DULL", "DUMB", "DUNE", "DUNK", "DUSK", "DUST", +"DUTY", "EACH", "EARL", "EARN", "EASE", "EAST", "EASY", "EBEN", +"ECHO", "EDDY", "EDEN", "EDGE", "EDGY", "EDIT", "EDNA", "EGAN", +"ELAN", "ELBA", "ELLA", "ELSE", "EMIL", "EMIT", "EMMA", "ENDS", +"ERIC", "EROS", "EVEN", "EVER", "EVIL", "EYED", "FACE", "FACT", +"FADE", "FAIL", "FAIN", "FAIR", "FAKE", "FALL", "FAME", "FANG", +"FARM", "FAST", "FATE", "FAWN", "FEAR", "FEAT", "FEED", "FEEL", +"FEET", "FELL", "FELT", "FEND", "FERN", "FEST", "FEUD", "FIEF", +"FIGS", "FILE", "FILL", "FILM", "FIND", "FINE", "FINK", "FIRE", +"FIRM", "FISH", "FISK", "FIST", "FITS", "FIVE", "FLAG", "FLAK", +"FLAM", "FLAT", "FLAW", "FLEA", "FLED", "FLEW", "FLIT", "FLOC", +"FLOG", "FLOW", "FLUB", "FLUE", "FOAL", "FOAM", "FOGY", "FOIL", +"FOLD", "FOLK", "FOND", "FONT", "FOOD", "FOOL", "FOOT", "FORD", +"FORE", "FORK", "FORM", "FORT", "FOSS", "FOUL", "FOUR", "FOWL", +"FRAU", "FRAY", "FRED", "FREE", "FRET", "FREY", "FROG", "FROM", +"FUEL", "FULL", "FUME", "FUND", "FUNK", "FURY", "FUSE", "FUSS", +"GAFF", "GAGE", "GAIL", "GAIN", "GAIT", "GALA", "GALE", "GALL", +"GALT", "GAME", "GANG", "GARB", "GARY", "GASH", "GATE", "GAUL", +"GAUR", "GAVE", "GAWK", "GEAR", "GELD", "GENE", "GENT", "GERM", +"GETS", "GIBE", "GIFT", "GILD", "GILL", "GILT", "GINA", "GIRD", +"GIRL", "GIST", "GIVE", "GLAD", "GLEE", "GLEN", "GLIB", "GLOB", +"GLOM", "GLOW", "GLUE", "GLUM", "GLUT", "GOAD", "GOAL", "GOAT", +"GOER", "GOES", "GOLD", "GOLF", "GONE", "GONG", "GOOD", "GOOF", +"GORE", "GORY", "GOSH", "GOUT", "GOWN", "GRAB", "GRAD", "GRAY", +"GREG", "GREW", "GREY", "GRID", "GRIM", "GRIN", "GRIT", "GROW", +"GRUB", "GULF", "GULL", "GUNK", "GURU", "GUSH", "GUST", "GWEN", +"GWYN", "HAAG", "HAAS", "HACK", "HAIL", "HAIR", "HALE", "HALF", +"HALL", "HALO", "HALT", "HAND", "HANG", "HANK", "HANS", "HARD", +"HARK", "HARM", "HART", "HASH", "HAST", "HATE", "HATH", "HAUL", +"HAVE", "HAWK", "HAYS", "HEAD", "HEAL", "HEAR", "HEAT", "HEBE", + + + +Haller & Metz Standards Track [Page 15] + +RFC 1938 A One-Time Password System May 1996 + + +"HECK", "HEED", "HEEL", "HEFT", "HELD", "HELL", "HELM", "HERB", +"HERD", "HERE", "HERO", "HERS", "HESS", "HEWN", "HICK", "HIDE", +"HIGH", "HIKE", "HILL", "HILT", "HIND", "HINT", "HIRE", "HISS", +"HIVE", "HOBO", "HOCK", "HOFF", "HOLD", "HOLE", "HOLM", "HOLT", +"HOME", "HONE", "HONK", "HOOD", "HOOF", "HOOK", "HOOT", "HORN", +"HOSE", "HOST", "HOUR", "HOVE", "HOWE", "HOWL", "HOYT", "HUCK", +"HUED", "HUFF", "HUGE", "HUGH", "HUGO", "HULK", "HULL", "HUNK", +"HUNT", "HURD", "HURL", "HURT", "HUSH", "HYDE", "HYMN", "IBIS", +"ICON", "IDEA", "IDLE", "IFFY", "INCA", "INCH", "INTO", "IONS", +"IOTA", "IOWA", "IRIS", "IRMA", "IRON", "ISLE", "ITCH", "ITEM", +"IVAN", "JACK", "JADE", "JAIL", "JAKE", "JANE", "JAVA", "JEAN", +"JEFF", "JERK", "JESS", "JEST", "JIBE", "JILL", "JILT", "JIVE", +"JOAN", "JOBS", "JOCK", "JOEL", "JOEY", "JOHN", "JOIN", "JOKE", +"JOLT", "JOVE", "JUDD", "JUDE", "JUDO", "JUDY", "JUJU", "JUKE", +"JULY", "JUNE", "JUNK", "JUNO", "JURY", "JUST", "JUTE", "KAHN", +"KALE", "KANE", "KANT", "KARL", "KATE", "KEEL", "KEEN", "KENO", +"KENT", "KERN", "KERR", "KEYS", "KICK", "KILL", "KIND", "KING", +"KIRK", "KISS", "KITE", "KLAN", "KNEE", "KNEW", "KNIT", "KNOB", +"KNOT", "KNOW", "KOCH", "KONG", "KUDO", "KURD", "KURT", "KYLE", +"LACE", "LACK", "LACY", "LADY", "LAID", "LAIN", "LAIR", "LAKE", +"LAMB", "LAME", "LAND", "LANE", "LANG", "LARD", "LARK", "LASS", +"LAST", "LATE", "LAUD", "LAVA", "LAWN", "LAWS", "LAYS", "LEAD", +"LEAF", "LEAK", "LEAN", "LEAR", "LEEK", "LEER", "LEFT", "LEND", +"LENS", "LENT", "LEON", "LESK", "LESS", "LEST", "LETS", "LIAR", +"LICE", "LICK", "LIED", "LIEN", "LIES", "LIEU", "LIFE", "LIFT", +"LIKE", "LILA", "LILT", "LILY", "LIMA", "LIMB", "LIME", "LIND", +"LINE", "LINK", "LINT", "LION", "LISA", "LIST", "LIVE", "LOAD", +"LOAF", "LOAM", "LOAN", "LOCK", "LOFT", "LOGE", "LOIS", "LOLA", +"LONE", "LONG", "LOOK", "LOON", "LOOT", "LORD", "LORE", "LOSE", +"LOSS", "LOST", "LOUD", "LOVE", "LOWE", "LUCK", "LUCY", "LUGE", +"LUKE", "LULU", "LUND", "LUNG", "LURA", "LURE", "LURK", "LUSH", +"LUST", "LYLE", "LYNN", "LYON", "LYRA", "MACE", "MADE", "MAGI", +"MAID", "MAIL", "MAIN", "MAKE", "MALE", "MALI", "MALL", "MALT", +"MANA", "MANN", "MANY", "MARC", "MARE", "MARK", "MARS", "MART", +"MARY", "MASH", "MASK", "MASS", "MAST", "MATE", "MATH", "MAUL", +"MAYO", "MEAD", "MEAL", "MEAN", "MEAT", "MEEK", "MEET", "MELD", +"MELT", "MEMO", "MEND", "MENU", "MERT", "MESH", "MESS", "MICE", +"MIKE", "MILD", "MILE", "MILK", "MILL", "MILT", "MIMI", "MIND", +"MINE", "MINI", "MINK", "MINT", "MIRE", "MISS", "MIST", "MITE", +"MITT", "MOAN", "MOAT", "MOCK", "MODE", "MOLD", "MOLE", "MOLL", +"MOLT", "MONA", "MONK", "MONT", "MOOD", "MOON", "MOOR", "MOOT", +"MORE", "MORN", "MORT", "MOSS", "MOST", "MOTH", "MOVE", "MUCH", +"MUCK", "MUDD", "MUFF", "MULE", "MULL", "MURK", "MUSH", "MUST", +"MUTE", "MUTT", "MYRA", "MYTH", "NAGY", "NAIL", "NAIR", "NAME", +"NARY", "NASH", "NAVE", "NAVY", "NEAL", "NEAR", "NEAT", "NECK", +"NEED", "NEIL", "NELL", "NEON", "NERO", "NESS", "NEST", "NEWS", +"NEWT", "NIBS", "NICE", "NICK", "NILE", "NINA", "NINE", "NOAH", +"NODE", "NOEL", "NOLL", "NONE", "NOOK", "NOON", "NORM", "NOSE", + + + +Haller & Metz Standards Track [Page 16] + +RFC 1938 A One-Time Password System May 1996 + + +"NOTE", "NOUN", "NOVA", "NUDE", "NULL", "NUMB", "OATH", "OBEY", +"OBOE", "ODIN", "OHIO", "OILY", "OINT", "OKAY", "OLAF", "OLDY", +"OLGA", "OLIN", "OMAN", "OMEN", "OMIT", "ONCE", "ONES", "ONLY", +"ONTO", "ONUS", "ORAL", "ORGY", "OSLO", "OTIS", "OTTO", "OUCH", +"OUST", "OUTS", "OVAL", "OVEN", "OVER", "OWLY", "OWNS", "QUAD", +"QUIT", "QUOD", "RACE", "RACK", "RACY", "RAFT", "RAGE", "RAID", +"RAIL", "RAIN", "RAKE", "RANK", "RANT", "RARE", "RASH", "RATE", +"RAVE", "RAYS", "READ", "REAL", "REAM", "REAR", "RECK", "REED", +"REEF", "REEK", "REEL", "REID", "REIN", "RENA", "REND", "RENT", +"REST", "RICE", "RICH", "RICK", "RIDE", "RIFT", "RILL", "RIME", +"RING", "RINK", "RISE", "RISK", "RITE", "ROAD", "ROAM", "ROAR", +"ROBE", "ROCK", "RODE", "ROIL", "ROLL", "ROME", "ROOD", "ROOF", +"ROOK", "ROOM", "ROOT", "ROSA", "ROSE", "ROSS", "ROSY", "ROTH", +"ROUT", "ROVE", "ROWE", "ROWS", "RUBE", "RUBY", "RUDE", "RUDY", +"RUIN", "RULE", "RUNG", "RUNS", "RUNT", "RUSE", "RUSH", "RUSK", +"RUSS", "RUST", "RUTH", "SACK", "SAFE", "SAGE", "SAID", "SAIL", +"SALE", "SALK", "SALT", "SAME", "SAND", "SANE", "SANG", "SANK", +"SARA", "SAUL", "SAVE", "SAYS", "SCAN", "SCAR", "SCAT", "SCOT", +"SEAL", "SEAM", "SEAR", "SEAT", "SEED", "SEEK", "SEEM", "SEEN", +"SEES", "SELF", "SELL", "SEND", "SENT", "SETS", "SEWN", "SHAG", +"SHAM", "SHAW", "SHAY", "SHED", "SHIM", "SHIN", "SHOD", "SHOE", +"SHOT", "SHOW", "SHUN", "SHUT", "SICK", "SIDE", "SIFT", "SIGH", +"SIGN", "SILK", "SILL", "SILO", "SILT", "SINE", "SING", "SINK", +"SIRE", "SITE", "SITS", "SITU", "SKAT", "SKEW", "SKID", "SKIM", +"SKIN", "SKIT", "SLAB", "SLAM", "SLAT", "SLAY", "SLED", "SLEW", +"SLID", "SLIM", "SLIT", "SLOB", "SLOG", "SLOT", "SLOW", "SLUG", +"SLUM", "SLUR", "SMOG", "SMUG", "SNAG", "SNOB", "SNOW", "SNUB", +"SNUG", "SOAK", "SOAR", "SOCK", "SODA", "SOFA", "SOFT", "SOIL", +"SOLD", "SOME", "SONG", "SOON", "SOOT", "SORE", "SORT", "SOUL", +"SOUR", "SOWN", "STAB", "STAG", "STAN", "STAR", "STAY", "STEM", +"STEW", "STIR", "STOW", "STUB", "STUN", "SUCH", "SUDS", "SUIT", +"SULK", "SUMS", "SUNG", "SUNK", "SURE", "SURF", "SWAB", "SWAG", +"SWAM", "SWAN", "SWAT", "SWAY", "SWIM", "SWUM", "TACK", "TACT", +"TAIL", "TAKE", "TALE", "TALK", "TALL", "TANK", "TASK", "TATE", +"TAUT", "TEAL", "TEAM", "TEAR", "TECH", "TEEM", "TEEN", "TEET", +"TELL", "TEND", "TENT", "TERM", "TERN", "TESS", "TEST", "THAN", +"THAT", "THEE", "THEM", "THEN", "THEY", "THIN", "THIS", "THUD", +"THUG", "TICK", "TIDE", "TIDY", "TIED", "TIER", "TILE", "TILL", +"TILT", "TIME", "TINA", "TINE", "TINT", "TINY", "TIRE", "TOAD", +"TOGO", "TOIL", "TOLD", "TOLL", "TONE", "TONG", "TONY", "TOOK", +"TOOL", "TOOT", "TORE", "TORN", "TOTE", "TOUR", "TOUT", "TOWN", +"TRAG", "TRAM", "TRAY", "TREE", "TREK", "TRIG", "TRIM", "TRIO", +"TROD", "TROT", "TROY", "TRUE", "TUBA", "TUBE", "TUCK", "TUFT", +"TUNA", "TUNE", "TUNG", "TURF", "TURN", "TUSK", "TWIG", "TWIN", +"TWIT", "ULAN", "UNIT", "URGE", "USED", "USER", "USES", "UTAH", +"VAIL", "VAIN", "VALE", "VARY", "VASE", "VAST", "VEAL", "VEDA", +"VEIL", "VEIN", "VEND", "VENT", "VERB", "VERY", "VETO", "VICE", +"VIEW", "VINE", "VISE", "VOID", "VOLT", "VOTE", "WACK", "WADE", + + + +Haller & Metz Standards Track [Page 17] + +RFC 1938 A One-Time Password System May 1996 + + +"WAGE", "WAIL", "WAIT", "WAKE", "WALE", "WALK", "WALL", "WALT", +"WAND", "WANE", "WANG", "WANT", "WARD", "WARM", "WARN", "WART", +"WASH", "WAST", "WATS", "WATT", "WAVE", "WAVY", "WAYS", "WEAK", +"WEAL", "WEAN", "WEAR", "WEED", "WEEK", "WEIR", "WELD", "WELL", +"WELT", "WENT", "WERE", "WERT", "WEST", "WHAM", "WHAT", "WHEE", +"WHEN", "WHET", "WHOA", "WHOM", "WICK", "WIFE", "WILD", "WILL", +"WIND", "WINE", "WING", "WINK", "WINO", "WIRE", "WISE", "WISH", +"WITH", "WOLF", "WONT", "WOOD", "WOOL", "WORD", "WORE", "WORK", +"WORM", "WORN", "WOVE", "WRIT", "WYNN", "YALE", "YANG", "YANK", +"YARD", "YARN", "YAWL", "YAWN", "YEAH", "YEAR", "YELL", "YOGA", +"YOKE" }; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Haller & Metz Standards Track [Page 18] + diff --git a/RFC/rfc1939.txt b/RFC/rfc1939.txt new file mode 100644 index 00000000..b11350e9 --- /dev/null +++ b/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: + 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: + 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: + + + + 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: + C: + 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: + S: . + C: DELE 1 + S: +OK message 1 deleted + C: RETR 2 + S: +OK 200 octets + S: + S: . + C: DELE 2 + S: +OK message 2 deleted + C: QUIT + S: +OK dewey POP3 server signing off (maildrop empty) + C: + S: + +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] + diff --git a/RFC/rfc1985.txt b/RFC/rfc1985.txt new file mode 100644 index 00000000..f49afd75 --- /dev/null +++ b/RFC/rfc1985.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group J. De Winter +Request for Comments: 1985 Wildbear Consulting, Inc. +Category: Standards Track August 1996 + + + SMTP Service Extension + for Remote Message Queue Starting + +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 + + This memo defines an extension to the SMTP service whereby an SMTP + client and server may interact to give the server an opportunity to + start the processing of its queues for messages to go to a given + host. This extension is meant to be used in startup conditions as + well as for mail nodes that have transient connections to their + service providers. + +1. Introduction + + The TURN command was a valid attempt to address the problem of having + to start the processing for the mail queue on a remote machine. + However, the TURN command presents a large security loophole. As + there is no verification of the remote host name, the TURN command + could be used by a rogue system to download the mail for a site other + than itself. + + Therefore, this memo introduces the ETRN command. This command uses + the mechanism defined in [4] to define extensions to the SMTP service + whereby a client ("sender-SMTP") may request that the server + ("receiver-SMTP") start the processing of its mail queues for + messages that are waiting at the server for the client machine. If + any messages are at the server for the client, then the server should + create a new SMTP session and send the messages at that time. + + + + + + + + + + +De Winter Standards Track [Page 1] + +RFC 1985 SMTP Service Extension - ETRN August 1996 + + +2. Framework for the ETRN Extension + + The following service extension is therefore defined: + + (1) the name of the SMTP service extension is "Remote Queue + Processing Declaration"; + + (2) the EHLO keyword value associated with this extension is "ETRN", + with no associated parameters; + + (3) one additional verb, ETRN, with a single parameter that + specifies the name of the client(s) to start processing for; + + (4) 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. + +3. The Remote Queue Processing Declaration service extension + + To save money, many small companies want to only maintain transient + connections to their service providers. In addition, there are some + situations where the client sites depend on their mail arriving + quickly, so forcing the queues on the server belonging to their + service provider may be more desirable than waiting for the retry + timeout to occur. + + Both of these situations could currently be fixed using the TURN + command defined in [1], if it were not for a large security loophole + in the TURN command. As it stands, the TURN command will reverse the + direction of the SMTP connection and assume that the remote host is + being honest about what its name is. The security loophole is that + there is no documented stipulation for checking the authenticity of + the remote host name, as given in the HELO or EHLO command. As such, + most SMTP and ESMTP implementations do not implement the TURN command + to avoid this security loophole. + + This has been addressed in the design of the ETRN command. This + extended turn command was written with the points in the first + paragraph in mind, yet paying attention to the problems that + currently exist with the TURN command. The security loophole is + avoided by asking the server to start a new connection aimed at the + specified client. + + In this manner, the server has a lot more certainty that it is + talking to the correct SMTP client. This mechanism can just be seen + as a more immediate version of the retry queues that appear in most + SMTP implementations. In addition, as this command will take a + + + +De Winter Standards Track [Page 2] + +RFC 1985 SMTP Service Extension - ETRN August 1996 + + + single parameter, the name of the remote host(s) to start the queues + for, the server can decide whether it wishes to respect the request + or deny it for any local administrative reasons. + +4. Definitions + + Remote queue processing means that using an SMTP or ESMTP connection, + the client may request that the server start to process parts of its + messaging queue. This processing is performed using the existing + SMTP infrastructure and will occur at some point after the processing + is initiated. + + The server host is the node that is responding to the ETRN + command. + + The client host is the node that is initiating the ETRN command. + + The remote host name is defined to be a plain-text field that + specifies a name for the remote host(s). This remote host name may + also include an alias for the specified remote host or special + commands to identify other types of queues. + +5. The extended ETRN command + + The extended ETRN command is issued by the client host when it wishes + to start the SMTP queue processing of a given server host. The + syntax of this command is as follows: + + ETRN [
]<> + The text of a particular body section. The section + specification is a set of zero or more part + specifiers delimited by periods. A part specifier + is either a part number or one of the following: + HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and + TEXT. An empty section specification refers to the + entire message, including the header. + + Every message has at least one part number. + Non-[MIME-IMB] messages, and non-multipart + [MIME-IMB] messages with no encapsulated message, + only have a part 1. + + Multipart messages are assigned consecutive part + numbers, as they occur in the message. If a + particular part is of type message or multipart, + its parts MUST be indicated by a period followed by + the part number within that nested multipart part. + + + + + + +Crispin Standards Track [Page 41] + +RFC 2060 IMAP4rev1 December 1996 + + + A part of type MESSAGE/RFC822 also has nested part + numbers, referring to parts of the MESSAGE part's + body. + + The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and + TEXT part specifiers can be the sole part specifier + or can be prefixed by one or more numeric part + specifiers, provided that the numeric part + specifier refers to a part of type MESSAGE/RFC822. + The MIME part specifier MUST be prefixed by one or + more numeric part specifiers. + + The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT + part specifiers refer to the [RFC-822] header of + the message or of an encapsulated [MIME-IMT] + MESSAGE/RFC822 message. HEADER.FIELDS and + HEADER.FIELDS.NOT are followed by a list of + field-name (as defined in [RFC-822]) names, and + return a subset of the header. The subset returned + by HEADER.FIELDS contains only those header fields + with a field-name that matches one of the names in + the list; similarly, the subset returned by + HEADER.FIELDS.NOT contains only the header fields + with a non-matching field-name. The field-matching + is case-insensitive but otherwise exact. In all + cases, the delimiting blank line between the header + and the body is always included. + + The MIME part specifier refers to the [MIME-IMB] + header for this part. + + The TEXT part specifier refers to the text body of + the message, omitting the [RFC-822] header. + + + + + + + + + + + + + + + + + + +Crispin Standards Track [Page 42] + +RFC 2060 IMAP4rev1 December 1996 + + + Here is an example of a complex message + with some of its part specifiers: + + HEADER ([RFC-822] header of the message) + TEXT MULTIPART/MIXED + 1 TEXT/PLAIN + 2 APPLICATION/OCTET-STREAM + 3 MESSAGE/RFC822 + 3.HEADER ([RFC-822] header of the message) + 3.TEXT ([RFC-822] text body of the message) + 3.1 TEXT/PLAIN + 3.2 APPLICATION/OCTET-STREAM + 4 MULTIPART/MIXED + 4.1 IMAGE/GIF + 4.1.MIME ([MIME-IMB] header for the IMAGE/GIF) + 4.2 MESSAGE/RFC822 + 4.2.HEADER ([RFC-822] header of the message) + 4.2.TEXT ([RFC-822] text body of the message) + 4.2.1 TEXT/PLAIN + 4.2.2 MULTIPART/ALTERNATIVE + 4.2.2.1 TEXT/PLAIN + 4.2.2.2 TEXT/RICHTEXT + + + It is possible to fetch a substring of the + designated text. This is done by appending an open + angle bracket ("<"), the octet position of the + first desired octet, a period, the maximum number + of octets desired, and a close angle bracket (">") + to the part specifier. If the starting octet is + beyond the end of the text, an empty string is + returned. + + Any partial fetch that attempts to read beyond the + end of the text is truncated as appropriate. A + partial fetch that starts at octet 0 is returned as + a partial fetch, even if this truncation happened. + + Note: this means that BODY[]<0.2048> of a + 1500-octet message will return BODY[]<0> + with a literal of size 1500, not BODY[]. + + Note: a substring fetch of a + HEADER.FIELDS or HEADER.FIELDS.NOT part + specifier is calculated after subsetting + the header. + + + + + +Crispin Standards Track [Page 43] + +RFC 2060 IMAP4rev1 December 1996 + + + The \Seen flag is implicitly set; if this causes + the flags to change they SHOULD be included as part + of the FETCH responses. + + BODY.PEEK[
]<> An alternate form of + BODY[
] that does not implicitly set the + \Seen flag. + + BODYSTRUCTURE The [MIME-IMB] body structure of the message. This + is computed by the server by parsing the [MIME-IMB] + header fields in the [RFC-822] header and + [MIME-IMB] headers. + + ENVELOPE The envelope structure of the message. This is + computed by the server by parsing the [RFC-822] + header into the component parts, defaulting various + fields as necessary. + + FAST Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE) + + FLAGS The flags that are set for this message. + + FULL Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE ENVELOPE BODY) + + INTERNALDATE The internal date of the message. + + RFC822 Functionally equivalent to BODY[], differing in the + syntax of the resulting untagged FETCH data (RFC822 + is returned). + + RFC822.HEADER Functionally equivalent to BODY.PEEK[HEADER], + differing in the syntax of the resulting untagged + FETCH data (RFC822.HEADER is returned). + + RFC822.SIZE The [RFC-822] size of the message. + + RFC822.TEXT Functionally equivalent to BODY[TEXT], differing in + the syntax of the resulting untagged FETCH data + (RFC822.TEXT is returned). + + UID The unique identifier for the message. + + + + + + + + +Crispin Standards Track [Page 44] + +RFC 2060 IMAP4rev1 December 1996 + + + Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) + S: * 2 FETCH .... + S: * 3 FETCH .... + S: * 4 FETCH .... + S: A654 OK FETCH completed + +6.4.6. STORE Command + + Arguments: message set + message data item name + value for message data item + + Responses: untagged responses: FETCH + + Result: OK - store completed + NO - store error: can't store that data + BAD - command unknown or arguments invalid + + The STORE command alters data associated with a message in the + mailbox. Normally, STORE will return the updated value of the + data with an untagged FETCH response. A suffix of ".SILENT" in + the data item name prevents the untagged FETCH, and the server + SHOULD assume that the client has determined the updated value + itself or does not care about the updated value. + + Note: regardless of whether or not the ".SILENT" suffix was + used, the server SHOULD send an untagged FETCH response if a + change to a message's flags from an external source is + observed. The intent is that the status of the flags is + determinate without a race condition. + + The currently defined data items that can be stored are: + + FLAGS + Replace the flags for the message with the + argument. The new value of the flags are returned + as if a FETCH of those flags was done. + + FLAGS.SILENT + Equivalent to FLAGS, but without returning a new + value. + + +FLAGS + Add the argument to the flags for the message. The + new value of the flags are returned as if a FETCH + of those flags was done. + + + + + +Crispin Standards Track [Page 45] + +RFC 2060 IMAP4rev1 December 1996 + + + +FLAGS.SILENT + Equivalent to +FLAGS, but without returning a new + value. + + -FLAGS + Remove the argument from the flags for the message. + The new value of the flags are returned as if a + FETCH of those flags was done. + + -FLAGS.SILENT + Equivalent to -FLAGS, but without returning a new + value. + + Example: C: A003 STORE 2:4 +FLAGS (\Deleted) + S: * 2 FETCH FLAGS (\Deleted \Seen) + S: * 3 FETCH FLAGS (\Deleted) + S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen) + S: A003 OK STORE completed + +6.4.7. COPY Command + + Arguments: message set + mailbox name + + Responses: no specific responses for this command + + Result: OK - copy completed + NO - copy error: can't copy those messages or to that + name + BAD - command unknown or arguments invalid + + The COPY command copies the specified message(s) to the end of the + specified destination mailbox. The flags and internal date of the + message(s) SHOULD be preserved in the copy. + + If the destination mailbox does not exist, a server SHOULD return + an error. It SHOULD NOT automatically create the mailbox. Unless + it is certain that the destination mailbox can not be created, the + server MUST send the response code "[TRYCREATE]" as the prefix of + the text of the tagged NO response. This gives a hint to the + client that it can attempt a CREATE command and retry the COPY if + the CREATE is successful. + + + + + + + + + +Crispin Standards Track [Page 46] + +RFC 2060 IMAP4rev1 December 1996 + + + If the COPY command is unsuccessful for any reason, server + implementations MUST restore the destination mailbox to its state + before the COPY attempt. + + Example: C: A003 COPY 2:4 MEETING + S: A003 OK COPY completed + +6.4.8. UID Command + + Arguments: command name + command arguments + + Responses: untagged responses: FETCH, SEARCH + + Result: OK - UID command completed + NO - UID command error + BAD - command unknown or arguments invalid + + The UID command has two forms. In the first form, it takes as its + arguments a COPY, FETCH, or STORE command with arguments + appropriate for the associated command. However, the numbers in + the message set argument are unique identifiers instead of message + sequence numbers. + + In the second form, the UID command takes a SEARCH command with + SEARCH command arguments. The interpretation of the arguments is + the same as with SEARCH; however, the numbers returned in a SEARCH + response for a UID SEARCH command are unique identifiers instead + of message sequence numbers. For example, the command UID SEARCH + 1:100 UID 443:557 returns the unique identifiers corresponding to + the intersection of the message sequence number set 1:100 and the + UID set 443:557. + + Message set ranges are permitted; however, there is no guarantee + that unique identifiers be contiguous. A non-existent unique + identifier within a message set range is ignored without any error + message generated. + + The number after the "*" in an untagged FETCH response is always a + message sequence number, not a unique identifier, even for a UID + command response. However, server implementations MUST implicitly + include the UID message data item as part of any FETCH response + caused by a UID command, regardless of whether a UID was specified + as a message data item to the FETCH. + + + + + + + +Crispin Standards Track [Page 47] + +RFC 2060 IMAP4rev1 December 1996 + + + Example: C: A999 UID FETCH 4827313:4828442 FLAGS + S: * 23 FETCH (FLAGS (\Seen) UID 4827313) + S: * 24 FETCH (FLAGS (\Seen) UID 4827943) + S: * 25 FETCH (FLAGS (\Seen) UID 4828442) + S: A999 UID FETCH completed + +6.5. Client Commands - Experimental/Expansion + +6.5.1. X Command + + Arguments: implementation defined + + Responses: implementation defined + + Result: OK - command completed + NO - failure + BAD - command unknown or arguments invalid + + Any command prefixed with an X is an experimental command. + Commands which are not part of this specification, a standard or + standards-track revision of this specification, or an IESG- + approved experimental protocol, MUST use the X prefix. + + Any added untagged responses issued by an experimental command + MUST also be prefixed with an X. Server implementations MUST NOT + send any such untagged responses, unless the client requested it + by issuing the associated experimental command. + + Example: C: a441 CAPABILITY + S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN + S: a441 OK CAPABILITY completed + C: A442 XPIG-LATIN + S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay + S: A442 OK XPIG-LATIN ompleted-cay + +7. Server Responses + + Server responses are in three forms: status responses, server data, + and command continuation request. The information contained in a + server response, identified by "Contents:" in the response + descriptions below, is described by function, not by syntax. The + precise syntax of server responses is described in the Formal Syntax + section. + + The client MUST be prepared to accept any response at all times. + + + + + + +Crispin Standards Track [Page 48] + +RFC 2060 IMAP4rev1 December 1996 + + + Status responses can be tagged or untagged. Tagged status responses + indicate the completion result (OK, NO, or BAD status) of a client + command, and have a tag matching the command. + + Some status responses, and all server data, are untagged. An + untagged response is indicated by the token "*" instead of a tag. + Untagged status responses indicate server greeting, or server status + that does not indicate the completion of a command (for example, an + impending system shutdown alert). For historical reasons, untagged + server data responses are also called "unsolicited data", although + strictly speaking only unilateral server data is truly "unsolicited". + + Certain server data MUST be recorded by the client when it is + received; this is noted in the description of that data. Such data + conveys critical information which affects the interpretation of all + subsequent commands and responses (e.g. updates reflecting the + creation or destruction of messages). + + Other server data SHOULD be recorded for later reference; if the + client does not need to record the data, or if recording the data has + no obvious purpose (e.g. a SEARCH response when no SEARCH command is + in progress), the data SHOULD be ignored. + + An example of unilateral untagged server data occurs when the IMAP + connection is in selected state. In selected state, the server + checks the mailbox for new messages as part of command execution. + Normally, this is part of the execution of every command; hence, a + NOOP command suffices to check for new messages. If new messages are + found, the server sends untagged EXISTS and RECENT responses + reflecting the new size of the mailbox. Server implementations that + offer multiple simultaneous access to the same mailbox SHOULD also + send appropriate unilateral untagged FETCH and EXPUNGE responses if + another agent changes the state of any message flags or expunges any + messages. + + Command continuation request responses use the token "+" instead of a + tag. These responses are sent by the server to indicate acceptance + of an incomplete client command and readiness for the remainder of + the command. + +7.1. Server Responses - Status Responses + + Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD + may be tagged or untagged. PREAUTH and BYE are always untagged. + + Status responses MAY include an OPTIONAL "response code". A response + code consists of data inside square brackets in the form of an atom, + possibly followed by a space and arguments. The response code + + + +Crispin Standards Track [Page 49] + +RFC 2060 IMAP4rev1 December 1996 + + + contains additional information or status codes for client software + beyond the OK/NO/BAD condition, and are defined when there is a + specific action that a client can take based upon the additional + information. + + The currently defined response codes are: + + ALERT The human-readable text contains a special alert + that MUST be presented to the user in a fashion + that calls the user's attention to the message. + + NEWNAME Followed by a mailbox name and a new mailbox name. + A SELECT or EXAMINE is failing because the target + mailbox name no longer exists because it was + renamed to the new mailbox name. This is a hint to + the client that the operation can succeed if the + SELECT or EXAMINE is reissued with the new mailbox + name. + + PARSE The human-readable text represents an error in + parsing the [RFC-822] header or [MIME-IMB] headers + of a message in the mailbox. + + PERMANENTFLAGS Followed by a parenthesized list of flags, + indicates which of the known flags that the client + can change permanently. Any flags that are in the + FLAGS untagged response, but not the PERMANENTFLAGS + list, can not be set permanently. If the client + attempts to STORE a flag that is not in the + PERMANENTFLAGS list, the server will either reject + it with a NO reply or store the state for the + remainder of the current session only. The + PERMANENTFLAGS list can also include the special + flag \*, which indicates that it is possible to + create new keywords by attempting to store those + flags in the mailbox. + + READ-ONLY The mailbox is selected read-only, or its access + while selected has changed from read-write to + read-only. + + READ-WRITE The mailbox is selected read-write, or its access + while selected has changed from read-only to + read-write. + + + + + + + +Crispin Standards Track [Page 50] + +RFC 2060 IMAP4rev1 December 1996 + + + TRYCREATE An APPEND or COPY attempt is failing because the + target mailbox does not exist (as opposed to some + other reason). This is a hint to the client that + the operation can succeed if the mailbox is first + created by the CREATE command. + + UIDVALIDITY Followed by a decimal number, indicates the unique + identifier validity value. + + UNSEEN Followed by a decimal number, indicates the number + of the first message without the \Seen flag set. + + Additional response codes defined by particular client or server + implementations SHOULD be prefixed with an "X" until they are + added to a revision of this protocol. Client implementations + SHOULD ignore response codes that they do not recognize. + +7.1.1. OK Response + + Contents: OPTIONAL response code + human-readable text + + The OK response indicates an information message from the server. + When tagged, it indicates successful completion of the associated + command. The human-readable text MAY be presented to the user as + an information message. The untagged form indicates an + information-only message; the nature of the information MAY be + indicated by a response code. + + The untagged form is also used as one of three possible greetings + at connection startup. It indicates that the connection is not + yet authenticated and that a LOGIN command is needed. + + Example: S: * OK IMAP4rev1 server ready + C: A001 LOGIN fred blurdybloop + S: * OK [ALERT] System shutdown in 10 minutes + S: A001 OK LOGIN Completed + +7.1.2. NO Response + + Contents: OPTIONAL response code + human-readable text + + The NO response indicates an operational error message from the + server. When tagged, it indicates unsuccessful completion of the + associated command. The untagged form indicates a warning; the + command can still complete successfully. The human-readable text + describes the condition. + + + +Crispin Standards Track [Page 51] + +RFC 2060 IMAP4rev1 December 1996 + + + Example: C: A222 COPY 1:2 owatagusiam + S: * NO Disk is 98% full, please delete unnecessary data + S: A222 OK COPY completed + C: A223 COPY 3:200 blurdybloop + S: * NO Disk is 98% full, please delete unnecessary data + S: * NO Disk is 99% full, please delete unnecessary data + S: A223 NO COPY failed: disk is full + +7.1.3. BAD Response + + Contents: OPTIONAL response code + human-readable text + + The BAD response indicates an error message from the server. When + tagged, it reports a protocol-level error in the client's command; + the tag indicates the command that caused the error. The untagged + form indicates a protocol-level error for which the associated + command can not be determined; it can also indicate an internal + server failure. The human-readable text describes the condition. + + Example: C: ...very long command line... + S: * BAD Command line too long + C: ...empty line... + S: * BAD Empty command line + C: A443 EXPUNGE + S: * BAD Disk crash, attempting salvage to a new disk! + S: * OK Salvage successful, no data lost + S: A443 OK Expunge completed + +7.1.4. PREAUTH Response + + Contents: OPTIONAL response code + human-readable text + + The PREAUTH response is always untagged, and is one of three + possible greetings at connection startup. It indicates that the + connection has already been authenticated by external means and + thus no LOGIN command is needed. + + Example: S: * PREAUTH IMAP4rev1 server logged in as Smith + +7.1.5. BYE Response + + Contents: OPTIONAL response code + human-readable text + + + + + + +Crispin Standards Track [Page 52] + +RFC 2060 IMAP4rev1 December 1996 + + + The BYE response is always untagged, and indicates that the server + is about to close the connection. The human-readable text MAY be + displayed to the user in a status report by the client. The BYE + response is sent under one of four conditions: + + 1) as part of a normal logout sequence. The server will close + the connection after sending the tagged OK response to the + LOGOUT command. + + 2) as a panic shutdown announcement. The server closes the + connection immediately. + + 3) as an announcement of an inactivity autologout. The server + closes the connection immediately. + + 4) as one of three possible greetings at connection startup, + indicating that the server is not willing to accept a + connection from this client. The server closes the + connection immediately. + + The difference between a BYE that occurs as part of a normal + LOGOUT sequence (the first case) and a BYE that occurs because of + a failure (the other three cases) is that the connection closes + immediately in the failure case. + + Example: S: * BYE Autologout; idle for too long + +7.2. Server Responses - Server and Mailbox Status + + These responses are always untagged. This is how server and mailbox + status data are transmitted from the server to the client. Many of + these responses typically result from a command with the same name. + +7.2.1. CAPABILITY Response + + Contents: capability listing + + The CAPABILITY response occurs as a result of a CAPABILITY + command. The capability listing contains a space-separated + listing of capability names that the server supports. The + capability listing MUST include the atom "IMAP4rev1". + + A capability name which begins with "AUTH=" indicates that the + server supports that particular authentication mechanism. + + + + + + + +Crispin Standards Track [Page 53] + +RFC 2060 IMAP4rev1 December 1996 + + + Other capability names indicate that the server supports an + extension, revision, or amendment to the IMAP4rev1 protocol. + Server responses MUST conform to this document until the client + issues a command that uses the associated capability. + + Capability names MUST either begin with "X" or be standard or + standards-track IMAP4rev1 extensions, revisions, or amendments + registered with IANA. A server MUST NOT offer unregistered or + non-standard capability names, unless such names are prefixed with + an "X". + + Client implementations SHOULD NOT require any capability name + other than "IMAP4rev1", and MUST ignore any unknown capability + names. + + Example: S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN + +7.2.2. LIST Response + + Contents: name attributes + hierarchy delimiter + name + + The LIST response occurs as a result of a LIST command. It + returns a single name that matches the LIST specification. There + can be multiple LIST responses for a single LIST command. + + Four name attributes are defined: + + \Noinferiors It is not possible for any child levels of + hierarchy to exist under this name; no child levels + exist now and none can be created in the future. + + \Noselect It is not possible to use this name as a selectable + mailbox. + + \Marked The mailbox has been marked "interesting" by the + server; the mailbox probably contains messages that + have been added since the last time the mailbox was + selected. + + \Unmarked The mailbox does not contain any additional + messages since the last time the mailbox was + selected. + + If it is not feasible for the server to determine whether the + mailbox is "interesting" or not, or if the name is a \Noselect + name, the server SHOULD NOT send either \Marked or \Unmarked. + + + +Crispin Standards Track [Page 54] + +RFC 2060 IMAP4rev1 December 1996 + + + The hierarchy delimiter is a character used to delimit levels of + hierarchy in a mailbox name. A client can use it to create child + mailboxes, and to search higher or lower levels of naming + hierarchy. All children of a top-level hierarchy node MUST use + the same separator character. A NIL hierarchy delimiter means + that no hierarchy exists; the name is a "flat" name. + + The name represents an unambiguous left-to-right hierarchy, and + MUST be valid for use as a reference in LIST and LSUB commands. + Unless \Noselect is indicated, the name MUST also be valid as an + argument for commands, such as SELECT, that accept mailbox + names. + + Example: S: * LIST (\Noselect) "/" ~/Mail/foo + +7.2.3. LSUB Response + + Contents: name attributes + hierarchy delimiter + name + + The LSUB response occurs as a result of an LSUB command. It + returns a single name that matches the LSUB specification. There + can be multiple LSUB responses for a single LSUB command. The + data is identical in format to the LIST response. + + Example: S: * LSUB () "." #news.comp.mail.misc + +7.2.4 STATUS Response + + Contents: name + status parenthesized list + + The STATUS response occurs as a result of an STATUS command. It + returns the mailbox name that matches the STATUS specification and + the requested mailbox status information. + + Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) + +7.2.5. SEARCH Response + + Contents: zero or more numbers + + + + + + + + + +Crispin Standards Track [Page 55] + +RFC 2060 IMAP4rev1 December 1996 + + + The SEARCH response occurs as a result of a SEARCH or UID SEARCH + command. The number(s) refer to those messages that match the + search criteria. For SEARCH, these are message sequence numbers; + for UID SEARCH, these are unique identifiers. Each number is + delimited by a space. + + Example: S: * SEARCH 2 3 6 + +7.2.6. FLAGS Response + + Contents: flag parenthesized list + + The FLAGS response occurs as a result of a SELECT or EXAMINE + command. The flag parenthesized list identifies the flags (at a + minimum, the system-defined flags) that are applicable for this + mailbox. Flags other than the system flags can also exist, + depending on server implementation. + + The update from the FLAGS response MUST be recorded by the client. + + Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + +7.3. Server Responses - Mailbox Size + + These responses are always untagged. This is how changes in the size + of the mailbox are trasnmitted from the server to the client. + Immediately following the "*" token is a number that represents a + message count. + +7.3.1. EXISTS Response + + Contents: none + + The EXISTS response reports the number of messages in the mailbox. + This response occurs as a result of a SELECT or EXAMINE command, + and if the size of the mailbox changes (e.g. new mail). + + The update from the EXISTS response MUST be recorded by the + client. + + Example: S: * 23 EXISTS + + + + + + + + + + +Crispin Standards Track [Page 56] + +RFC 2060 IMAP4rev1 December 1996 + + +7.3.2. RECENT Response + + Contents: none + + The RECENT response reports the number of messages with the + \Recent flag set. This response occurs as a result of a SELECT or + EXAMINE command, and if the size of the mailbox changes (e.g. new + mail). + + Note: It is not guaranteed that the message sequence numbers of + recent messages will be a contiguous range of the highest n + messages in the mailbox (where n is the value reported by the + RECENT response). Examples of situations in which this is not + the case are: multiple clients having the same mailbox open + (the first session to be notified will see it as recent, others + will probably see it as non-recent), and when the mailbox is + re-ordered by a non-IMAP agent. + + The only reliable way to identify recent messages is to look at + message flags to see which have the \Recent flag set, or to do + a SEARCH RECENT. + + The update from the RECENT response MUST be recorded by the + client. + + Example: S: * 5 RECENT + +7.4. Server Responses - Message Status + + These responses are always untagged. This is how message data are + transmitted from the server to the client, often as a result of a + command with the same name. Immediately following the "*" token is a + number that represents a message sequence number. + +7.4.1. EXPUNGE Response + + Contents: none + + The EXPUNGE response reports that the specified message sequence + number has been permanently removed from the mailbox. The message + sequence number for each successive message in the mailbox is + immediately decremented by 1, and this decrement is reflected in + message sequence numbers in subsequent responses (including other + untagged EXPUNGE responses). + + As a result of the immediate decrement rule, message sequence + numbers that appear in a set of successive EXPUNGE responses + depend upon whether the messages are removed starting from lower + + + +Crispin Standards Track [Page 57] + +RFC 2060 IMAP4rev1 December 1996 + + + numbers to higher numbers, or from higher numbers to lower + numbers. For example, if the last 5 messages in a 9-message + mailbox are expunged; a "lower to higher" server will send five + untagged EXPUNGE responses for message sequence number 5, whereas + a "higher to lower server" will send successive untagged EXPUNGE + responses for message sequence numbers 9, 8, 7, 6, and 5. + + An EXPUNGE response MUST NOT be sent when no command is in + progress; nor while responding to a FETCH, STORE, or SEARCH + command. This rule is necessary to prevent a loss of + synchronization of message sequence numbers between client and + server. + + The update from the EXPUNGE response MUST be recorded by the + client. + + Example: S: * 44 EXPUNGE + +7.4.2. FETCH Response + + Contents: message data + + The FETCH response returns data about a message to the client. + The data are pairs of data item names and their values in + parentheses. This response occurs as the result of a FETCH or + STORE command, as well as by unilateral server decision (e.g. flag + updates). + + The current data items are: + + BODY A form of BODYSTRUCTURE without extension data. + + BODY[
]<> + A string expressing the body contents of the + specified section. The string SHOULD be + interpreted by the client according to the content + transfer encoding, body type, and subtype. + + If the origin octet is specified, this string is a + substring of the entire body contents, starting at + that origin octet. This means that BODY[]<0> MAY + be truncated, but BODY[] is NEVER truncated. + + 8-bit textual data is permitted if a [CHARSET] + identifier is part of the body parameter + parenthesized list for this section. Note that + headers (part specifiers HEADER or MIME, or the + header portion of a MESSAGE/RFC822 part), MUST be + + + +Crispin Standards Track [Page 58] + +RFC 2060 IMAP4rev1 December 1996 + + + 7-bit; 8-bit characters are not permitted in + headers. Note also that the blank line at the end + of the header is always included in header data. + + Non-textual data such as binary data MUST be + transfer encoded into a textual form such as BASE64 + prior to being sent to the client. To derive the + original binary data, the client MUST decode the + transfer encoded string. + + BODYSTRUCTURE A parenthesized list that describes the [MIME-IMB] + body structure of a message. This is computed by + the server by parsing the [MIME-IMB] header fields, + defaulting various fields as necessary. + + For example, a simple text message of 48 lines and + 2279 octets can have a body structure of: ("TEXT" + "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 + 48) + + Multiple parts are indicated by parenthesis + nesting. Instead of a body type as the first + element of the parenthesized list there is a nested + body. The second element of the parenthesized list + is the multipart subtype (mixed, digest, parallel, + alternative, etc.). + + For example, a two part message consisting of a + text and a BASE645-encoded text attachment can have + a body structure of: (("TEXT" "PLAIN" ("CHARSET" + "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN" + ("CHARSET" "US-ASCII" "NAME" "cc.diff") + "<960723163407.20117h@cac.washington.edu>" + "Compiler diff" "BASE64" 4554 73) "MIXED")) + + Extension data follows the multipart subtype. + Extension data is never returned with the BODY + fetch, but can be returned with a BODYSTRUCTURE + fetch. Extension data, if present, MUST be in the + defined order. + + The extension data of a multipart body part are in + the following order: + + body parameter parenthesized list + A parenthesized list of attribute/value pairs + [e.g. ("foo" "bar" "baz" "rag") where "bar" is + the value of "foo" and "rag" is the value of + + + +Crispin Standards Track [Page 59] + +RFC 2060 IMAP4rev1 December 1996 + + + "baz"] as defined in [MIME-IMB]. + + body disposition + A parenthesized list, consisting of a + disposition type string followed by a + parenthesized list of disposition + attribute/value pairs. The disposition type and + attribute names will be defined in a future + standards-track revision to [DISPOSITION]. + + body language + A string or parenthesized list giving the body + language value as defined in [LANGUAGE-TAGS]. + + Any following extension data are not yet defined in + this version of the protocol. Such extension data + can consist of zero or more NILs, strings, numbers, + or potentially nested parenthesized lists of such + data. Client implementations that do a + BODYSTRUCTURE fetch MUST be prepared to accept such + extension data. Server implementations MUST NOT + send such extension data until it has been defined + by a revision of this protocol. + + The basic fields of a non-multipart body part are + in the following order: + + body type + A string giving the content media type name as + defined in [MIME-IMB]. + + body subtype + A string giving the content subtype name as + defined in [MIME-IMB]. + + body parameter parenthesized list + A parenthesized list of attribute/value pairs + [e.g. ("foo" "bar" "baz" "rag") where "bar" is + the value of "foo" and "rag" is the value of + "baz"] as defined in [MIME-IMB]. + + body id + A string giving the content id as defined in + [MIME-IMB]. + + body description + A string giving the content description as + defined in [MIME-IMB]. + + + +Crispin Standards Track [Page 60] + +RFC 2060 IMAP4rev1 December 1996 + + + body encoding + A string giving the content transfer encoding as + defined in [MIME-IMB]. + + body size + A number giving the size of the body in octets. + Note that this size is the size in its transfer + encoding and not the resulting size after any + decoding. + + A body type of type MESSAGE and subtype RFC822 + contains, immediately after the basic fields, the + envelope structure, body structure, and size in + text lines of the encapsulated message. + + A body type of type TEXT contains, immediately + after the basic fields, the size of the body in + text lines. Note that this size is the size in its + content transfer encoding and not the resulting + size after any decoding. + + Extension data follows the basic fields and the + type-specific fields listed above. Extension data + is never returned with the BODY fetch, but can be + returned with a BODYSTRUCTURE fetch. Extension + data, if present, MUST be in the defined order. + + The extension data of a non-multipart body part are + in the following order: + + body MD5 + A string giving the body MD5 value as defined in + [MD5]. + + body disposition + A parenthesized list with the same content and + function as the body disposition for a multipart + body part. + + body language + A string or parenthesized list giving the body + language value as defined in [LANGUAGE-TAGS]. + + Any following extension data are not yet defined in + this version of the protocol, and would be as + described above under multipart extension data. + + + + + +Crispin Standards Track [Page 61] + +RFC 2060 IMAP4rev1 December 1996 + + + ENVELOPE A parenthesized list that describes the envelope + structure of a message. This is computed by the + server by parsing the [RFC-822] header into the + component parts, defaulting various fields as + necessary. + + The fields of the envelope structure are in the + following order: date, subject, from, sender, + reply-to, to, cc, bcc, in-reply-to, and message-id. + The date, subject, in-reply-to, and message-id + fields are strings. The from, sender, reply-to, + to, cc, and bcc fields are parenthesized lists of + address structures. + + An address structure is a parenthesized list that + describes an electronic mail address. The fields + of an address structure are in the following order: + personal name, [SMTP] at-domain-list (source + route), mailbox name, and host name. + + [RFC-822] group syntax is indicated by a special + form of address structure in which the host name + field is NIL. If the mailbox name field is also + NIL, this is an end of group marker (semi-colon in + RFC 822 syntax). If the mailbox name field is + non-NIL, this is a start of group marker, and the + mailbox name field holds the group name phrase. + + Any field of an envelope or address structure that + is not applicable is presented as NIL. Note that + the server MUST default the reply-to and sender + fields from the from field; a client is not + expected to know to do this. + + FLAGS A parenthesized list of flags that are set for this + message. + + INTERNALDATE A string representing the internal date of the + message. + + RFC822 Equivalent to BODY[]. + + RFC822.HEADER Equivalent to BODY.PEEK[HEADER]. + + RFC822.SIZE A number expressing the [RFC-822] size of the + message. + + RFC822.TEXT Equivalent to BODY[TEXT]. + + + +Crispin Standards Track [Page 62] + +RFC 2060 IMAP4rev1 December 1996 + + + UID A number expressing the unique identifier of the + message. + + + Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827) + +7.5. Server Responses - Command Continuation Request + + The command continuation request response is indicated by a "+" token + instead of a tag. This form of response indicates that the server is + ready to accept the continuation of a command from the client. The + remainder of this response is a line of text. + + This response is used in the AUTHORIZATION command to transmit server + data to the client, and request additional client data. This + response is also used if an argument to any command is a literal. + + The client is not permitted to send the octets of the literal unless + the server indicates that it expects it. This permits the server to + process commands and reject errors on a line-by-line basis. The + remainder of the command, including the CRLF that terminates a + command, follows the octets of the literal. If there are any + additional command arguments the literal octets are followed by a + space and those arguments. + + Example: C: A001 LOGIN {11} + S: + Ready for additional command text + C: FRED FOOBAR {7} + S: + Ready for additional command text + C: fat man + S: A001 OK LOGIN completed + C: A044 BLURDYBLOOP {102856} + S: A044 BAD No such command as "BLURDYBLOOP" + +8. Sample IMAP4rev1 connection + + The following is a transcript of an IMAP4rev1 connection. A long + line in this sample is broken for editorial clarity. + +S: * OK IMAP4rev1 Service Ready +C: a001 login mrc secret +S: a001 OK LOGIN completed +C: a002 select inbox +S: * 18 EXISTS +S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) +S: * 2 RECENT +S: * OK [UNSEEN 17] Message 17 is the first unseen message +S: * OK [UIDVALIDITY 3857529045] UIDs valid + + + +Crispin Standards Track [Page 63] + +RFC 2060 IMAP4rev1 December 1996 + + +S: a002 OK [READ-WRITE] SELECT completed +C: a003 fetch 12 full +S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700" + RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)" + "IMAP4rev1 WG mtg summary and minutes" + (("Terry Gray" NIL "gray" "cac.washington.edu")) + (("Terry Gray" NIL "gray" "cac.washington.edu")) + (("Terry Gray" NIL "gray" "cac.washington.edu")) + ((NIL NIL "imap" "cac.washington.edu")) + ((NIL NIL "minutes" "CNRI.Reston.VA.US") + ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL + "") + BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92)) +S: a003 OK FETCH completed +C: a004 fetch 12 body[header] +S: * 12 FETCH (BODY[HEADER] {350} +S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT) +S: From: Terry Gray +S: Subject: IMAP4rev1 WG mtg summary and minutes +S: To: imap@cac.washington.edu +S: cc: minutes@CNRI.Reston.VA.US, John Klensin +S: Message-Id: +S: MIME-Version: 1.0 +S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII +S: +S: ) +S: a004 OK FETCH completed +C: a005 store 12 +flags \deleted +S: * 12 FETCH (FLAGS (\Seen \Deleted)) +S: a005 OK +FLAGS completed +C: a006 logout +S: * BYE IMAP4rev1 server terminating connection +S: a006 OK LOGOUT completed + +9. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in [RFC-822] with one exception; the + delimiter used with the "#" construct is a single space (SPACE) and + not one or more commas. + + In the case of alternative or optional rules in which a later rule + overlaps an earlier rule, the rule which is listed earlier MUST take + priority. For example, "\Seen" when parsed as a flag is the \Seen + flag name and not a flag_extension, even though "\Seen" could be + parsed as a flag_extension. Some, but not all, instances of this + rule are noted below. + + + + +Crispin Standards Track [Page 64] + +RFC 2060 IMAP4rev1 December 1996 + + + Except as noted otherwise, all alphabetic characters are case- + insensitive. The use of upper or lower case characters to define + token strings is for editorial clarity only. Implementations MUST + accept these strings in a case-insensitive fashion. + +address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox + SPACE addr_host ")" + +addr_adl ::= nstring + ;; Holds route from [RFC-822] route-addr if + ;; non-NIL + +addr_host ::= nstring + ;; NIL indicates [RFC-822] group syntax. + ;; Otherwise, holds [RFC-822] domain name + +addr_mailbox ::= nstring + ;; NIL indicates end of [RFC-822] group; if + ;; non-NIL and addr_host is NIL, holds + ;; [RFC-822] group name. + ;; Otherwise, holds [RFC-822] local-part + +addr_name ::= nstring + ;; Holds phrase from [RFC-822] mailbox if + ;; non-NIL + +alpha ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / + "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / + "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / + "Y" / "Z" / + "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / + "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / + "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / + "y" / "z" + ;; Case-sensitive + +append ::= "APPEND" SPACE mailbox [SPACE flag_list] + [SPACE date_time] SPACE literal + +astring ::= atom / string + +atom ::= 1*ATOM_CHAR + +ATOM_CHAR ::= + +atom_specials ::= "(" / ")" / "{" / SPACE / CTL / list_wildcards / + quoted_specials + + + + +Crispin Standards Track [Page 65] + +RFC 2060 IMAP4rev1 December 1996 + + +authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64) + +auth_type ::= atom + ;; Defined by [IMAP-AUTH] + +base64 ::= *(4base64_char) [base64_terminal] + +base64_char ::= alpha / digit / "+" / "/" + +base64_terminal ::= (2base64_char "==") / (3base64_char "=") + +body ::= "(" body_type_1part / body_type_mpart ")" + +body_extension ::= nstring / number / "(" 1#body_extension ")" + ;; Future expansion. Client implementations + ;; MUST accept body_extension fields. Server + ;; implementations MUST NOT generate + ;; body_extension fields except as defined by + ;; future standard or standards-track + ;; revisions of this specification. + +body_ext_1part ::= body_fld_md5 [SPACE body_fld_dsp + [SPACE body_fld_lang + [SPACE 1#body_extension]]] + ;; MUST NOT be returned on non-extensible + ;; "BODY" fetch + +body_ext_mpart ::= body_fld_param + [SPACE body_fld_dsp SPACE body_fld_lang + [SPACE 1#body_extension]] + ;; MUST NOT be returned on non-extensible + ;; "BODY" fetch + +body_fields ::= body_fld_param SPACE body_fld_id SPACE + body_fld_desc SPACE body_fld_enc SPACE + body_fld_octets + +body_fld_desc ::= nstring + +body_fld_dsp ::= "(" string SPACE body_fld_param ")" / nil + +body_fld_enc ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/ + "QUOTED-PRINTABLE") <">) / string + +body_fld_id ::= nstring + +body_fld_lang ::= nstring / "(" 1#string ")" + + + + +Crispin Standards Track [Page 66] + +RFC 2060 IMAP4rev1 December 1996 + + +body_fld_lines ::= number + +body_fld_md5 ::= nstring + +body_fld_octets ::= number + +body_fld_param ::= "(" 1#(string SPACE string) ")" / nil + +body_type_1part ::= (body_type_basic / body_type_msg / body_type_text) + [SPACE body_ext_1part] + +body_type_basic ::= media_basic SPACE body_fields + ;; MESSAGE subtype MUST NOT be "RFC822" + +body_type_mpart ::= 1*body SPACE media_subtype + [SPACE body_ext_mpart] + +body_type_msg ::= media_message SPACE body_fields SPACE envelope + SPACE body SPACE body_fld_lines + +body_type_text ::= media_text SPACE body_fields SPACE body_fld_lines + +capability ::= "AUTH=" auth_type / atom + ;; New capabilities MUST begin with "X" or be + ;; registered with IANA as standard or + ;; standards-track + +capability_data ::= "CAPABILITY" SPACE [1#capability SPACE] "IMAP4rev1" + [SPACE 1#capability] + ;; IMAP4rev1 servers which offer RFC 1730 + ;; compatibility MUST list "IMAP4" as the first + ;; capability. + +CHAR ::= + +CHAR8 ::= + +command ::= tag SPACE (command_any / command_auth / + command_nonauth / command_select) CRLF + ;; Modal based on state + +command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command + ;; Valid in all states + +command_auth ::= append / create / delete / examine / list / lsub / + rename / select / status / subscribe / unsubscribe + ;; Valid only in Authenticated or Selected state + + + +Crispin Standards Track [Page 67] + +RFC 2060 IMAP4rev1 December 1996 + + +command_nonauth ::= login / authenticate + ;; Valid only when in Non-Authenticated state + +command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" / + copy / fetch / store / uid / search + ;; Valid only when in Selected state + +continue_req ::= "+" SPACE (resp_text / base64) + +copy ::= "COPY" SPACE set SPACE mailbox + +CR ::= + +create ::= "CREATE" SPACE mailbox + ;; Use of INBOX gives a NO error + +CRLF ::= CR LF + +CTL ::= + +date ::= date_text / <"> date_text <"> + +date_day ::= 1*2digit + ;; Day of month + +date_day_fixed ::= (SPACE digit) / 2digit + ;; Fixed-format version of date_day + +date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / + "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" + +date_text ::= date_day "-" date_month "-" date_year + +date_year ::= 4digit + +date_time ::= <"> date_day_fixed "-" date_month "-" date_year + SPACE time SPACE zone <"> + +delete ::= "DELETE" SPACE mailbox + ;; Use of INBOX gives a NO error + +digit ::= "0" / digit_nz + +digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / + "9" + + + + + +Crispin Standards Track [Page 68] + +RFC 2060 IMAP4rev1 December 1996 + + +envelope ::= "(" env_date SPACE env_subject SPACE env_from + SPACE env_sender SPACE env_reply_to SPACE env_to + SPACE env_cc SPACE env_bcc SPACE env_in_reply_to + SPACE env_message_id ")" + +env_bcc ::= "(" 1*address ")" / nil + +env_cc ::= "(" 1*address ")" / nil + +env_date ::= nstring + +env_from ::= "(" 1*address ")" / nil + +env_in_reply_to ::= nstring + +env_message_id ::= nstring + +env_reply_to ::= "(" 1*address ")" / nil + +env_sender ::= "(" 1*address ")" / nil + +env_subject ::= nstring + +env_to ::= "(" 1*address ")" / nil + +examine ::= "EXAMINE" SPACE mailbox + +fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" / + "FAST" / fetch_att / "(" 1#fetch_att ")") + +fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / + "RFC822" [".HEADER" / ".SIZE" / ".TEXT"] / + "BODY" ["STRUCTURE"] / "UID" / + "BODY" [".PEEK"] section + ["<" number "." nz_number ">"] + +flag ::= "\Answered" / "\Flagged" / "\Deleted" / + "\Seen" / "\Draft" / flag_keyword / flag_extension + +flag_extension ::= "\" atom + ;; Future expansion. Client implementations + ;; MUST accept flag_extension flags. Server + ;; implementations MUST NOT generate + ;; flag_extension flags except as defined by + ;; future standard or standards-track + ;; revisions of this specification. + +flag_keyword ::= atom + + + +Crispin Standards Track [Page 69] + +RFC 2060 IMAP4rev1 December 1996 + + +flag_list ::= "(" #flag ")" + +greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF + +header_fld_name ::= astring + +header_list ::= "(" 1#header_fld_name ")" + +LF ::= + +list ::= "LIST" SPACE mailbox SPACE list_mailbox + +list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string + +list_wildcards ::= "%" / "*" + +literal ::= "{" number "}" CRLF *CHAR8 + ;; Number represents the number of CHAR8 octets + +login ::= "LOGIN" SPACE userid SPACE password + +lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox + +mailbox ::= "INBOX" / astring + ;; INBOX is case-insensitive. All case variants of + ;; INBOX (e.g. "iNbOx") MUST be interpreted as INBOX + ;; not as an astring. Refer to section 5.1 for + ;; further semantic details of mailbox names. + +mailbox_data ::= "FLAGS" SPACE flag_list / + "LIST" SPACE mailbox_list / + "LSUB" SPACE mailbox_list / + "MAILBOX" SPACE text / + "SEARCH" [SPACE 1#nz_number] / + "STATUS" SPACE mailbox SPACE + "(" # QUOTED_CHAR <"> / nil) SPACE mailbox + +media_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" / + "MESSAGE" / "VIDEO") <">) / string) + SPACE media_subtype + ;; Defined in [MIME-IMT] + +media_message ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> + + + +Crispin Standards Track [Page 70] + +RFC 2060 IMAP4rev1 December 1996 + + + ;; Defined in [MIME-IMT] + +media_subtype ::= string + ;; Defined in [MIME-IMT] + +media_text ::= <"> "TEXT" <"> SPACE media_subtype + ;; Defined in [MIME-IMT] + +message_data ::= nz_number SPACE ("EXPUNGE" / + ("FETCH" SPACE msg_att)) + +msg_att ::= "(" 1#("ENVELOPE" SPACE envelope / + "FLAGS" SPACE "(" #(flag / "\Recent") ")" / + "INTERNALDATE" SPACE date_time / + "RFC822" [".HEADER" / ".TEXT"] SPACE nstring / + "RFC822.SIZE" SPACE number / + "BODY" ["STRUCTURE"] SPACE body / + "BODY" section ["<" number ">"] SPACE nstring / + "UID" SPACE uniqueid) ")" + +nil ::= "NIL" + +nstring ::= string / nil + +number ::= 1*digit + ;; Unsigned 32-bit integer + ;; (0 <= n < 4,294,967,296) + +nz_number ::= digit_nz *digit + ;; Non-zero unsigned 32-bit integer + ;; (0 < n < 4,294,967,296) + +password ::= astring + +quoted ::= <"> *QUOTED_CHAR <"> + +QUOTED_CHAR ::= / + "\" quoted_specials + +quoted_specials ::= <"> / "\" + +rename ::= "RENAME" SPACE mailbox SPACE mailbox + ;; Use of INBOX as a destination gives a NO error + +response ::= *(continue_req / response_data) response_done + +response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye / + mailbox_data / message_data / capability_data) + + + +Crispin Standards Track [Page 71] + +RFC 2060 IMAP4rev1 December 1996 + + + CRLF + +response_done ::= response_tagged / response_fatal + +response_fatal ::= "*" SPACE resp_cond_bye CRLF + ;; Server closes connection immediately + +response_tagged ::= tag SPACE resp_cond_state CRLF + +resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text + ;; Authentication condition + +resp_cond_bye ::= "BYE" SPACE resp_text + +resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text + ;; Status condition + +resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text) + ;; text SHOULD NOT begin with "[" or "=" + +resp_text_code ::= "ALERT" / "PARSE" / + "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" / + "READ-ONLY" / "READ-WRITE" / "TRYCREATE" / + "UIDVALIDITY" SPACE nz_number / + "UNSEEN" SPACE nz_number / + atom [SPACE 1*] + +search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE] + 1#search_key + ;; [CHARSET] MUST be registered with IANA + +search_key ::= "ALL" / "ANSWERED" / "BCC" SPACE astring / + "BEFORE" SPACE date / "BODY" SPACE astring / + "CC" SPACE astring / "DELETED" / "FLAGGED" / + "FROM" SPACE astring / + "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" / + "ON" SPACE date / "RECENT" / "SEEN" / + "SINCE" SPACE date / "SUBJECT" SPACE astring / + "TEXT" SPACE astring / "TO" SPACE astring / + "UNANSWERED" / "UNDELETED" / "UNFLAGGED" / + "UNKEYWORD" SPACE flag_keyword / "UNSEEN" / + ;; Above this line were in [IMAP2] + "DRAFT" / + "HEADER" SPACE header_fld_name SPACE astring / + "LARGER" SPACE number / "NOT" SPACE search_key / + "OR" SPACE search_key SPACE search_key / + "SENTBEFORE" SPACE date / "SENTON" SPACE date / + "SENTSINCE" SPACE date / "SMALLER" SPACE number / + + + +Crispin Standards Track [Page 72] + +RFC 2060 IMAP4rev1 December 1996 + + + "UID" SPACE set / "UNDRAFT" / set / + "(" 1#search_key ")" + +section ::= "[" [section_text / (nz_number *["." nz_number] + ["." (section_text / "MIME")])] "]" + +section_text ::= "HEADER" / "HEADER.FIELDS" [".NOT"] + SPACE header_list / "TEXT" + +select ::= "SELECT" SPACE mailbox + +sequence_num ::= nz_number / "*" + ;; * is the largest number in use. For message + ;; sequence numbers, it is the number of messages + ;; in the mailbox. For unique identifiers, it is + ;; the unique identifier of the last message in + ;; the mailbox. + +set ::= sequence_num / (sequence_num ":" sequence_num) / + (set "," set) + ;; Identifies a set of messages. For message + ;; sequence numbers, these are consecutive + ;; numbers from 1 to the number of messages in + ;; the mailbox + ;; Comma delimits individual numbers, colon + ;; delimits between two numbers inclusive. + ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13, + ;; 14,15 for a mailbox with 15 messages. + +SPACE ::= + +status ::= "STATUS" SPACE mailbox SPACE "(" 1#status_att ")" + +status_att ::= "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" / + "UNSEEN" + +store ::= "STORE" SPACE set SPACE store_att_flags + +store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE + (flag_list / #flag) + +string ::= quoted / literal + +subscribe ::= "SUBSCRIBE" SPACE mailbox + +tag ::= 1* + +text ::= 1*TEXT_CHAR + + + +Crispin Standards Track [Page 73] + +RFC 2060 IMAP4rev1 December 1996 + + +text_mime2 ::= "=?" "?" "?" + "?=" + ;; Syntax defined in [MIME-HDRS] + +TEXT_CHAR ::= + +time ::= 2digit ":" 2digit ":" 2digit + ;; Hours minutes seconds + +uid ::= "UID" SPACE (copy / fetch / search / store) + ;; Unique identifiers used instead of message + ;; sequence numbers + +uniqueid ::= nz_number + ;; Strictly ascending + +unsubscribe ::= "UNSUBSCRIBE" SPACE mailbox + +userid ::= astring + +x_command ::= "X" atom + +zone ::= ("+" / "-") 4digit + ;; Signed four-digit value of hhmm representing + ;; hours and minutes west of Greenwich (that is, + ;; (the amount that the given time differs from + ;; Universal Time). Subtracting the timezone + ;; from the given time will give the UT form. + ;; The Universal Time zone is "+0000". + +10. Author's Note + + This document is a revision or rewrite of earlier documents, and + supercedes the protocol specification in those documents: RFC 1730, + unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064. + +11. Security Considerations + + IMAP4rev1 protocol transactions, including electronic mail data, are + sent in the clear over the network unless privacy protection is + negotiated in the AUTHENTICATE command. + + A server error message for an AUTHENTICATE command which fails due to + invalid credentials SHOULD NOT detail why the credentials are + invalid. + + Use of the LOGIN command sends passwords in the clear. This can be + avoided by using the AUTHENTICATE command instead. + + + +Crispin Standards Track [Page 74] + +RFC 2060 IMAP4rev1 December 1996 + + + A server error message for a failing LOGIN command SHOULD NOT specify + that the user name, as opposed to the password, is invalid. + + Additional security considerations are discussed in the section + discussing the AUTHENTICATE and LOGIN commands. + +12. Author's Address + + Mark R. Crispin + Networks and Distributed Computing + University of Washington + 4545 15th Aveneue NE + Seattle, WA 98105-4527 + + Phone: (206) 543-5762 + + EMail: MRC@CAC.Washington.EDU + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin Standards Track [Page 75] + +RFC 2060 IMAP4rev1 December 1996 + + +Appendices + +A. References + +[ACAP] Myers, J. "ACAP -- Application Configuration Access Protocol", +Work in Progress. + +[CHARSET] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, +RFC 1700, USC/Information Sciences Institute, October 1994. + +[DISPOSITION] Troost, R., and Dorner, S., "Communicating Presentation +Information in Internet Messages: The Content-Disposition Header", +RFC 1806, June 1995. + +[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731. +Carnegie-Mellon University, December 1994. + +[IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with IMAP2bis", RFC +2061, University of Washington, November 1996. + +[IMAP-DISC] Austein, R., "Synchronization Operations for Disconnected +IMAP4 Clients", Work in Progress. + +[IMAP-HISTORICAL] Crispin, M. "IMAP4 Compatibility with IMAP2 and +IMAP2bis", RFC 1732, University of Washington, December 1994. + +[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in +IMAP4", RFC 1733, University of Washington, December 1994. + +[IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol - +Obsolete Syntax", RFC 2062, University of Washington, November 1996. + +[IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", +RFC 1176, University of Washington, August 1990. + +[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of +Languages", RFC 1766, March 1995. + +[MD5] Myers, J., and M. Rose, "The Content-MD5 Header Field", RFC +1864, October 1995. + +[MIME-IMB] Freed, N., and N. Borenstein, "MIME (Multipurpose Internet +Mail Extensions) Part One: Format of Internet Message Bodies", RFC +2045, November 1996. + +[MIME-IMT] Freed, N., and N. Borenstein, "MIME (Multipurpose +Internet Mail Extensions) Part Two: Media Types", RFC 2046, +November 1996. + + + +Crispin Standards Track [Page 76] + +RFC 2060 IMAP4rev1 December 1996 + + +[MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail Extensions) +Part Three: Message Header Extensions for Non-ASCII Text", RFC +2047, November 1996. + +[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text +Messages", STD 11, RFC 822, University of Delaware, August 1982. + +[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, +RFC 821, USC/Information Sciences Institute, August 1982. + +[UTF-7] Goldsmith, D., and Davis, M., "UTF-7: A Mail-Safe +Transformation Format of Unicode", RFC 1642, July 1994. + +B. Changes from RFC 1730 + +1) The STATUS command has been added. + +2) Clarify in the formal syntax that the "#" construct can never +refer to multiple spaces. + +3) Obsolete syntax has been moved to a separate document. + +4) The PARTIAL command has been obsoleted. + +5) The RFC822.HEADER.LINES, RFC822.HEADER.LINES.NOT, RFC822.PEEK, and +RFC822.TEXT.PEEK fetch attributes have been obsoleted. + +6) The "<" origin "." size ">" suffix for BODY text attributes has +been added. + +7) The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and TEXT part +specifiers have been added. + +8) Support for Content-Disposition and Content-Language has been +added. + +9) The restriction on fetching nested MULTIPART parts has been +removed. + +10) Body part number 0 has been obsoleted. + +11) Server-supported authenticators are now identified by +capabilities. + + + + + + + + +Crispin Standards Track [Page 77] + +RFC 2060 IMAP4rev1 December 1996 + + +12) The capability that identifies this protocol is now called +"IMAP4rev1". A server that provides backwards support for RFC 1730 +SHOULD emit the "IMAP4" capability in addition to "IMAP4rev1" in its +CAPABILITY response. Because RFC-1730 required "IMAP4" to appear as +the first capability, it MUST listed first in the response. + +13) A description of the mailbox name namespace convention has been +added. + +14) A description of the international mailbox name convention has +been added. + +15) The UID-NEXT and UID-VALIDITY status items are now called UIDNEXT +and UIDVALIDITY. This is a change from the IMAP STATUS +Work in Progress and not from RFC-1730 + +16) Add a clarification that a null mailbox name argument to the LIST +command returns an untagged LIST response with the hierarchy +delimiter and root of the reference argument. + +17) Define terms such as "MUST", "SHOULD", and "MUST NOT". + +18) Add a section which defines message attributes and more +thoroughly details the semantics of message sequence numbers, UIDs, +and flags. + +19) Add a clarification detailing the circumstances when a client may +send multiple commands without waiting for a response, and the +circumstances in which ambiguities may result. + +20) Add a recommendation on server behavior for DELETE and RENAME +when inferior hierarchical names of the given name exist. + +21) Add a clarification that a mailbox name may not be unilaterally +unsubscribed by the server, even if that mailbox name no longer +exists. + +22) Add a clarification that LIST should return its results quickly +without undue delay. + +23) Add a clarification that the date_time argument to APPEND sets +the internal date of the message. + +24) Add a clarification on APPEND behavior when the target mailbox is +the currently selected mailbox. + + + + + + +Crispin Standards Track [Page 78] + +RFC 2060 IMAP4rev1 December 1996 + + +25) Add a clarification that external changes to flags should be +always announced via an untagged FETCH even if the current command is +a STORE with the ".SILENT" suffix. + +26) Add a clarification that COPY appends to the target mailbox. + +27) Add the NEWNAME response code. + +28) Rewrite the description of the untagged BYE response to clarify +its semantics. + +29) Change the reference for the body MD5 to refer to the proper RFC. + +30) Clarify that the formal syntax contains rules which may overlap, +and that in the event of such an overlap the rule which occurs first +takes precedence. + +31) Correct the definition of body_fld_param. + +32) More formal syntax for capability_data. + +33) Clarify that any case variant of "INBOX" must be interpreted as +INBOX. + +34) Clarify that the human-readable text in resp_text should not +begin with "[" or "=". + +35) Change MIME references to Draft Standard documents. + +36) Clarify \Recent semantics. + +37) Additional examples. + +C. Key Word Index + + +FLAGS (store command data item) ............... 45 + +FLAGS.SILENT (store command data item) ........ 46 + -FLAGS (store command data item) ............... 46 + -FLAGS.SILENT (store command data item) ........ 46 + ALERT (response code) ...................................... 50 + ALL (fetch item) ........................................... 41 + ALL (search key) ........................................... 38 + ANSWERED (search key) ...................................... 38 + APPEND (command) ........................................... 34 + AUTHENTICATE (command) ..................................... 20 + BAD (response) ............................................. 52 + BCC (search key) .................................. 38 + BEFORE (search key) ................................. 39 + + + +Crispin Standards Track [Page 79] + +RFC 2060 IMAP4rev1 December 1996 + + + BODY (fetch item) .......................................... 41 + BODY (fetch result) ........................................ 58 + BODY (search key) ................................. 39 + BODY.PEEK[
]<> (fetch item) ............... 44 + BODYSTRUCTURE (fetch item) ................................. 44 + BODYSTRUCTURE (fetch result) ............................... 59 + BODY[
]<> (fetch result) ............. 58 + BODY[
]<> (fetch item) .................... 41 + BYE (response) ............................................. 52 + Body Structure (message attribute) ......................... 11 + CAPABILITY (command) ....................................... 18 + CAPABILITY (response) ...................................... 53 + CC (search key) ................................... 39 + CHECK (command) ............................................ 36 + CLOSE (command) ............................................ 36 + COPY (command) ............................................. 46 + CREATE (command) ........................................... 25 + DELETE (command) ........................................... 26 + DELETED (search key) ....................................... 39 + DRAFT (search key) ......................................... 39 + ENVELOPE (fetch item) ...................................... 44 + ENVELOPE (fetch result) .................................... 62 + EXAMINE (command) .......................................... 24 + EXISTS (response) .......................................... 56 + EXPUNGE (command) .......................................... 37 + EXPUNGE (response) ......................................... 57 + Envelope Structure (message attribute) ..................... 11 + FAST (fetch item) .......................................... 44 + FETCH (command) ............................................ 41 + FETCH (response) ........................................... 58 + FLAGGED (search key) ....................................... 39 + FLAGS (fetch item) ......................................... 44 + FLAGS (fetch result) ....................................... 62 + FLAGS (response) ........................................... 56 + FLAGS (store command data item) ................ 45 + FLAGS.SILENT (store command data item) ......... 45 + FROM (search key) ................................. 39 + FULL (fetch item) .......................................... 44 + Flags (message attribute) .................................. 9 + HEADER (part specifier) .................................... 41 + HEADER (search key) .................. 39 + HEADER.FIELDS (part specifier) ............... 41 + HEADER.FIELDS.NOT (part specifier) ........... 41 + INTERNALDATE (fetch item) .................................. 44 + INTERNALDATE (fetch result) ................................ 62 + Internal Date (message attribute) .......................... 10 + KEYWORD (search key) ................................ 39 + Keyword (type of flag) ..................................... 10 + + + +Crispin Standards Track [Page 80] + +RFC 2060 IMAP4rev1 December 1996 + + + LARGER (search key) .................................... 39 + LIST (command) ............................................. 30 + LIST (response) ............................................ 54 + LOGIN (command) ............................................ 22 + LOGOUT (command) ........................................... 20 + LSUB (command) ............................................. 32 + LSUB (response) ............................................ 55 + MAY (specification requirement term) ....................... 5 + MESSAGES (status item) ..................................... 33 + MIME (part specifier) ...................................... 42 + MUST (specification requirement term) ...................... 4 + MUST NOT (specification requirement term) .................. 4 + Message Sequence Number (message attribute) ................ 9 + NEW (search key) ........................................... 39 + NEWNAME (response code) .................................... 50 + NO (response) .............................................. 51 + NOOP (command) ............................................. 19 + NOT (search key) .............................. 39 + OK (response) .............................................. 51 + OLD (search key) ........................................... 39 + ON (search key) ..................................... 39 + OPTIONAL (specification requirement term) .................. 5 + OR (search key) ................ 39 + PARSE (response code) ...................................... 50 + PERMANENTFLAGS (response code) ............................. 50 + PREAUTH (response) ......................................... 52 + Permanent Flag (class of flag) ............................. 10 + READ-ONLY (response code) .................................. 50 + READ-WRITE (response code) ................................. 50 + RECENT (response) .......................................... 57 + RECENT (search key) ........................................ 39 + RECENT (status item) ....................................... 33 + RENAME (command) ........................................... 27 + REQUIRED (specification requirement term) .................. 4 + RFC822 (fetch item) ........................................ 44 + RFC822 (fetch result) ...................................... 63 + RFC822.HEADER (fetch item) ................................. 44 + RFC822.HEADER (fetch result) ............................... 62 + RFC822.SIZE (fetch item) ................................... 44 + RFC822.SIZE (fetch result) ................................. 62 + RFC822.TEXT (fetch item) ................................... 44 + RFC822.TEXT (fetch result) ................................. 62 + SEARCH (command) ........................................... 37 + SEARCH (response) .......................................... 55 + SEEN (search key) .......................................... 40 + SELECT (command) ........................................... 23 + SENTBEFORE (search key) ............................. 40 + SENTON (search key) ................................. 40 + + + +Crispin Standards Track [Page 81] + +RFC 2060 IMAP4rev1 December 1996 + + + SENTSINCE (search key) .............................. 40 + SHOULD (specification requirement term) .................... 5 + SHOULD NOT (specification requirement term) ................ 5 + SINCE (search key) .................................. 40 + SMALLER (search key) ................................... 40 + STATUS (command) ........................................... 33 + STATUS (response) .......................................... 55 + STORE (command) ............................................ 45 + SUBJECT (search key) .............................. 40 + SUBSCRIBE (command) ........................................ 29 + Session Flag (class of flag) ............................... 10 + System Flag (type of flag) ................................. 9 + TEXT (part specifier) ...................................... 42 + TEXT (search key) ................................. 40 + TO (search key) ................................... 40 + TRYCREATE (response code) .................................. 51 + UID (command) .............................................. 47 + UID (fetch item) ........................................... 44 + UID (fetch result) ......................................... 63 + UID (search key) ............................. 40 + UIDNEXT (status item) ...................................... 33 + UIDVALIDITY (response code) ................................ 51 + UIDVALIDITY (status item) .................................. 34 + UNANSWERED (search key) .................................... 40 + UNDELETED (search key) ..................................... 40 + UNDRAFT (search key) ....................................... 40 + UNFLAGGED (search key) ..................................... 40 + UNKEYWORD (search key) .............................. 40 + UNSEEN (response code) ..................................... 51 + UNSEEN (search key) ........................................ 40 + UNSEEN (status item) ....................................... 34 + UNSUBSCRIBE (command) ...................................... 30 + Unique Identifier (UID) (message attribute) ................ 7 + X (command) .......................................... 48 + [RFC-822] Size (message attribute) ......................... 11 + \Answered (system flag) .................................... 9 + \Deleted (system flag) ..................................... 9 + \Draft (system flag) ....................................... 9 + \Flagged (system flag) ..................................... 9 + \Marked (mailbox name attribute) ........................... 54 + \Noinferiors (mailbox name attribute) ...................... 54 + \Noselect (mailbox name attribute) ......................... 54 + \Recent (system flag) ...................................... 10 + \Seen (system flag) ........................................ 9 + \Unmarked (mailbox name attribute) ......................... 54 + + + + + + +Crispin Standards Track [Page 82] + diff --git a/RFC/rfc2061.txt b/RFC/rfc2061.txt new file mode 100644 index 00000000..7cb02bb2 --- /dev/null +++ b/RFC/rfc2061.txt @@ -0,0 +1,171 @@ + + + + + + +Network Working Group M. Crispin +Request for Comments: 2061 University of Washington +Category: Informational December 1996 + + + IMAP4 COMPATIBILITY WITH IMAP2BIS + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Introduction + + The Internet Message Access Protocol (IMAP) has been through several + revisions and variants in its 10-year history. Many of these are + either extinct or extremely rare; in particular, several undocumented + variants and the variants described in RFC 1064, RFC 1176, and RFC + 1203 fall into this category. + + One variant, IMAP2bis, is at the time of this writing very common and + has been widely distributed with the Pine mailer. Unfortunately, + there is no definite document describing IMAP2bis. This document is + intended to be read along with RFC 1176 and the most recent IMAP4 + specification (RFC 2060) to assist implementors in creating an IMAP4 + implementation to interoperate with implementations that conform to + earlier specifications. Nothing in this document is required by the + IMAP4 specification; implementors must decide for themselves whether + they want their implementation to fail if it encounters old software. + + At the time of this writing, IMAP4 has been updated from the version + described in RFC 1730. An implementor who wishes to interoperate + with both RFC 1730 and RFC 2060 should refer to both documents. + + This information is not complete; it reflects current knowledge of + server and client implementations as well as "folklore" acquired in + the evolution of the protocol. It is NOT a description of how to + interoperate with all variants of IMAP, but rather with the old + variant that is most likely to be encountered. For detailed + information on interoperating with other old variants, refer to RFC + 1732. + +IMAP4 client interoperability with IMAP2bis servers + + A quick way to check whether a server implementation supports the + IMAP4 specification is to try the CAPABILITY command. An OK response + will indicate which variant(s) of IMAP4 are supported by the server. + + + +Crispin Informational [Page 1] + +RFC 2061 IMAP4 Compatibility December 1996 + + + If the client does not find any of its known variant in the response, + it should treat the server as IMAP2bis. A BAD response indicates an + IMAP2bis or older server. + + Most IMAP4 facilities are in IMAP2bis. The following exceptions + exist: + + CAPABILITY command + The absense of this command indicates IMAP2bis (or older). + + AUTHENTICATE command. + Use the LOGIN command. + + LSUB, SUBSCRIBE, and UNSUBSCRIBE commands + No direct functional equivalent. IMAP2bis had a concept + called "bboards" which is not in IMAP4. RFC 1176 supported + these with the BBOARD and FIND BBOARDS commands. IMAP2bis + augmented these with the FIND ALL.BBOARDS, SUBSCRIBE BBOARD, + and UNSUBSCRIBE BBOARD commands. It is recommended that + none of these commands be implemented in new software, + including servers that support old clients. + + LIST command + Use the command FIND ALL.MAILBOXES, which has a similar syn- + tax and response to the FIND MAILBOXES command described in + RFC 1176. The FIND MAILBOXES command is unlikely to produce + useful information. + + * in a sequence + Use the number of messages in the mailbox from the EXISTS + unsolicited response. + + SEARCH extensions (character set, additional criteria) + Reformulate the search request using only the RFC 1176 syn- + tax. This may entail doing multiple searches to achieve the + desired results. + + BODYSTRUCTURE fetch data item + Use the non-extensible BODY data item. + + body sections HEADER, TEXT, MIME, HEADER.FIELDS, HEADER.FIELDS.NOT + Use body section numbers only. + + BODY.PEEK[section] + Use BODY[section] and manually clear the \Seen flag as + necessary. + + + + + +Crispin Informational [Page 2] + +RFC 2061 IMAP4 Compatibility December 1996 + + + FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items + Use the corresponding non-SILENT versions and ignore the + untagged FETCH responses which come back. + + UID fetch data item and the UID commands + No functional equivalent. + + CLOSE command + No functional equivalent. + + + In IMAP2bis, the TRYCREATE special information token is sent as a + separate unsolicited OK response instead of inside the NO response. + + IMAP2bis is ambiguous about whether or not flags or internal dates + are preserved on COPY. It is impossible to know what behavior is + supported by the server. + +IMAP4 server interoperability with IMAP2bis clients + + The only interoperability problem between an IMAP4 server and a + well-written IMAP2bis client is an incompatibility with the use of + "\" in quoted strings. This is best avoided by using literals + instead of quoted strings if "\" or <"> is embedded in the string. + +Security Considerations + + Security issues are not discussed in this memo. + +Author's Address + + Mark R. Crispin + Networks and Distributed Computing + University of Washington + 4545 15th Aveneue NE + Seattle, WA 98105-4527 + + Phone: (206) 543-5762 + EMail: MRC@CAC.Washington.EDU + + + + + + + + + + + + +Crispin Informational [Page 3] + diff --git a/RFC/rfc2062.txt b/RFC/rfc2062.txt new file mode 100644 index 00000000..865d1dad --- /dev/null +++ b/RFC/rfc2062.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group M. Crispin +Request for Comments: 2062 University of Washington +Category: Informational December 1996 + + + Internet Message Access Protocol - Obsolete Syntax + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + This document describes obsolete syntax which may be encountered by + IMAP4 implementations which deal with older versions of the Internet + Mail Access Protocol. IMAP4 implementations MAY implement this + syntax in order to maximize interoperability with older + implementations. + + This document repeats information from earlier documents, most + notably RFC 1176 and RFC 1730. + +Obsolete Commands and Fetch Data Items + + The following commands are OBSOLETE. It is NOT required to support + any of these commands or fetch data items in new server + implementations. These commands are documented here for the benefit + of implementors who may wish to support them for compatibility with + old client implementations. + + The section headings of these commands are intended to correspond + with where they would be located in the main document if they were + not obsoleted. + +6.3.OBS.1. FIND ALL.MAILBOXES Command + + Arguments: mailbox name with possible wildcards + + Data: untagged responses: MAILBOX + + Result: OK - find completed + NO - find failure: can't list that name + BAD - command unknown or arguments invalid + + + + + + +Crispin Informational [Page 1] + +RFC 2062 IMAP4 Obsolete December 1996 + + + The FIND ALL.MAILBOXES command returns a subset of names from the + complete set of all names available to the user. It returns zero + or more untagged MAILBOX replies. The mailbox argument to FIND + ALL.MAILBOXES is similar to that for LIST with an empty reference, + except that the characters "%" and "?" match a single character. + + Example: C: A002 FIND ALL.MAILBOXES * + S: * MAILBOX blurdybloop + S: * MAILBOX INBOX + S: A002 OK FIND ALL.MAILBOXES completed + +6.3.OBS.2. FIND MAILBOXES Command + + Arguments: mailbox name with possible wildcards + + Data: untagged responses: MAILBOX + + Result: OK - find completed + NO - find failure: can't list that name + BAD - command unknown or arguments invalid + + The FIND MAILBOXES command returns a subset of names from the set + of names that the user has declared as being "active" or + "subscribed". It returns zero or more untagged MAILBOX replies. + The mailbox argument to FIND MAILBOXES is similar to that for LSUB + with an empty reference, except that the characters "%" and "?" + match a single character. + + Example: C: A002 FIND MAILBOXES * + S: * MAILBOX blurdybloop + S: * MAILBOX INBOX + S: A002 OK FIND MAILBOXES completed + +6.3.OBS.3. SUBSCRIBE MAILBOX Command + + Arguments: mailbox name + + Data: no specific data for this command + + Result: OK - subscribe completed + NO - subscribe failure: can't subscribe to that name + BAD - command unknown or arguments invalid + + The SUBSCRIBE MAILBOX command is identical in effect to the + SUBSCRIBE command. A server which implements this command must be + able to distinguish between a SUBSCRIBE MAILBOX command and a + SUBSCRIBE command with a mailbox name argument of "MAILBOX". + + + + +Crispin Informational [Page 2] + +RFC 2062 IMAP4 Obsolete December 1996 + + + Example: C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime + S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime + completed + C: A003 SUBSCRIBE MAILBOX + S: A003 OK SUBSCRIBE to MAILBOX completed + + +6.3.OBS.4. UNSUBSCRIBE MAILBOX Command + + Arguments: mailbox name + + Data: no specific data for this command + + Result: OK - unsubscribe completed + NO - unsubscribe failure: can't unsubscribe that name + BAD - command unknown or arguments invalid + + The UNSUBSCRIBE MAILBOX command is identical in effect to the + UNSUBSCRIBE command. A server which implements this command must + be able to distinguish between a UNSUBSCRIBE MAILBOX command and + an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX". + + Example: C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime + S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime + completed + C: A003 UNSUBSCRIBE MAILBOX + S: A003 OK UNSUBSCRIBE from MAILBOX completed + +6.4.OBS.1 PARTIAL Command + + Arguments: message sequence number + message data item name + position of first octet + number of octets + + Data: untagged responses: FETCH + + Result: OK - partial completed + NO - partial error: can't fetch that data + BAD - command unknown or arguments invalid + + The PARTIAL command is equivalent to the associated FETCH command, + with the added functionality that only the specified number of + octets, beginning at the specified starting octet, are returned. + Only a single message can be fetched at a time. The first octet + of a message, and hence the minimum for the starting octet, is + octet 1. + + + + +Crispin Informational [Page 3] + +RFC 2062 IMAP4 Obsolete December 1996 + + + The following FETCH items are valid data for PARTIAL: RFC822, + RFC822.HEADER, RFC822.TEXT, BODY[
], as well as any .PEEK + forms of these. + + Any partial fetch that attempts to read beyond the end of the text + is truncated as appropriate. If the starting octet is beyond the + end of the text, an empty string is returned. + + The data are returned with the FETCH response. There is no + indication of the range of the partial data in this response. It + is not possible to stream multiple PARTIAL commands of the same + data item without processing and synchronizing at each step, since + streamed commands may be executed out of order. + + There is no requirement that partial fetches follow any sequence. + For example, if a partial fetch of octets 1 through 10000 breaks + in an awkward place for BASE64 decoding, it is permitted to + continue with a partial fetch of 9987 through 19987, etc. + + The handling of the \Seen flag is the same as in the associated + FETCH command. + + Example: C: A005 PARTIAL 4 RFC822 1 1024 + S: * 1 FETCH (RFC822 {1024} + S: Return-Path: + S: ... + S: ......... FLAGS (\Seen)) + S: A005 OK PARTIAL completed + +6.4.5.OBS.1 Obsolete FETCH Data Items + + The following FETCH data items are obsolete: + + BODY[<...>0] A body part number of 0 is the [RFC-822] header of + the message. BODY[0] is functionally equivalent to + BODY[HEADER], differing in the syntax of the + resulting untagged FETCH data (BODY[0] is + returned). + + RFC822.HEADER.LINES + Functionally equivalent to BODY.PEEK[HEADER.LINES + ], differing in the syntax of the + resulting untagged FETCH data (RFC822.HEADER is + returned). + + + + + + + +Crispin Informational [Page 4] + +RFC 2062 IMAP4 Obsolete December 1996 + + + RFC822.HEADER.LINES.NOT + Functionally equivalent to + BODY.PEEK[HEADER.LINES.NOT ], + differing in the syntax of the resulting untagged + FETCH data (RFC822.HEADER is returned). + + RFC822.PEEK Functionally equivalent to BODY.PEEK[], except for + the syntax of the resulting untagged FETCH data + (RFC822 is returned). + + RFC822.TEXT.PEEK + Functionally equivalent to BODY.PEEK[TEXT], except + for the syntax of the resulting untagged FETCH data + (RFC822.TEXT is returned). + +Obsolete Responses + + The following responses are OBSOLETE. Except as noted below, these + responses MUST NOT be transmitted by new server implementations. + Client implementations SHOULD accept these responses. + + The section headings of these responses are intended to correspond + with where they would be located in the main document if they were + not obsoleted. + +7.2.OBS.1. MAILBOX Response + + Data: name + + The MAILBOX response MUST NOT be transmitted by server + implementations except in response to the obsolete FIND MAILBOXES + and FIND ALL.MAILBOXES commands. Client implementations that do + not use these commands MAY ignore this response. It is documented + here for the benefit of implementors who may wish to support it + for compatibility with old client implementations. + + This response occurs as a result of the FIND MAILBOXES and FIND + ALL.MAILBOXES commands. It returns a single name that matches the + FIND specification. There are no attributes or hierarchy + delimiter. + + Example: S: * MAILBOX blurdybloop + + + + + + + + + +Crispin Informational [Page 5] + +RFC 2062 IMAP4 Obsolete December 1996 + + +7.3.OBS.1. COPY Response + + Data: none + + The COPY response MUST NOT be transmitted by new server + implementations. Client implementations MUST ignore the COPY + response. It is documented here for the benefit of client + implementors who may encounter this response from old server + implementations. + + In some experimental versions of this protocol, this response was + returned in response to a COPY command to indicate on a + per-message basis that the message was copied successfully. + + Example: S: * 44 COPY + +7.3.OBS.2. STORE Response + + Data: message data + + The STORE response MUST NOT be transmitted by new server + implementations. Client implementations MUST treat the STORE + response as equivalent to the FETCH response. It is documented + here for the benefit of client implementors who may encounter this + response from old server implementations. + + In some experimental versions of this protocol, this response was + returned instead of FETCH in response to a STORE command to report + the new value of the flags. + + Example: S: * 69 STORE (FLAGS (\Deleted)) + +Formal Syntax of Obsolete Commands and Responses + + Each obsolete syntax rule that is suffixed with "_old" is added to + the corresponding name in the formal syntax. For example, + command_auth_old adds the FIND command to command_auth. + + command_auth_old ::= find + + command_select_old + ::= partial + + date_year_old ::= 2digit + ;; (year - 1900) + + date_time_old ::= <"> date_day_fixed "-" date_month "-" date_year + SPACE time "-" zone_name <"> + + + +Crispin Informational [Page 6] + +RFC 2062 IMAP4 Obsolete December 1996 + + + find ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE + list_mailbox + + fetch_att_old ::= "RFC822.HEADER.LINES" [".NOT"] SPACE header_list / + fetch_text_old + + fetch_text_old ::= "BODY" [".PEEK"] section_old / + "RFC822" [".HEADER" / ".TEXT" [".PEEK"]] + + msg_data_old ::= "COPY" / ("STORE" SPACE msg_att) + + partial ::= "PARTIAL" SPACE nz_number SPACE fetch_text_old SPACE + number SPACE number + + section_old ::= "[" (number ["." number]) "]" + + subscribe_old ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox + + unsubscribe_old ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox + + zone_name ::= "UT" / "GMT" / "Z" / ;; +0000 + "AST" / "EDT" / ;; -0400 + "EST" / "CDT" / ;; -0500 + "CST" / "MDT" / ;; -0600 + "MST" / "PDT" / ;; -0700 + "PST" / "YDT" / ;; -0800 + "YST" / "HDT" / ;; -0900 + "HST" / "BDT" / ;; -1000 + "BST" / ;; -1100 + "A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6 + "G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12 + "N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6 + "T" / "U" / "V" / "W" / "X" / "Y" ;; -7 to -12 + +Security Considerations + + Security issues are not discussed in this memo. + + + + + + + + + + + + + + +Crispin Informational [Page 7] + +RFC 2062 IMAP4 Obsolete December 1996 + + +Author's Address + + Mark R. Crispin + Networks and Distributed Computing + University of Washington + 4545 15th Aveneue NE + Seattle, WA 98105-4527 + + Phone: (206) 543-5762 + EMail: MRC@CAC.Washington.EDU + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin Informational [Page 8] + diff --git a/RFC/rfc2177.txt b/RFC/rfc2177.txt new file mode 100644 index 00000000..ef28fad3 --- /dev/null +++ b/RFC/rfc2177.txt @@ -0,0 +1,227 @@ + + + + + + +Network Working Group B. Leiba +Request for Comments: 2177 IBM T.J. Watson Research Center +Category: Standards Track June 1997 + + + IMAP4 IDLE command + +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 + + The Internet Message Access Protocol [IMAP4] requires a client to + poll the server for changes to the selected mailbox (new mail, + deletions). It's often more desirable to have the server transmit + updates to the client in real time. This allows a user to see new + mail immediately. It also helps some real-time applications based on + IMAP, which might otherwise need to poll extremely often (such as + every few seconds). (While the spec actually does allow a server to + push EXISTS responses aysynchronously, a client can't expect this + behaviour and must poll.) + + This document specifies the syntax of an IDLE command, which will + allow a client to tell the server that it's ready to accept such + real-time updates. + +2. Conventions Used in this Document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" + in this document are to be interpreted as described in RFC 2060 + [IMAP4]. + +3. Specification + + IDLE Command + + Arguments: none + + Responses: continuation data will be requested; the client sends + the continuation data "DONE" to end the command + + + +Leiba Standards Track [Page 1] + +RFC 2177 IMAP4 IDLE command June 1997 + + + + Result: OK - IDLE completed after client sent "DONE" + NO - failure: the server will not allow the IDLE + command at this time + BAD - command unknown or arguments invalid + + The IDLE command may be used with any IMAP4 server implementation + that returns "IDLE" as one of the supported capabilities to the + CAPABILITY command. If the server does not advertise the IDLE + capability, the client MUST NOT use the IDLE command and must poll + for mailbox updates. In particular, the client MUST continue to be + able to accept unsolicited untagged responses to ANY command, as + specified in the base IMAP specification. + + The IDLE command is sent from the client to the server when the + client is ready to accept unsolicited mailbox update messages. The + server requests a response to the IDLE command using the continuation + ("+") response. The IDLE command remains active until the client + responds to the continuation, and as long as an IDLE command is + active, the server is now free to send untagged EXISTS, EXPUNGE, and + other messages at any time. + + The IDLE command is terminated by the receipt of a "DONE" + continuation from the client; such response satisfies the server's + continuation request. At that point, the server MAY send any + remaining queued untagged responses and then MUST immediately send + the tagged response to the IDLE command and prepare to process other + commands. As in the base specification, the processing of any new + command may cause the sending of unsolicited untagged responses, + subject to the ambiguity limitations. The client MUST NOT send a + command while the server is waiting for the DONE, since the server + will not be able to distinguish a command from a continuation. + + The server MAY consider a client inactive if it has an IDLE command + running, and if such a server has an inactivity timeout it MAY log + the client off implicitly at the end of its timeout period. Because + of that, clients using IDLE are advised to terminate the IDLE and + re-issue it at least every 29 minutes to avoid being logged off. + This still allows a client to receive immediate mailbox updates even + though it need only "poll" at half hour intervals. + + + + + + + + + + + +Leiba Standards Track [Page 2] + +RFC 2177 IMAP4 IDLE command June 1997 + + + Example: C: A001 SELECT INBOX + S: * FLAGS (Deleted Seen) + S: * 3 EXISTS + S: * 0 RECENT + S: * OK [UIDVALIDITY 1] + S: A001 OK SELECT completed + C: A002 IDLE + S: + idling + ...time passes; new mail arrives... + S: * 4 EXISTS + C: DONE + S: A002 OK IDLE terminated + ...another client expunges message 2 now... + C: A003 FETCH 4 ALL + S: * 4 FETCH (...) + S: A003 OK FETCH completed + C: A004 IDLE + S: * 2 EXPUNGE + S: * 3 EXISTS + S: + idling + ...time passes; another client expunges message 3... + S: * 3 EXPUNGE + S: * 2 EXISTS + ...time passes; new mail arrives... + S: * 3 EXISTS + C: DONE + S: A004 OK IDLE terminated + C: A005 FETCH 3 ALL + S: * 3 FETCH (...) + S: A005 OK FETCH completed + C: A006 IDLE + +4. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. + Non-terminals referenced but not defined below are as defined by + [IMAP4]. + + command_auth ::= append / create / delete / examine / list / lsub / + rename / select / status / subscribe / unsubscribe + / idle + ;; Valid only in Authenticated or Selected state + + idle ::= "IDLE" CRLF "DONE" + + + + + + +Leiba Standards Track [Page 3] + +RFC 2177 IMAP4 IDLE command June 1997 + + +5. References + + [IMAP4] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, December 1996. + +6. Security Considerations + + There are no known security issues with this extension. + +7. Author's Address + + Barry Leiba + IBM T.J. Watson Research Center + 30 Saw Mill River Road + Hawthorne, NY 10532 + + Email: leiba@watson.ibm.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Leiba Standards Track [Page 4] + diff --git a/RFC/rfc2195.txt b/RFC/rfc2195.txt new file mode 100644 index 00000000..4a2725bf --- /dev/null +++ b/RFC/rfc2195.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group J. Klensin +Request for Comments: 2195 R. Catoe +Category: Standards Track P. Krumviede +Obsoletes: 2095 MCI + September 1997 + + + IMAP/POP AUTHorize Extension for Simple Challenge/Response + +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 + + While IMAP4 supports a number of strong authentication mechanisms as + described in RFC 1731, it lacks any mechanism that neither passes + cleartext, reusable passwords across the network nor requires either + a significant security infrastructure or that the mail server update + a mail-system-wide user authentication file on each mail access. + This specification provides a simple challenge-response + authentication protocol that is suitable for use with IMAP4. Since + it utilizes Keyed-MD5 digests and does not require that the secret be + stored in the clear on the server, it may also constitute an + improvement on APOP for POP3 use as specified in RFC 1734. + +1. Introduction + + Existing Proposed Standards specify an AUTHENTICATE mechanism for the + IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for + the POP3 protocol [POP3-AUTH]. The AUTHENTICATE mechanism is + intended to be extensible; the four methods specified in [IMAP-AUTH] + are all fairly powerful and require some security infrastructure to + support. The base POP3 specification [POP3] also contains a + lightweight challenge-response mechanism called APOP. APOP is + associated with most of the risks associated with such protocols: in + particular, it requires that both the client and server machines have + access to the shared secret in cleartext form. CRAM offers a method + for avoiding such cleartext storage while retaining the algorithmic + simplicity of APOP in using only MD5, though in a "keyed" method. + + + + + + + +Klensin, Catoe & Krumviede Standards Track [Page 1] + +RFC 2195 IMAP/POP AUTHorize Extension September 1997 + + + At present, IMAP [IMAP] lacks any facility corresponding to APOP. + The only alternative to the strong mechanisms identified in [IMAP- + AUTH] is a presumably cleartext username and password, supported + through the LOGIN command in [IMAP]. This document describes a + simple challenge-response mechanism, similar to APOP and PPP CHAP + [PPP], that can be used with IMAP (and, in principle, with POP3). + + This mechanism also has the advantage over some possible alternatives + of not requiring that the server maintain information about email + "logins" on a per-login basis. While mechanisms that do require such + per-login history records may offer enhanced security, protocols such + as IMAP, which may have several connections between a given client + and server open more or less simultaneous, may make their + implementation particularly challenging. + +2. Challenge-Response Authentication Mechanism (CRAM) + + The authentication type associated with CRAM is "CRAM-MD5". + + The data encoded in the first ready response contains an + presumptively arbitrary string of random digits, a timestamp, and the + fully-qualified primary host name of the server. The syntax of the + unencoded form must correspond to that of an RFC 822 'msg-id' + [RFC822] as described in [POP3]. + + The client makes note of the data and then responds with a string + consisting of the user name, a space, and a 'digest'. The latter is + computed by applying the keyed MD5 algorithm from [KEYED-MD5] where + the key is a shared secret and the digested text is the timestamp + (including angle-brackets). + + This shared secret is a string known only to the client and server. + The `digest' parameter itself is a 16-octet value which is sent in + hexadecimal format, using lower-case ASCII characters. + + When the server receives this client response, it verifies the digest + provided. If the digest is correct, the server should consider the + client authenticated and respond appropriately. + + Keyed MD5 is chosen for this application because of the greater + security imparted to authentication of short messages. In addition, + the use of the techniques described in [KEYED-MD5] for precomputation + of intermediate results make it possible to avoid explicit cleartext + storage of the shared secret on the server system by instead storing + the intermediate results which are known as "contexts". + + + + + + +Klensin, Catoe & Krumviede Standards Track [Page 2] + +RFC 2195 IMAP/POP AUTHorize Extension September 1997 + + + CRAM does not support a protection mechanism. + + Example: + + The examples in this document show the use of the CRAM mechanism with + the IMAP4 AUTHENTICATE command [IMAP-AUTH]. The base64 encoding of + the challenges and responses is part of the IMAP4 AUTHENTICATE + command, not part of the CRAM specification itself. + + S: * OK IMAP4 Server + C: A0001 AUTHENTICATE CRAM-MD5 + S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ + C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw + S: A0001 OK CRAM authentication successful + + In this example, the shared secret is the string + 'tanstaaftanstaaf'. Hence, the Keyed MD5 digest is produced by + calculating + + MD5((tanstaaftanstaaf XOR opad), + MD5((tanstaaftanstaaf XOR ipad), + <1896.697170952@postoffice.reston.mci.net>)) + + where ipad and opad are as defined in the keyed-MD5 Work in + Progress [KEYED-MD5] and the string shown in the challenge is the + base64 encoding of <1896.697170952@postoffice.reston.mci.net>. The + shared secret is null-padded to a length of 64 bytes. If the + shared secret is longer than 64 bytes, the MD5 digest of the + shared secret is used as a 16 byte input to the keyed MD5 + calculation. + + This produces a digest value (in hexadecimal) of + + b913a602c7eda7a495b4e6e7334d3890 + + The user name is then prepended to it, forming + + tim b913a602c7eda7a495b4e6e7334d3890 + + Which is then base64 encoded to meet the requirements of the IMAP4 + AUTHENTICATE command (or the similar POP3 AUTH command), yielding + + dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw + + + + + + + + +Klensin, Catoe & Krumviede Standards Track [Page 3] + +RFC 2195 IMAP/POP AUTHorize Extension September 1997 + + +3. References + + [CHAP] Lloyd, B., and W. Simpson, "PPP Authentication Protocols", + RFC 1334, October 1992. + + [IMAP] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, University of Washington, December 1996. + + [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms", + RFC 1731, Carnegie Mellon, December 1994. + + [KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for + Message Authentication", RFC 2104, February 1997. + + [MD5] Rivest, R., "The MD5 Message Digest Algorithm", + RFC 1321, MIT Laboratory for Computer Science, April 1992. + + [POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3", + STD 53, RFC 1939, Carnegie Mellon, May 1996. + + [POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, + Carnegie Mellon, December, 1994. + +4. Security Considerations + + It is conjectured that use of the CRAM authentication mechanism + provides origin identification and replay protection for a session. + Accordingly, a server that implements both a cleartext password + command and this authentication type should not allow both methods of + access for a given user. + + While the saving, on the server, of "contexts" (see section 2) is + marginally better than saving the shared secrets in cleartext as is + required by CHAP [CHAP] and APOP [POP3], it is not sufficient to + protect the secrets if the server itself is compromised. + Consequently, servers that store the secrets or contexts must both be + protected to a level appropriate to the potential information value + in user mailboxes and identities. + + As the length of the shared secret increases, so does the difficulty + of deriving it. + + While there are now suggestions in the literature that the use of MD5 + and keyed MD5 in authentication procedures probably has a limited + effective lifetime, the technique is now widely deployed and widely + understood. It is believed that this general understanding may + assist with the rapid replacement, by CRAM-MD5, of the current uses + of permanent cleartext passwords in IMAP. This document has been + + + +Klensin, Catoe & Krumviede Standards Track [Page 4] + +RFC 2195 IMAP/POP AUTHorize Extension September 1997 + + + deliberately written to permit easy upgrading to use SHA (or whatever + alternatives emerge) when they are considered to be widely available + and adequately safe. + + Even with the use of CRAM, users are still vulnerable to active + attacks. An example of an increasingly common active attack is 'TCP + Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95]. + + See section 1 above for additional discussion. + +5. Acknowledgements + + This memo borrows ideas and some text liberally from [POP3] and + [RFC-1731] and thanks are due the authors of those documents. Ran + Atkinson made a number of valuable technical and editorial + contributions to the document. + +6. Authors' Addresses + + John C. Klensin + MCI Telecommunications + 800 Boylston St, 7th floor + Boston, MA 02199 + USA + + EMail: klensin@mci.net + Phone: +1 617 960 1011 + + Randy Catoe + MCI Telecommunications + 2100 Reston Parkway + Reston, VA 22091 + USA + + EMail: randy@mci.net + Phone: +1 703 715 7366 + + Paul Krumviede + MCI Telecommunications + 2100 Reston Parkway + Reston, VA 22091 + USA + + EMail: paul@mci.net + Phone: +1 703 715 7251 + + + + + + +Klensin, Catoe & Krumviede Standards Track [Page 5] + diff --git a/RFC/rfc2449.txt b/RFC/rfc2449.txt new file mode 100644 index 00000000..dbea10b2 --- /dev/null +++ b/RFC/rfc2449.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group R. Gellens +Request for Comments: 2449 Qualcomm +Updates: 1939 C. Newman +Category: Standards Track Innosoft + L. Lundblade + Qualcomm + November 1998 + + + POP3 Extension Mechanism + +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. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +IESG Note + + This extension to the POP3 protocol is to be used by a server to + express policy descisions taken by the server administrator. It is + not an endorsement of implementations of further POP3 extensions + generally. It is the general view that the POP3 protocol should stay + simple, and for the simple purpose of downloading email from a mail + server. If more complicated operations are needed, the IMAP protocol + [RFC 2060] should be used. The first paragraph of section 7 should + be read very carefully. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Conventions Used in this Document . . . . . . . . . . . . . 3 + 3. General Command and Response Grammar . . . . . . . . . . . . 3 + 4. Parameter and Response Lengths . . . . . . . . . . . . . . 4 + 5. The CAPA Command . . . . . . . . . . . . . . . . . . . . . . 4 + 6. Initial Set of Capabilities . . . . . . . . . . . . . . . . 5 + 6.1. TOP capability . . . . . . . . . . . . . . . . . . . . . 6 + 6.2. USER capability . . . . . . . . . . . . . . . . . . . . 6 + 6.3. SASL capability . . . . . . . . . . . . . . . . . . . . 7 + 6.4. RESP-CODES capability . . . . . . . . . . . . . . . . . 8 + 6.5. LOGIN-DELAY capability . . . . . . . . . . . . . . . . . 8 + 6.6. PIPELINING capability . . . . . . . . . . . . . . . . . 9 + + + +Gellens, et. al. Standards Track [Page 1] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + 6.7. EXPIRE capability . . . . . . . . . . . . . . . . . . . 10 + 6.8. UIDL capability . . . . . . . . . . . . . . . . . . . . 13 + 6.9. IMPLEMENTATION capability . . . . . . . . . . . . . . . 13 + 7. Future Extensions to POP3 . . . . . . . . . . . . . . . . . 14 + 8. Extended POP3 Response Codes . . . . . . . . . . . . . . . . 14 + 8.1. Initial POP3 response codes . . . . . . . . . . . . . . 15 + 8.1.1. The LOGIN-DELAY response code . . . . . . . . . . . 15 + 8.1.2. The IN-USE response code . . . . . . . . . . . . . 16 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 + 10. Security Considerations . . . . . . . . . . . . . . . . . . 17 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . 17 + 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18 + 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 + +1. Introduction + + The Post Office Protocol version 3 [POP3] is very widely used. + However, while it includes some optional commands (and some useful + protocol extensions have been published), it lacks a mechanism for + advertising support for these extensions or for behavior variations. + + Currently these optional features and extensions can only be detected + by probing, if at all. This is at best inefficient, and possibly + worse. As a result, some clients have manual configuration options + for POP3 server capabilities. + + Because one of the most important characteristics of POP3 is its + simplicity, it is desirable that extensions be few in number (see + section 7). However, some extensions are necessary (such as ones + that provide improved security [POP-AUTH]), while others are very + desirable in certain situations. In addition, a means for + discovering server behavior is needed. + + This memo updates RFC 1939 [POP3] to define a mechanism to announce + support for optional commands, extensions, and unconditional server + behavior. Included is an initial set of currently deployed + capabilities which vary between server implementations, and several + new capabilities (SASL, RESP-CODES, LOGIN-DELAY, PIPELINING, EXPIRE + and IMPLEMENTATION). This document also extends POP3 error messages + so that machine parsable codes can be provided to the client. An + initial set of response codes is included. In addition, an [ABNF] + specification of POP3 commands and responses is defined. + + Public comments should be sent to the IETF POP3 Extensions mailing + list, . To subscribe, send a message + containing SUBSCRIBE to . + + + + +Gellens, et. al. Standards Track [Page 2] + +RFC 2449 POP3 Extension Mechanism November 1998 + + +2. Conventions Used in this Document + + The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", + and "MAY" in this document are to be interpreted as described in "Key + words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + +3. General Command and Response Grammar + + The general form of POP3 commands and responses is described using + [ABNF]: + + POP3 commands: + + command = keyword *(SP param) CRLF ;255 octets maximum + keyword = 3*4VCHAR + param = 1*VCHAR + + POP3 responses: + + response = greeting / single-line / capa-resp / multi-line + capa-resp = single-line *capability "." CRLF + capa-tag = 1*cchar + capability = capa-tag *(SP param) CRLF ;512 octets maximum + cchar = %x21-2D / %x2F-7F + ;printable ASCII, excluding "." + dot-stuffed = *CHAR CRLF ;must be dot-stuffed + gchar = %x21-3B / %x3D-7F + ;printable ASCII, excluding "<" + greeting = "+OK" [resp-code] *gchar [timestamp] *gchar CRLF + ;512 octets maximum + multi-line = single-line *dot-stuffed "." CRLF + rchar = %x21-2E / %x30-5C / %x5E-7F + ;printable ASCII, excluding "/" and "]" + resp-code = "[" resp-level *("/" resp-level) "]" + resp-level = 1*rchar + schar = %x21-5A / %x5C-7F + ;printable ASCII, excluding "[" + single-line = status [SP text] CRLF ;512 octets maximum + status = "+OK" / "-ERR" + text = *schar / resp-code *CHAR + timestamp = "<" *VCHAR ">" + ;MUST conform to RFC-822 msg-id + + + + + + +Gellens, et. al. Standards Track [Page 3] + +RFC 2449 POP3 Extension Mechanism November 1998 + + +4. Parameter and Response Lengths + + This specification increases the length restrictions on commands and + parameters imposed by RFC 1939. + + The maximum length of a command is increased from 47 characters (4 + character command, single space, 40 character argument, CRLF) to 255 + octets, including the terminating CRLF. + + Servers which support the CAPA command MUST support commands up to + 255 octets. Servers MUST also support the largest maximum command + length specified by any supported capability. + + The maximum length of the first line of a command response (including + the initial greeting) is unchanged at 512 octets (including the + terminating CRLF). + +5. The CAPA Command + + The POP3 CAPA command returns a list of capabilities supported by the + POP3 server. It is available in both the AUTHORIZATION and + TRANSACTION states. + + A capability description MUST document in which states the capability + is announced, and in which states the commands are valid. + + Capabilities available in the AUTHORIZATION state MUST be announced + in both states. + + If a capability is announced in both states, but the argument might + differ after authentication, this possibility MUST be stated in the + capability description. + + (These requirements allow a client to issue only one CAPA command if + it does not use any TRANSACTION-only capabilities, or any + capabilities whose values may differ after authentication.) + + If the authentication step negotiates an integrity protection layer, + the client SHOULD reissue the CAPA command after authenticating, to + check for active down-negotiation attacks. + + Each capability may enable additional protocol commands, additional + parameters and responses for existing commands, or describe an aspect + of server behavior. These details are specified in the description + of the capability. + + + + + + +Gellens, et. al. Standards Track [Page 4] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + Section 3 describes the CAPA response using [ABNF]. When a + capability response describes an optional command, the + SHOULD be identical to the command keyword. CAPA response tags are + case-insensitive. + + CAPA + + Arguments: + none + + Restrictions: + none + + Discussion: + An -ERR response indicates the capability command is not + implemented and the client will have to probe for + capabilities as before. + + An +OK response is followed by a list of capabilities, one + per line. Each capability name MAY be followed by a single + space and a space-separated list of parameters. Each + capability line is limited to 512 octets (including the + CRLF). The capability list is terminated by a line + containing a termination octet (".") and a CRLF pair. + + Possible Responses: + +OK -ERR + + Examples: + C: CAPA + S: +OK Capability list follows + S: TOP + S: USER + S: SASL CRAM-MD5 KERBEROS_V4 + S: RESP-CODES + S: LOGIN-DELAY 900 + S: PIPELINING + S: EXPIRE 60 + S: UIDL + S: IMPLEMENTATION Shlemazle-Plotz-v302 + S: . + +6. Initial Set of Capabilities + + This section defines an initial set of POP3 capabilities. These + include the optional POP3 commands, already published POP3 + extensions, and behavior variations between POP3 servers which can + impact clients. + + + +Gellens, et. al. Standards Track [Page 5] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + Note that there is no APOP capability, even though APOP is an + optional command in [POP3]. Clients discover server support of APOP + by the presence in the greeting banner of an initial challenge + enclosed in angle brackets ("<>"). Therefore, an APOP capability + would introduce two ways for a server to announce the same thing. + +6.1. TOP capability + + CAPA tag: + TOP + + Arguments: + none + + Added commands: + TOP + + Standard commands affected: + none + + Announced states / possible differences: + both / no + + Commands valid in states: + TRANSACTION + + Specification reference: + [POP3] + + Discussion: + The TOP capability indicates the optional TOP command is + available. + +6.2. USER capability + + CAPA tag: + USER + + Arguments: + none + + Added commands: + USER PASS + + Standard commands affected: + none + + + + + +Gellens, et. al. Standards Track [Page 6] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + Announced states / possible differences: + both / no + + Commands valid in states: + AUTHENTICATION + + Specification reference: + [POP3] + + Discussion: + The USER capability indicates that the USER and PASS commands + are supported, although they may not be available to all users. + +6.3. SASL capability + + CAPA tag: + SASL + + Arguments: + Supported SASL mechanisms + + Added commands: + AUTH + + Standard commands affected: + none + + Announced states / possible differences: + both / no + + Commands valid in states: + AUTHENTICATION + + Specification reference: + [POP-AUTH, SASL] + + Discussion: + The POP3 AUTH command [POP-AUTH] permits the use of [SASL] + authentication mechanisms with POP3. The SASL capability + indicates that the AUTH command is available and that it supports + an optional base64 encoded second argument for an initial client + response as described in the SASL specification. The argument to + the SASL capability is a space separated list of SASL mechanisms + which are supported. + + + + + + + +Gellens, et. al. Standards Track [Page 7] + +RFC 2449 POP3 Extension Mechanism November 1998 + + +6.4. RESP-CODES capability + + CAPA tag: + RESP-CODES + + Arguments: + none + + Added commands: + none + + Standard commands affected: + none + + Announced states / possible differences: + both / no + + Commands valid in states: + n/a + + Specification reference: + this document + + Discussion: + The RESP-CODES capability indicates that any response text issued + by this server which begins with an open square bracket ("[") is + an extended response code (see section 8). + +6.5. LOGIN-DELAY capability + + CAPA tag: + LOGIN-DELAY + + Arguments: + minimum seconds between logins; optionally followed by USER in + AUTHENTICATION state. + + Added commands: + none + + Standard commands affected: + USER PASS APOP AUTH + + Announced states / possible differences: + both / yes + + Commands valid in states: + n/a + + + +Gellens, et. al. Standards Track [Page 8] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + Specification reference: + this document + + Discussion: + POP3 clients often login frequently to check for new mail. + Unfortunately, the process of creating a connection, + authenticating the user, and opening the user's maildrop can be + very resource intensive on the server. A number of deployed POP3 + servers try to reduce server load by requiring a delay between + logins. The LOGIN-DELAY capability includes an integer argument + which indicates the number of seconds after an "+OK" response to + a PASS, APOP, or AUTH command before another authentication will + be accepted. Clients which permit the user to configure a mail + check interval SHOULD use this capability to determine the + minimum permissible interval. Servers which advertise LOGIN- + DELAY SHOULD enforce it. + + If the minimum login delay period could differ per user (that is, + the LOGIN-DELAY argument might change after authentication), the + server MUST announce in AUTHENTICATION state the largest value + which could be set for any user. This might be the largest value + currently in use for any user (so only one value per server), or + even the largest value which the server permits to be set for any + user. The server SHOULD append the token "USER" to the LOGIN- + DELAY parameter in AUTHENTICATION state, to inform the client + that a more accurate value is available after authentication. + The server SHOULD announce the more accurate value in TRANSACTION + state. (The "USER" token allows the client to decide if a second + CAPA command is needed or not.) + + Servers enforce LOGIN-DELAY by rejecting an authentication + command with or without the LOGIN-DELAY error response. See + section 8.1.1 for more information. + +6.6. PIPELINING capability + + CAPA tag: + PIPELINING + + Arguments: + none + + Added commands: + none + + Standard commands affected: + all + + + + +Gellens, et. al. Standards Track [Page 9] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + Announced states / possible differences: + both / no + + Commands valid in states: + n/a + + Specification reference: + this document + + Discussion: + The PIPELINING capability indicates the server is capable of + accepting multiple commands at a time; the client does not have + to wait for the response to a command before issuing a subsequent + command. If a server supports PIPELINING, it MUST process each + command in turn. If a client uses PIPELINING, it MUST keep track + of which commands it has outstanding, and match server responses + to commands in order. If either the client or server uses + blocking writes, it MUST not exceed the window size of the + underlying transport layer. + + Some POP3 clients have an option to indicate the server supports + "Overlapped POP3 commands." This capability removes the need to + configure this at the client. + + This is roughly synonymous with the ESMTP PIPELINING extension + [PIPELINING], however, since SMTP [SMTP] tends to have short + commands and responses, the benefit is in grouping multiple + commands and sending them as a unit. While there are cases of + this in POP (for example, USER and PASS could be batched, + multiple RETR and/or DELE commands could be sent as a group), + because POP has short commands and sometimes lengthy responses, + there is also an advantage is sending new commands while still + receiving the response to an earlier command (for example, + sending RETR and/or DELE commands while processing a UIDL reply). + +6.7. EXPIRE capability + + CAPA tag: + EXPIRE + + Arguments: + server-guaranteed minimum retention days, or NEVER; optionally + followed by USER in AUTHENTICATION state + + Added commands: + none + + + + + +Gellens, et. al. Standards Track [Page 10] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + Standard commands affected: + none + + Announced states / possible differences: + both / yes + + Commands valid in states: + n/a + + Specification reference: + this document + + Discussion: + While POP3 allows clients to leave messages on the server, RFC + 1939 [POP3] warns about the problems that may arise from this, + and allows servers to delete messages based on site policy. + + The EXPIRE capability avoids the problems mentioned in RFC 1939, + by allowing the server to inform the client as to the policy in + effect. The argument to the EXPIRE capability indicates the + minimum server retention period, in days, for messages on the + server. + + EXPIRE 0 indicates the client is not permitted to leave mail on + the server; when the session enters the UPDATE state the server + MAY assume an implicit DELE for each message which was downloaded + with RETR. + + EXPIRE NEVER asserts that the server does not delete messages. + + The concept of a "retention period" is intentionally vague. + Servers may start counting days to expiration when a message is + added to a maildrop, when a client becomes aware of the existence + of a message through the LIST or UIDL commands, when a message + has been acted upon in some way (for example, TOP or RETR), or at + some other event. The EXPIRE capability cannot provide a precise + indication as to exactly when any specific message will expire. + The capability is intended to make it easier for clients to + behave in ways which conform to site policy and user wishes. For + example, a client might display a warning for attempts to + configure a "leave mail on server" period which is greater than + or equal to some percentage of the value announced by the server. + + If a site uses any automatic deletion policy, it SHOULD use the + EXPIRE capability to announce this. + + + + + + +Gellens, et. al. Standards Track [Page 11] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + The EXPIRE capability, with a parameter other than 0 or NEVER, is + intended to let the client know that the server does permit mail + to be left on the server, and to present a value which is the + smallest which might be in force. + + Sites which permit users to retain messages indefinitely SHOULD + announce this with the EXPIRE NEVER response. + + If the expiration policy differs per user (that is, the EXPIRE + argument might change after authentication), the server MUST + announce in AUTHENTICATION state the smallest value which could + be set for any user. This might be the smallest value currently + in use for any user (so only one value per server), or even the + smallest value which the server permits to be set for any user. + The server SHOULD append the token "USER" to the EXPIRE parameter + in AUTHENTICATION state, to inform the client that a more + accurate value is available after authentication. The server + SHOULD announce the more accurate value in TRANSACTION state. + (The "USER" token allows the client to decide if a second CAPA + command is needed or not.) + + A site may have a message expiration policy which treats messages + differently depending on which user actions have been performed, + or based on other factors. For example, a site might delete + unseen messages after 60 days, and completely- or partially-seen + messages after 15 days. + + The announced EXPIRE value is the smallest retention period which + is or might be used by any category or condition of the current + site policy, for any user (in AUTHENTICATION state) or the + specific user (in TRANSACTION state). That is, EXPIRE informs + the client of the minimum number of days messages may remain on + the server under any circumstances. + + Examples: + EXPIRE 5 USER + EXPIRE 30 + EXPIRE NEVER + EXPIRE 0 + + The first example indicates the server might delete messages + after five days, but the period differs per user, and so a more + accurate value can be obtained by issuing a second CAPA command + in TRANSACTION state. The second example indicates the server + could delete messages after 30 days. In the third example, the + server announces it does not delete messages. The fourth example + specifies that the site does not permit messages to be left on + the server. + + + +Gellens, et. al. Standards Track [Page 12] + +RFC 2449 POP3 Extension Mechanism November 1998 + + +6.8. UIDL capability + + CAPA tag: + UIDL + + Arguments: + none + + Added commands: + UIDL + + Standard commands affected: + none + + Announced states / possible differences: + both / no + + Commands valid in states: + TRANSACTION + + Specification reference: + [POP3] + + Discussion: + The UIDL capability indicates that the optional UIDL command is + supported. + +6.9. IMPLEMENTATION capability + + CAPA tag: + IMPLEMENTATION + + Arguments: + string giving server implementation information + + Added commands: + none + + Standard commands affected: + none + + Announced states / possible differences: + both (optionally TRANSACTION only) / no + + Commands valid in states: + n/a + + + + + +Gellens, et. al. Standards Track [Page 13] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + Specification reference: + this document + + Discussion: + It is often useful to identify an implementation of a particular + server (for example, when logging). This is commonly done in the + welcome banner, but one must guess if a string is an + implementation ID or not. + + The argument to the IMPLEMENTATION capability consists of one or + more tokens which identify the server. (Note that since CAPA + response tag arguments are space-separated, it may be convenient + for the IMPLEMENTATION capability argument to not contain spaces, + so that it is a single token.) + + Normally, servers announce IMPLEMENTATION in both states. + However, a server MAY chose to do so only in TRANSACTION state. + + A server MAY include the implementation identification both in + the welcome banner and in the IMPLEMENTATION capability. + + Clients MUST NOT modify their behavior based on the server + implementation. Instead the server and client should agree on a + private extension. + +7. Future Extensions to POP3 + + Future extensions to POP3 are in general discouraged, as POP3's + usefulness lies in its simplicity. POP3 is intended as a download- + and-delete protocol; mail access capabilities are available in IMAP + [IMAP4]. Extensions which provide support for additional mailboxes, + allow uploading of messages to the server, or which deviate from + POP's download-and-delete model are strongly discouraged and unlikely + to be permitted on the IETF standards track. + + Clients MUST NOT require the presence of any extension for basic + functionality, with the exception of the authentication commands + (APOP, AUTH [section 6.3] and USER/PASS). + + Section 9 specifies how additional capabilities are defined. + +8. Extended POP3 Response Codes + + Unextended POP3 is only capable of indicating success or failure to + most commands. Unfortunately, clients often need to know more + information about the cause of a failure in order to gracefully + recover. This is especially important in response to a failed login + + + + +Gellens, et. al. Standards Track [Page 14] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + (there are widely-deployed clients which attempt to decode the error + text of a PASS command result, to try and distinguish between "unable + to get maildrop lock" and "bad login"). + + This specification amends the POP3 standard to permit an optional + response code, enclosed in square brackets, at the beginning of the + human readable text portion of an "+OK" or "-ERR" response. Clients + supporting this extension MAY remove any information enclosed in + square brackets prior to displaying human readable text to the user. + Immediately following the open square bracket "[" character is a + response code which is interpreted in a case-insensitive fashion by + the client. + + The response code is hierarchical, with a "/" separating levels of + detail about the error. Clients MUST ignore unknown hierarchical + detail about the response code. This is important, as it could be + necessary to provide further detail for response codes in the future. + + Section 3 describes response codes using [ABNF]. + + If a server supports extended response codes, it indicates this by + including the RESP-CODES capability in the CAPA response. + + Examples: + C: APOP mrose c4c9334bac560ecc979e58001b3e22fb + S: -ERR [IN-USE] Do you have another POP session running? + +8.1. Initial POP3 response codes + + This specification defines two POP3 response codes which can be used + to determine the reason for a failed login. Section 9 specifies how + additional response codes are defined. + +8.1.1. The LOGIN-DELAY response code + + This occurs on an -ERR response to an AUTH, USER (see note), PASS or + APOP command and indicates that the user has logged in recently and + will not be allowed to login again until the login delay period has + expired. + + NOTE: Returning the LOGIN-DELAY response code to the USER command + avoids the work of authenticating the user but reveals to the client + that the specified user exists. Unless the server is operating in an + environment where user names are not secret (for example, many + popular email clients advertise the POP server and user name in an + outgoing mail header), or where server access is restricted, or the + server can verify that the connection is to the same user, it is + + + + +Gellens, et. al. Standards Track [Page 15] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + strongly recommended that the server not issue this response code to + the USER command. The server still saves the cost of opening the + maildrop, which in some environments is the most expensive step. + +8.1.2. The IN-USE response code + + This occurs on an -ERR response to an AUTH, APOP, or PASS command. + It indicates the authentication was successful, but the user's + maildrop is currently in use (probably by another POP3 client). + +9. IANA Considerations + + This document requests that IANA maintain two new registries: POP3 + capabilities and POP3 response codes. + + New POP3 capabilities MUST be defined in a standards track or IESG + approved experimental RFC, and MUST NOT begin with the letter "X". + + New POP3 capabilities MUST include the following information: + CAPA tag + Arguments + Added commands + Standard commands affected + Announced states / possible differences + Commands valid in states + Specification reference + Discussion + + In addition, new limits for POP3 command and response lengths may + need to be included. + + New POP3 response codes MUST be defined in an RFC or other permanent + and readily available reference, in sufficient detail so that + interoperability between independent implementations is possible. + (This is the "Specification Required" policy described in [IANA]). + + New POP3 response code specifications MUST include the following + information: the complete response code, for which responses (+OK + or -ERR) and commands it is valid, and a definition of its meaning and + expected client behavior. + + + + + + + + + + + +Gellens, et. al. Standards Track [Page 16] + +RFC 2449 POP3 Extension Mechanism November 1998 + + +10. Security Considerations + + A capability list can reveal information about the server's + authentication mechanisms which can be used to determine if certain + attacks will be successful. However, allowing clients to + automatically detect availability of stronger mechanisms and alter + their configurations to use them can improve overall security at a + site. + + Section 8.1 discusses the security issues related to use of the + LOGIN-DELAY response code with the USER command. + +11. Acknowledgments + + This document has been revised in part based on comments and + discussions which took place on and off the IETF POP3 Extensions + mailing list. The help of those who took the time to review this + memo and make suggestions is appreciated, especially that of Alexey + Melnikov, Harald Alvestrand, and Mike Gahrns. + +12. References + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [IMAP4] Crispin, M., "Internet Message Access Protocol -- + Version 4rev1", RFC 2060, December 1996. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [PIPELINING] Freed, N., "SMTP Service Extension for Command + Pipelining", RFC 2197, September 1997. + + [POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version + 3", STD 53, RFC 1939, May 1996. + + [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, + December 1994. + + [SASL] Myers, J., "Simple Authentication and Security Layer + (SASL)", RFC 2222, October 1997. + + + + + +Gellens, et. al. Standards Track [Page 17] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC + 821, August 1982. + +13. Authors' Addresses + + Randall Gellens + QUALCOMM Incorporated + 6455 Lusk Blvd. + San Diego, CA 92121-2779 + USA + + Phone: +1 619 651 5115 + Fax: +1 619 845 7268 + EMail: randy@qualcomm.com + + + Chris Newman + Innosoft International, Inc. + 1050 Lakes Drive + West Covina, CA 91790 + USA + + EMail: chris.newman@innosoft.com + + + Laurence Lundblade + QUALCOMM Incorporated + 6455 Lusk Blvd. + San Diego, Ca, 92121-2779 + USA + + Phone: +1 619 658 3584 + Fax: +1 619 845 7268 + EMail: lgl@qualcomm.com + + + + + + + + + + + + + + + + + +Gellens, et. al. Standards Track [Page 18] + +RFC 2449 POP3 Extension Mechanism November 1998 + + +14. Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Gellens, et. al. Standards Track [Page 19] + diff --git a/RFC/rfc2554.txt b/RFC/rfc2554.txt new file mode 100644 index 00000000..2922deae --- /dev/null +++ b/RFC/rfc2554.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group J. Myers +Request for Comments: 2554 Netscape Communications +Category: Standards Track March 1999 + + + SMTP Service Extension + for Authentication + +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. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + +1. Introduction + + This document defines an SMTP service extension [ESMTP] whereby an + SMTP client may indicate an authentication mechanism to the server, + perform an authentication protocol exchange, and optionally negotiate + a security layer for subsequent protocol interactions. This + extension is a profile of the Simple Authentication and Security + Layer [SASL]. + + +2. Conventions Used in this Document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" + in this document are to be interpreted as defined in "Key words for + use in RFCs to Indicate Requirement Levels" [KEYWORDS]. + + +3. The Authentication service extension + + + (1) the name of the SMTP service extension is "Authentication" + + (2) the EHLO keyword value associated with this extension is "AUTH" + + + + +Myers Standards Track [Page 1] + +RFC 2554 SMTP Authentication March 1999 + + + (3) The AUTH EHLO keyword contains as a parameter a space separated + list of the names of supported SASL mechanisms. + + (4) a new SMTP verb "AUTH" is defined + + (5) an optional parameter using the keyword "AUTH" is added to the + MAIL FROM command, and extends the maximum line length of the + MAIL FROM command by 500 characters. + + (6) this extension is appropriate for the submission protocol + [SUBMIT]. + + +4. The AUTH command + + AUTH mechanism [initial-response] + + Arguments: + a string identifying a SASL authentication mechanism. + an optional base64-encoded response + + Restrictions: + After an AUTH command has successfully completed, no more AUTH + commands may be issued in the same session. After a successful + AUTH command completes, a server MUST reject any further AUTH + commands with a 503 reply. + + The AUTH command is not permitted during a mail transaction. + + Discussion: + The AUTH command indicates an authentication mechanism to the + server. If the server supports the requested authentication + mechanism, it performs an authentication protocol exchange to + authenticate and identify the user. Optionally, it also + negotiates a security layer for subsequent protocol + interactions. If the requested authentication mechanism is not + supported, the server rejects the AUTH command with a 504 + reply. + + The authentication protocol exchange consists of a series of + server challenges and client answers that are specific to the + authentication mechanism. A server challenge, otherwise known + as a ready response, is a 334 reply with the text part + containing a BASE64 encoded string. The client answer consists + of a line containing a BASE64 encoded string. If the client + wishes to cancel an authentication exchange, it issues a line + with a single "*". If the server receives such an answer, it + MUST reject the AUTH command by sending a 501 reply. + + + +Myers Standards Track [Page 2] + +RFC 2554 SMTP Authentication March 1999 + + + The optional initial-response argument to the AUTH command is + used to save a round trip when using authentication mechanisms + that are defined to send no data in the initial challenge. + When the initial-response argument is used with such a + mechanism, the initial empty challenge is not sent to the + client and the server uses the data in the initial-response + argument as if it were sent in response to the empty challenge. + Unlike a zero-length client answer to a 334 reply, a zero- + length initial response is sent as a single equals sign ("="). + If the client uses an initial-response argument to the AUTH + command with a mechanism that sends data in the initial + challenge, the server rejects the AUTH command with a 535 + reply. + + If the server cannot BASE64 decode the argument, it rejects the + AUTH command with a 501 reply. If the server rejects the + authentication data, it SHOULD reject the AUTH command with a + 535 reply unless a more specific error code, such as one listed + in section 6, is appropriate. Should the client successfully + complete the authentication exchange, the SMTP server issues a + 235 reply. + + The service name specified by this protocol's profile of SASL + is "smtp". + + If a security layer is negotiated through the SASL + authentication exchange, it takes effect immediately following + the CRLF that concludes the authentication exchange for the + client, and the CRLF of the success reply for the server. Upon + a security layer's taking effect, the SMTP protocol is reset to + the initial state (the state in SMTP after a server issues a + 220 service ready greeting). The server MUST discard any + knowledge obtained from the client, such as the argument to the + EHLO command, which was not obtained from the SASL negotiation + itself. The client MUST discard any knowledge obtained from + the server, such as the list of SMTP service extensions, which + was not obtained from the SASL negotiation itself (with the + exception that a client MAY compare the list of advertised SASL + mechanisms before and after authentication in order to detect + an active down-negotiation attack). The client SHOULD send an + EHLO command as the first command after a successful SASL + negotiation which results in the enabling of a security layer. + + The server is not required to support any particular + authentication mechanism, nor are authentication mechanisms + required to support any security layers. If an AUTH command + fails, the client may try another authentication mechanism by + issuing another AUTH command. + + + +Myers Standards Track [Page 3] + +RFC 2554 SMTP Authentication March 1999 + + + If an AUTH command fails, the server MUST behave the same as if + the client had not issued the AUTH command. + + The BASE64 string may in general be arbitrarily long. Clients + and servers MUST be able to support challenges and responses + that are as long as are generated by the authentication + mechanisms they support, independent of any line length + limitations the client or server may have in other parts of its + protocol implementation. + + Examples: + S: 220 smtp.example.com ESMTP server ready + C: EHLO jgm.example.com + S: 250-smtp.example.com + S: 250 AUTH CRAM-MD5 DIGEST-MD5 + C: AUTH FOOBAR + S: 504 Unrecognized authentication type. + C: AUTH CRAM-MD5 + S: 334 + PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4= + C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ== + S: 235 Authentication successful. + + + +5. The AUTH parameter to the MAIL FROM command + + AUTH=addr-spec + + Arguments: + An addr-spec containing the identity which submitted the message + to the delivery system, or the two character sequence "<>" + indicating such an identity is unknown or insufficiently + authenticated. To comply with the restrictions imposed on ESMTP + parameters, the addr-spec is encoded inside an xtext. The syntax + of an xtext is described in section 5 of [ESMTP-DSN]. + + Discussion: + The optional AUTH parameter to the MAIL FROM command allows + cooperating agents in a trusted environment to communicate the + authentication of individual messages. + + If the server trusts the authenticated identity of the client to + assert that the message was originally submitted by the supplied + addr-spec, then the server SHOULD supply the same addr-spec in an + AUTH parameter when relaying the message to any server which + supports the AUTH extension. + + + + +Myers Standards Track [Page 4] + +RFC 2554 SMTP Authentication March 1999 + + + A MAIL FROM parameter of AUTH=<> indicates that the original + submitter of the message is not known. The server MUST NOT treat + the message as having been originally submitted by the client. + + If the AUTH parameter to the MAIL FROM is not supplied, the + client has authenticated, and the server believes the message is + an original submission by the client, the server MAY supply the + client's identity in the addr-spec in an AUTH parameter when + relaying the message to any server which supports the AUTH + extension. + + If the server does not sufficiently trust the authenticated + identity of the client, or if the client is not authenticated, + then the server MUST behave as if the AUTH=<> parameter was + supplied. The server MAY, however, write the value of the AUTH + parameter to a log file. + + If an AUTH=<> parameter was supplied, either explicitly or due to + the requirement in the previous paragraph, then the server MUST + supply the AUTH=<> parameter when relaying the message to any + server which it has authenticated to using the AUTH extension. + + A server MAY treat expansion of a mailing list as a new + submission, setting the AUTH parameter to the mailing list + address or mailing list administration address when relaying the + message to list subscribers. + + It is conforming for an implementation to be hard-coded to treat + all clients as being insufficiently trusted. In that case, the + implementation does nothing more than parse and discard + syntactically valid AUTH parameters to the MAIL FROM command and + supply AUTH=<> parameters to any servers to which it + authenticates using the AUTH extension. + + Examples: + C: MAIL FROM: AUTH=e+3Dmc2@example.com + S: 250 OK + + + + + + + + + + + + + + +Myers Standards Track [Page 5] + +RFC 2554 SMTP Authentication March 1999 + + +6. Error Codes + + The following error codes may be used to indicate various conditions + as described. + + 432 A password transition is needed + + This response to the AUTH command indicates that the user needs to + transition to the selected authentication mechanism. This typically + done by authenticating once using the PLAIN authentication mechanism. + + 534 Authentication mechanism is too weak + + This response to the AUTH command indicates that the selected + authentication mechanism is weaker than server policy permits for + that user. + + 538 Encryption required for requested authentication mechanism + + This response to the AUTH command indicates that the selected + authentication mechanism may only be used when the underlying SMTP + connection is encrypted. + + 454 Temporary authentication failure + + This response to the AUTH command indicates that the authentication + failed due to a temporary server failure. + + 530 Authentication required + + This response may be returned by any command other than AUTH, EHLO, + HELO, NOOP, RSET, or QUIT. It indicates that server policy requires + authentication in order to perform the requested action. + + + + + + + + + + + + + + + + + + +Myers Standards Track [Page 6] + +RFC 2554 SMTP Authentication March 1999 + + +7. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in [ABNF]. + + Except as noted otherwise, all alphabetic characters are case- + insensitive. The use of upper or lower case characters to define + token strings is for editorial clarity only. Implementations MUST + accept these strings in a case-insensitive fashion. + + UPALPHA = %x41-5A ;; Uppercase: A-Z + + LOALPHA = %x61-7A ;; Lowercase: a-z + + ALPHA = UPALPHA / LOALPHA ;; case insensitive + + DIGIT = %x30-39 ;; Digits 0-9 + + HEXDIGIT = %x41-46 / DIGIT ;; hexidecimal digit (uppercase) + + hexchar = "+" HEXDIGIT HEXDIGIT + + xchar = %x21-2A / %x2C-3C / %x3E-7E + ;; US-ASCII except for "+", "=", SPACE and CTL + + xtext = *(xchar / hexchar) + + AUTH_CHAR = ALPHA / DIGIT / "-" / "_" + + auth_type = 1*20AUTH_CHAR + + auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")] + *(CRLF [base64]) CRLF + + auth_param = "AUTH=" xtext + ;; The decoded form of the xtext MUST be either + ;; an addr-spec or the two characters "<>" + + base64 = base64_terminal / + ( 1*(4base64_CHAR) [base64_terminal] ) + + base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/" + ;; Case-sensitive + + base64_terminal = (2base64_char "==") / (3base64_char "=") + + continue_req = "334" SPACE [base64] CRLF + + + + +Myers Standards Track [Page 7] + +RFC 2554 SMTP Authentication March 1999 + + + CR = %x0C ;; ASCII CR, carriage return + + CRLF = CR LF + + CTL = %x00-1F / %x7F ;; any ASCII control character and DEL + + LF = %x0A ;; ASCII LF, line feed + + SPACE = %x20 ;; ASCII SP, space + + + + +8. References + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP + AUTHorize Extension for Simple Challenge/Response", RFC + 2195, September 1997. + + [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. + Crocker, "SMTP Service Extensions", RFC 1869, November + 1995. + + [ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status + Notifications", RFC 1891, January 1996. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [SASL] Myers, J., "Simple Authentication and Security Layer + (SASL)", RFC 2222, October 1997. + + [SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC + 2476, December 1998. + + [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC + 821, August 1982. + + [RFC822] Crocker, D., "Standard for the Format of ARPA Internet + Text Messages", STD 11, RFC 822, August 1982. + + + + + + + + +Myers Standards Track [Page 8] + +RFC 2554 SMTP Authentication March 1999 + + +9. Security Considerations + + Security issues are discussed throughout this memo. + + If a client uses this extension to get an encrypted tunnel through an + insecure network to a cooperating server, it needs to be configured + to never send mail to that server when the connection is not mutually + authenticated and encrypted. Otherwise, an attacker could steal the + client's mail by hijacking the SMTP connection and either pretending + the server does not support the Authentication extension or causing + all AUTH commands to fail. + + Before the SASL negotiation has begun, any protocol interactions are + performed in the clear and may be modified by an active attacker. + For this reason, clients and servers MUST discard any knowledge + obtained prior to the start of the SASL negotiation upon completion + of a SASL negotiation which results in a security layer. + + This mechanism does not protect the TCP port, so an active attacker + may redirect a relay connection attempt to the submission port + [SUBMIT]. The AUTH=<> parameter prevents such an attack from causing + an relayed message without an envelope authentication to pick up the + authentication of the relay client. + + A message submission client may require the user to authenticate + whenever a suitable SASL mechanism is advertised. Therefore, it may + not be desirable for a submission server [SUBMIT] to advertise a SASL + mechanism when use of that mechanism grants the client no benefits + over anonymous submission. + + This extension is not intended to replace or be used instead of end- + to-end message signature and encryption systems such as S/MIME or + PGP. This extension addresses a different problem than end-to-end + systems; it has the following key differences: + + (1) it is generally useful only within a trusted enclave + + (2) it protects the entire envelope of a message, not just the + message's body. + + (3) it authenticates the message submission, not authorship of the + message content + + (4) it can give the sender some assurance the message was + delivered to the next hop in the case where the sender + mutually authenticates with the next hop and negotiates an + appropriate security layer. + + + + +Myers Standards Track [Page 9] + +RFC 2554 SMTP Authentication March 1999 + + + Additional security considerations are mentioned in the SASL + specification [SASL]. + + + +10. Author's Address + + John Gardiner Myers + Netscape Communications + 501 East Middlefield Road + Mail Stop MV-029 + Mountain View, CA 94043 + + EMail: jgmyers@netscape.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Myers Standards Track [Page 10] + +RFC 2554 SMTP Authentication March 1999 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Myers Standards Track [Page 11] + diff --git a/RFC/rfc2645.txt b/RFC/rfc2645.txt new file mode 100644 index 00000000..cb99fc84 --- /dev/null +++ b/RFC/rfc2645.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group R. Gellens +Request for Comments: 2645 Qualcomm +Category: Standards Track August 1999 + + + ON-DEMAND MAIL RELAY (ODMR) + SMTP with Dynamic IP Addresses + +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. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +Table of Contents + + 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 1 + 2. Conventions Used in this Document . . . . . . . . . . . . . . 2 + 3. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 4. Description . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 5. States . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 5.1. Initial State . . . . . . . . . . . . . . . . . . . . . . 4 + 5.1.1. EHLO . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5.1.2. AUTH . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5.1.3. QUIT . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5.2. Authenticated State . . . . . . . . . . . . . . . . . . . 4 + 5.2.1. ATRN (Authenticated TURN) . . . . . . . . . . . . . 4 + 5.3. Reversed State . . . . . . . . . . . . . . . . . . . . . 5 + 5.4. Other Commands . . . . . . . . . . . . . . . . . . . . . 6 + 6. Example On-Demand Mail Relay Session: . . . . . . . . . . . . 6 + 7. Response Codes . . . . . . . . . . . . . . . . . . . . . . . 6 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 7 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 11. Author's Address . . . . . . . . . . . . . . . . . . . . . 8 + 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 9 + +1. Abstract + + With the spread of low-cost computer systems and Internet + connectivity, the demand for local mail servers has been rising. + Many people now want to operate a mail server on a system which has + + + +Gellens Standards Track [Page 1] + +RFC 2645 On-Demand Mail Relay August 1999 + + + only an intermittent connection to a service provider. If the system + has a static IP address, the ESMTP ETRN command [ETRN] can be used. + However, systems with dynamic IP addresses (which are very common + with low-cost connections) have no widely-deployed solution. + + This memo proposes a new service, On-Demand Mail Relay (ODMR), which + is a profile of SMTP [SMTP, ESMTP], providing for a secure, + extensible, easy to implement approach to the problem. + +2. Conventions Used in this Document + + Because the client and server roles reverse during the session, to + avoid confusion, the terms "customer" and "provider" will be used in + place of "client" and "server", although of course this protocol may + be useful in cases other than commercial service providers and + customers. + + In examples, "P:" is used to indicate lines sent by the provider, and + "C:" indicates those sent by the customer. Line breaks within a + command are for editorial purposes only. + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" + in this document are to be interpreted as defined in [KEYWORDS]. + + Examples use 'example.net' as the provider, and 'example.org' and ' + example.com' as the customers. + +3. Comments + + Private comments should be sent to the author. Public comments may + be sent to the IETF Disconnected SMTP mailing list, + . To subscribe, send a message to + containing the word SUBSCRIBE as + the body. + +4. Description + + On-Demand Mail Relay is a restricted profile of SMTP [SMTP, ESMTP]. + Port 366 is reserved for On-Demand Mail Relay. The initial client + and server roles are short-lived, as the point is to allow the + intermittently-connected host to request mail held for it by a + service provider. + + The customer initiates a connection to the provider, authenticates, + and requests its mail. The roles of client and server then reverse, + and normal SMTP [SMTP, ESMTP] proceeds. + + + + + +Gellens Standards Track [Page 2] + +RFC 2645 On-Demand Mail Relay August 1999 + + + The provider has an On-Demand Mail Relay process listening for + connections on the ODMR port. This process does not need to be a + full SMTP server. It does need to be an SMTP client with access to + the outgoing mail queues, and as a server implement the EHLO, AUTH, + ATRN, and QUIT commands. + + An MTA normally has a mail client component which processes the + outgoing mail queues, attempting to send mail for particular domains, + based on time or event (such as new mail being placed in the queue, + or receipt of an ETRN command by the SMTP server component). The + On-Demand Mail Relay service processes the outgoing queue not on a + timer or new mail creation, but on request. + + The provider side has normal SMTP server responsibilities [SMTP], + including generation of delivery failure notices, etc. as needed. + +5. States + + The On-Demand Mail Relay service has three states: an initial state, + an authenticated state, and a reversed state. The state progression + is illustrated in the following diagram: + + --------------------------- + ! initial state ! + --------------------------- + ! ! + QUIT AUTH + ! ! + ! V + ! ----------------------- + ! ! authenticated state ! + ! ----------------------- + ! ! ! + ! QUIT ATRN + ! ! ! + ! ! V + ! ! ------------------ + ! ! ! reversed state ! + ! ! ------------------ + ! ! ! + ! ! QUIT + ! ! ! + V V V + --------------------- + ! termination ! + --------------------- + + + + + +Gellens Standards Track [Page 3] + +RFC 2645 On-Demand Mail Relay August 1999 + + + (Note that in the reversed state, commands are sent by the provider, + not the customer.) + +5.1. Initial State + + In the initial state, the provider is the server and the customer is + the client. Three commands are valid: EHLO, AUTH, and QUIT. + +5.1.1. EHLO + + The EHLO command is the same as in [ESMTP]. The response MUST + include AUTH and ATRN. + +5.1.2. AUTH + + The AUTH command is specified in [AUTH]. The AUTH command uses a + [SASL] mechanism to authenticate the session. The session is not + considered authenticated until a success response to AUTH has been + sent. + + For interoperability, implementations MUST support the CRAM-MD5 + mechanism [CRAM]. Other SASL mechanisms may be supported. A site + MAY disable CRAM-MD5 support if it uses more secure methods. The + EXTERNAL mechanism [SASL] might be useful in some cases, for example, + if the provider has already authenticated the client, such as during + a PPP connection. + +5.1.3. QUIT + + The QUIT command is the same as in [SMTP]. + +5.2. Authenticated State + + The authenticated state is entered after a successful AUTH command. + Two commands are valid in the authenticated state: ATRN and QUIT. + +5.2.1. ATRN (Authenticated TURN) + + Unlike the TURN command in [SMTP], the ATRN command optionally takes + one or more domains as a parameter. The ATRN command MUST be + rejected if the session has not been authenticated. Response code + 530 [AUTH] is used for this. + + The timeout for this command MUST be at least 10 minutes to allow the + provider time to process its mail queue. + + An ATRN command sent with no domains is equivalent to an ATRN command + specifying all domains to which the customer has access. + + + +Gellens Standards Track [Page 4] + +RFC 2645 On-Demand Mail Relay August 1999 + + + If the authentication used by the customer does not provide access to + all of the domains specified in ATRN, the provider MUST NOT send mail + for any domains to the customer; the provider MUST reject the ATRN + command with a 450 code. + + If the customer does have access to all of the specified domains, but + none of them have any queued mail, the provider normally rejects the + ATRN command with response code 453. The provider MAY instead issue + a 250 success code, and after the roles are reversed, send a QUIT + following the EHLO. + + The provider MAY also reject the ATRN command with a 450 response to + indicate refusal to accept multiple requests issued within a + particular time interval. + + If the customer has access to all of the specified domains and mail + exists in at least one of them, the provider issues a 250 success + code. + + If the server is unable to verify access to the requested domains + (for example, a mapping database is temporarily unavailable), + response code 451 is sent. + + [ABNF] for ATRN: + + atrn = "ATRN" [SP domain *("," domain)] + + domain = sub-domain 1*("." sub-domain) + + sub-domain = (ALPHA / DIGIT) *(ldh-str) + + ldh-str = *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) + +5.3. Reversed State + + After the provider has sent a success reply to the ATRN command, the + roles reverse, and the customer becomes the server, and the provider + becomes the client. + + After receiving the success response to ATRN, the customer sends a + standard SMTP initial greeting line. At this point normal SMTP + [SMTP, ESMTP] commands are used. Typically the provider sends EHLO + after seeing the customer's greeting, to be followed by MAIL FROM and + so on. + + + + + + + +Gellens Standards Track [Page 5] + +RFC 2645 On-Demand Mail Relay August 1999 + + +5.4. Other Commands + + The provider MAY reject all commands other than EHLO, AUTH, ATRN, and + QUIT with response code 502. + +6. Example On-Demand Mail Relay Session + + P: 220 EXAMPLE.NET on-demand mail relay server ready + C: EHLO example.org + P: 250-EXAMPLE.NET + P: 250-AUTH CRAM-MD5 EXTERNAL + P: 250 ATRN + C: AUTH CRAM-MD5 + P: 334 MTg5Ni42OTcxNzA5NTJASVNQLkNPTQo= + C: Zm9vYmFyLm5ldCBiOTEzYTYwMmM3ZWRhN2E0OTViNGU2ZTczMzRkMzg5MAo= + P: 235 now authenticated as example.org + C: ATRN example.org,example.com + P: 250 OK now reversing the connection + C: 220 example.org ready to receive email + P: EHLO EXAMPLE.NET + C: 250-example.org + C: 250 SIZE + P: MAIL FROM: + C: 250 OK + P: RCPT TO: + C: 250 OK, recipient accepted + ... + P: QUIT + C: 221 example.org closing connection + +7. Response Codes + + The response codes used in this document are: + + 250 Requested mail action okay, completed + 450 ATRN request refused + 451 Unable to process ATRN request now + 453 You have no mail + 502 Command not implemented + 530 Authentication required [AUTH] + +8. Security Considerations + + Because access to the On-Demand Mail Relay server is only useful with + a prior arrangement between the parties (so the provider is the + target of MX records for the customer's domains and thus has mail to + relay), it may be useful for the provider to restrict access to the + On-Demand Mail Relay port. For example, the ODMR server could be + + + +Gellens Standards Track [Page 6] + +RFC 2645 On-Demand Mail Relay August 1999 + + + configurable, or a TCP wrapper or firewall could be used, to block + access to port 366 except within the provider's network. This might + be useful when the provider is the customer's ISP. Use of such + mechanisms does not reduce the need for the AUTH command, however, + but can increase the security it provides. + + Use of SASL in the AUTH command allows for substitution of more + secure authentication mechanisms in the future. + + See sections 5.1.2 and 5.2.1 for additional security details. + +9. Acknowledgments + + This memo has been developed in part based on comments and + discussions which took place on and off the IETF-disconn-smtp mailing + list. Special thanks to Chris Newman and Ned Freed for their + comments. + +10. References + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [AUTH] Myers, J., "SMTP Service Extension for Authentication", + RFC 2554, March 1999. + + [CRAM] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP + AUTHorize Extension for Simple Challenge/Response", RFC + 2195, September 1997. + + [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. + Crocker, "SMTP Service Extensions", RFC 1869, November + 1995. + + [ETRN] De Winter, J., "SMTP Service Extension for Remote Message + Queue Starting", RFC 1985, August 1996. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [SASL] Myers, J., "Simple Authentication and Security Layer + (SASL)", RFC 2222, October 1997. + + [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC + 821, August 1982. + + + + + + +Gellens Standards Track [Page 7] + +RFC 2645 On-Demand Mail Relay August 1999 + + +11. Author's Address + + Randall Gellens + QUALCOMM Incorporated + 5775 Morehouse Dr. + San Diego, CA 92121-2779 + U.S.A. + + Phone: +1.619.651.5115 + EMail: randy@qualcomm.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gellens Standards Track [Page 8] + +RFC 2645 On-Demand Mail Relay August 1999 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Gellens Standards Track [Page 9] + diff --git a/RFC/rfc2683.txt b/RFC/rfc2683.txt new file mode 100644 index 00000000..651447b3 --- /dev/null +++ b/RFC/rfc2683.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group B. Leiba +Request for Comments: 2683 IBM T.J. Watson Research Center +Category: Informational September 1999 + + + IMAP4 Implementation Recommendations + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +1. Abstract + + The IMAP4 specification [RFC-2060] describes a rich protocol for use + in building clients and servers for storage, retrieval, and + manipulation of electronic mail. Because the protocol is so rich and + has so many implementation choices, there are often trade-offs that + must be made and issues that must be considered when designing such + clients and servers. This document attempts to outline these issues + and to make recommendations in order to make the end products as + interoperable as possible. + +2. Conventions used in this document + + In examples, "C:" indicates lines sent by a client that is connected + to a server. "S:" indicates lines sent by the server to the client. + + The words "must", "must not", "should", "should not", and "may" are + used with specific meaning in this document; since their meaning is + somewhat different from that specified in RFC 2119, we do not put + them in all caps here. Their meaning is as follows: + + must -- This word means that the action described is necessary + to ensure interoperability. The recommendation should + not be ignored. + must not -- This phrase means that the action described will be + almost certain to hurt interoperability. The + recommendation should not be ignored. + + + + + + + +Leiba Informational [Page 1] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + should -- This word means that the action described is strongly + recommended and will enhance interoperability or + usability. The recommendation should not be ignored + without careful consideration. + should not -- This phrase means that the action described is strongly + recommended against, and might hurt interoperability or + usability. The recommendation should not be ignored + without careful consideration. + may -- This word means that the action described is an + acceptable implementation choice. No specific + recommendation is implied; this word is used to point + out a choice that might not be obvious, or to let + implementors know what choices have been made by + existing implementations. + +3. Interoperability Issues and Recommendations + +3.1. Accessibility + + This section describes the issues related to access to servers and + server resources. Concerns here include data sharing and maintenance + of client/server connections. + +3.1.1. Multiple Accesses of the Same Mailbox + + One strong point of IMAP4 is that, unlike POP3, it allows for + multiple simultaneous access to a single mailbox. A user can, thus, + read mail from a client at home while the client in the office is + still connected; or the help desk staff can all work out of the same + inbox, all seeing the same pool of questions. An important point + about this capability, though is that NO SERVER IS GUARANTEED TO + SUPPORT THIS. If you are selecting an IMAP server and this facility + is important to you, be sure that the server you choose to install, + in the configuration you choose to use, supports it. + + If you are designing a client, you must not assume that you can + access the same mailbox more than once at a time. That means + + 1. you must handle gracefully the failure of a SELECT command if the + server refuses the second SELECT, + 2. you must handle reasonably the severing of your connection (see + "Severed Connections", below) if the server chooses to allow the + second SELECT by forcing the first off, + 3. you must avoid making multiple connections to the same mailbox in + your own client (for load balancing or other such reasons), and + 4. you must avoid using the STATUS command on a mailbox that you have + selected (with some server implementations the STATUS command has + the same problems with multiple access as do the SELECT and + + + +Leiba Informational [Page 2] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + EXAMINE commands). + + A further note about STATUS: The STATUS command is sometimes used to + check a non-selected mailbox for new mail. This mechanism must not + be used to check for new mail in the selected mailbox; section 5.2 of + [RFC-2060] specifically forbids this in its last paragraph. Further, + since STATUS takes a mailbox name it is an independent operation, not + operating on the selected mailbox. Because of this, the information + it returns is not necessarily in synchronization with the selected + mailbox state. + +3.1.2. Severed Connections + + The client/server connection may be severed for one of three reasons: + the client severs the connection, the server severs the connection, + or the connection is severed by outside forces beyond the control of + the client and the server (a telephone line drops, for example). + Clients and servers must both deal with these situations. + + When the client wants to sever a connection, it's usually because it + has finished the work it needed to do on that connection. The client + should send a LOGOUT command, wait for the tagged response, and then + close the socket. But note that, while this is what's intended in + the protocol design, there isn't universal agreement here. Some + contend that sending the LOGOUT and waiting for the two responses + (untagged BYE and tagged OK) is wasteful and unnecessary, and that + the client can simply close the socket. The server should interpret + the closed socket as a log out by the client. The counterargument is + that it's useful from the standpoint of cleanup, problem + determination, and the like, to have an explicit client log out, + because otherwise there is no way for the server to tell the + difference between "closed socket because of log out" and "closed + socket because communication was disrupted". If there is a + client/server interaction problem, a client which routinely + terminates a session by breaking the connection without a LOGOUT will + make it much more difficult to determine the problem. + + Because of this disagreement, server designers must be aware that + some clients might close the socket without sending a LOGOUT. In any + case, whether or not a LOGOUT was sent, the server should not + implicitly expunge any messages from the selected mailbox. If a + client wants the server to do so, it must send a CLOSE or EXPUNGE + command explicitly. + + When the server wants to sever a connection it's usually due to an + inactivity timeout or is because a situation has arisen that has + changed the state of the mail store in a way that the server can not + communicate to the client. The server should send an untagged BYE + + + +Leiba Informational [Page 3] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + response to the client and then close the socket. Sending an + untagged BYE response before severing allows the server to send a + human-readable explanation of the problem to the client, which the + client may then log, display to the user, or both (see section 7.1.5 + of [RFC-2060]). + + Regarding inactivity timeouts, there is some controversy. Unlike + POP, for which the design is for a client to connect, retrieve mail, + and log out, IMAP's design encourages long-lived (and mostly + inactive) client/server sessions. As the number of users grows, this + can use up a lot of server resources, especially with clients that + are designed to maintain sessions for mailboxes that the user has + finished accessing. To alleviate this, a server may implement an + inactivity timeout, unilaterally closing a session (after first + sending an untagged BYE, as noted above). Some server operators have + reported dramatic improvements in server performance after doing + this. As specified in [RFC-2060], if such a timeout is done it must + not be until at least 30 minutes of inactivity. The reason for this + specification is to prevent clients from sending commands (such as + NOOP) to the server at frequent intervals simply to avert a too-early + timeout. If the client knows that the server may not time out the + session for at least 30 minutes, then the client need not poll at + intervals more frequent than, say, 25 minutes. + +3.2. Scaling + + IMAP4 has many features that allow for scalability, as mail stores + become larger and more numerous. Large numbers of users, mailboxes, + and messages, and very large messages require thought to handle + efficiently. This document will not address the administrative + issues involved in large numbers of users, but we will look at the + other items. + +3.2.1. Flood Control + + There are three situations when a client can make a request that will + result in a very large response - too large for the client reasonably + to deal with: there are a great many mailboxes available, there are a + great many messages in the selected mailbox, or there is a very large + message part. The danger here is that the end user will be stuck + waiting while the server sends (and the client processes) an enormous + response. In all of these cases there are things a client can do to + reduce that danger. + + There is also the case where a client can flood a server, by sending + an arbitratily long command. We'll discuss that issue, too, in this + section. + + + + +Leiba Informational [Page 4] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + +3.2.1.1. Listing Mailboxes + + Some servers present Usenet newsgroups to IMAP users. Newsgroups, + and other such hierarchical mailbox structures, can be very numerous + but may have only a few entries at the top level of hierarchy. Also, + some servers are built against mail stores that can, unbeknownst to + the server, have circular hierarchies - that is, it's possible for + "a/b/c/d" to resolve to the same file structure as "a", which would + then mean that "a/b/c/d/b" is the same as "a/b", and the hierarchy + will never end. The LIST response in this case will be unlimited. + + Clients that will have trouble with this are those that use + + C: 001 LIST "" * + + to determine the mailbox list. Because of this, clients should not + use an unqualified "*" that way in the LIST command. A safer + approach is to list each level of hierarchy individually, allowing + the user to traverse the tree one limb at a time, thus: + + C: 001 LIST "" % + S: * LIST () "/" Banana + S: * LIST ...etc... + S: 001 OK done + + and then + + C: 002 LIST "" Banana/% + S: * LIST () "/" Banana/Apple + S: * LIST ...etc... + S: 002 OK done + + Using this technique the client's user interface can give the user + full flexibility without choking on the voluminous reply to "LIST *". + + Of course, it is still possible that the reply to + + C: 005 LIST "" alt.fan.celebrity.% + + may be thousands of entries long, and there is, unfortunately, + nothing the client can do to protect itself from that. This has not + yet been a notable problem. + + Servers that may export circular hierarchies (any server that + directly presents a UNIX file system, for instance) should limit the + hierarchy depth to prevent unlimited LIST responses. A suggested + depth limit is 20 hierarchy levels. + + + + +Leiba Informational [Page 5] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + +3.2.1.2. Fetching the List of Messages + + When a client selects a mailbox, it is given a count, in the untagged + EXISTS response, of the messages in the mailbox. This number can be + very large. In such a case it might be unwise to use + + C: 004 FETCH 1:* ALL + + to populate the user's view of the mailbox. One good method to avoid + problems with this is to batch the requests, thus: + + C: 004 FETCH 1:50 ALL + S: * 1 FETCH ...etc... + S: 004 OK done + C: 005 FETCH 51:100 ALL + S: * 51 FETCH ...etc... + S: 005 OK done + C: 006 FETCH 101:150 ALL + ...etc... + + Using this method, another command, such as "FETCH 6 BODY[1]" can be + inserted as necessary, and the client will not have its access to the + server blocked by a storm of FETCH replies. (Such a method could be + reversed to fetch the LAST 50 messages first, then the 50 prior to + that, and so on.) + + As a smart extension of this, a well designed client, prepared for + very large mailboxes, will not automatically fetch data for all + messages AT ALL. Rather, the client will populate the user's view + only as the user sees it, possibly pre-fetching selected information, + and only fetching other information as the user scrolls to it. For + example, to select only those messages beginning with the first + unseen one: + + C: 003 SELECT INBOX + S: * 10000 EXISTS + S: * 80 RECENT + S: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen) + S: * OK [UIDVALIDITY 824708485] UID validity status + S: * OK [UNSEEN 9921] First unseen message + S: 003 OK [READ-WRITE] SELECT completed + C: 004 FETCH 9921:* ALL + ... etc... + + If the server does not return an OK [UNSEEN] response, the client may + use SEARCH UNSEEN to obtain that value. + + + + + +Leiba Informational [Page 6] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + This mechanism is good as a default presentation method, but only + works well if the default message order is acceptable. A client may + want to present various sort orders to the user (by subject, by date + sent, by sender, and so on) and in that case (lacking a SORT + extension on the server side) the client WILL have to retrieve all + message descriptors. A client that provides this service should not + do it by default and should inform the user of the costs of choosing + this option for large mailboxes. + +3.2.1.3. Fetching a Large Body Part + + The issue here is similar to the one for a list of messages. In the + BODYSTRUCTURE response the client knows the size, in bytes, of the + body part it plans to fetch. Suppose this is a 70 MB video clip. The + client can use partial fetches to retrieve the body part in pieces, + avoiding the problem of an uninterruptible 70 MB literal coming back + from the server: + + C: 022 FETCH 3 BODY[1]<0.20000> + S: * 3 FETCH (FLAGS(\Seen) BODY[1]<0> {20000} + S: ...data...) + S: 022 OK done + C: 023 FETCH 3 BODY[1]<20001.20000> + S: * 3 FETCH (BODY[1]<20001> {20000} + S: ...data...) + S: 023 OK done + C: 024 FETCH 3 BODY[1]<40001.20000> + ...etc... + +3.2.1.4. BODYSTRUCTURE vs. Entire Messages + + Because FETCH BODYSTRUCTURE is necessary in order to determine the + number of body parts, and, thus, whether a message has "attachments", + clients often use FETCH FULL as their normal method of populating the + user's view of a mailbox. The benefit is that the client can display + a paperclip icon or some such indication along with the normal + message summary. However, this comes at a significant cost with some + server configurations. The parsing needed to generate the FETCH + BODYSTRUCTURE response may be time-consuming compared with that + needed for FETCH ENVELOPE. The client developer should consider this + issue when deciding whether the ability to add a paperclip icon is + worth the tradeoff in performance, especially with large mailboxes. + + Some clients, rather than using FETCH BODYSTRUCTURE, use FETCH BODY[] + (or the equivalent FETCH RFC822) to retrieve the entire message. + They then do the MIME parsing in the client. This may give the + client slightly more flexibility in some areas (access, for instance, + to header fields that aren't returned in the BODYSTRUCTURE and + + + +Leiba Informational [Page 7] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + ENVELOPE responses), but it can cause severe performance problems by + forcing the transfer of all body parts when the user might only want + to see some of them - a user logged on by modem and reading a small + text message with a large ZIP file attached may prefer to read the + text only and save the ZIP file for later. Therefore, a client + should not normally retrieve entire messages and should retrieve + message body parts selectively. + +3.2.1.5. Long Command Lines + + A client can wind up building a very long command line in an effort to + try to be efficient about requesting information from a server. This + can typically happen when a client builds a message set from selected + messages and doesn't recognise that contiguous blocks of messages may + be group in a range. Suppose a user selects all 10,000 messages in a + large mailbox and then unselects message 287. The client could build + that message set as "1:286,288:10000", but a client that doesn't + handle that might try to enumerate each message individually and build + "1,2,3,4, [and so on] ,9999,10000". Adding that to the fetch command + results in a command line that's almost 49,000 octets long, and, + clearly, one can construct a command line that's even longer. + + A client should limit the length of the command lines it generates to + approximately 1000 octets (including all quoted strings but not + including literals). If the client is unable to group things into + ranges so that the command line is within that length, it should + split the request into multiple commands. The client should use + literals instead of long quoted strings, in order to keep the command + length down. + + For its part, a server should allow for a command line of at least + 8000 octets. This provides plenty of leeway for accepting reasonable + length commands from clients. The server should send a BAD response + to a command that does not end within the server's maximum accepted + command length. + +3.2.2. Subscriptions + + The client isn't the only entity that can get flooded: the end user, + too, may need some flood control. The IMAP4 protocol provides such + control in the form of subscriptions. Most servers support the + SUBSCRIBE, UNSUBSCRIBE, and LSUB commands, and many users choose to + narrow down a large list of available mailboxes by subscribing to the + ones that they usually want to see. Clients, with this in mind, + should give the user a way to see only subscribed mailboxes. A + client that never uses the LSUB command takes a significant usability + feature away from the user. Of course, the client would not want to + hide the LIST command completely; the user needs to have a way to + + + +Leiba Informational [Page 8] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + choose between LIST and LSUB. The usual way to do this is to provide + a setting like "show which mailboxes?: [] all [] subscribed only". + +3.2.3. Searching + + IMAP SEARCH commands can become particularly troublesome (that is, + slow) on mailboxes containing a large number of messages. So let's + put a few things in perspective in that regard. + + The flag searches should be fast. The flag searches (ALL, [UN]SEEN, + [UN]ANSWERED, [UN]DELETED, [UN]DRAFT, [UN]FLAGGED, NEW, OLD, RECENT) + are known to be used by clients for the client's own use (for + instance, some clients use "SEARCH UNSEEN" to find unseen mail and + "SEARCH DELETED" to warn the user before expunging messages). + + Other searches, particularly the text searches (HEADER, TEXT, BODY) + are initiated by the user, rather than by the client itself, and + somewhat slower performance can be tolerated, since the user is aware + that the search is being done (and is probably aware that it might be + time-consuming). A smart server might use dynamic indexing to speed + commonly used text searches. + + The client may allow other commands to be sent to the server while a + SEARCH is in progress, but at the time of this writing there is + little or no server support for parallel processing of multiple + commands in the same session (and see "Multiple Accesses of the Same + Mailbox" above for a description of the dangers of trying to work + around this by doing your SEARCH in another session). + + Another word about text searches: some servers, built on database + back-ends with indexed search capabilities, may return search results + that do not match the IMAP spec's "case-insensitive substring" + requirements. While these servers are in violation of the protocol, + there is little harm in the violation as long as the search results + are used only in response to a user's request. Still, developers of + such servers should be aware that they ARE violating the protocol, + should think carefully about that behaviour, and must be certain that + their servers respond accurately to the flag searches for the reasons + outlined above. + + In addition, servers should support CHARSET UTF-8 [UTF-8] in + searches. + + + + + + + + + +Leiba Informational [Page 9] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + +3.3 Avoiding Invalid Requests + + IMAP4 provides ways for a server to tell a client in advance what is + and isn't permitted in some circumstances. Clients should use these + features to avoid sending requests that a well designed client would + know to be invalid. This section explains this in more detail. + +3.3.1. The CAPABILITY Command + + All IMAP4 clients should use the CAPABILITY command to determine what + version of IMAP and what optional features a server supports. The + client should not send IMAP4rev1 commands and arguments to a server + that does not advertize IMAP4rev1 in its CAPABILITY response. + Similarly, the client should not send IMAP4 commands that no longer + exist in IMAP4rev1 to a server that does not advertize IMAP4 in its + CAPABILITY response. An IMAP4rev1 server is NOT required to support + obsolete IMAP4 or IMAP2bis commands (though some do; do not let this + fact lull you into thinking that it's valid to send such commands to + an IMAP4rev1 server). + + A client should not send commands to probe for the existance of + certain extensions. All standard and standards-track extensions + include CAPABILITY tokens indicating their presense. All private and + experimental extensions should do the same, and clients that take + advantage of them should use the CAPABILITY response to determine + whether they may be used or not. + +3.3.2. Don't Do What the Server Says You Can't + + In many cases, the server, in response to a command, will tell the + client something about what can and can't be done with a particular + mailbox. The client should pay attention to this information and + should not try to do things that it's been told it can't do. + + Examples: + + * Do not try to SELECT a mailbox that has the \Noselect flag set. + * Do not try to CREATE a sub-mailbox in a mailbox that has the + \Noinferiors flag set. + * Do not respond to a failing COPY or APPEND command by trying to + CREATE the target mailbox if the server does not respond with a + [TRYCREATE] response code. + * Do not try to expunge a mailbox that has been selected with the + [READ-ONLY] response code. + + + + + + + +Leiba Informational [Page 10] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + +3.4. Miscellaneous Protocol Considerations + + We describe here a number of important protocol-related issues, the + misunderstanding of which has caused significant interoperability + problems in IMAP4 implementations. One general item is that every + implementer should be certain to take note of and to understand + section 2.2.2 and the preamble to section 7 of the IMAP4rev1 spec + [RFC-2060]. + +3.4.1. Well Formed Protocol + + We cannot stress enough the importance of adhering strictly to the + protocol grammar. The specification of the protocol is quite rigid; + do not assume that you can insert blank space for "readability" if + none is called for. Keep in mind that there are parsers out there + that will crash if there are protocol errors. There are clients that + will report every parser burp to the user. And in any case, + information that cannot be parsed is information that is lost. Be + careful in your protocol generation. And see "A Word About Testing", + below. + + In particular, note that the string in the INTERNALDATE response is + NOT an RFC-822 date string - that is, it is not in the same format as + the first string in the ENVELOPE response. Since most clients will, + in fact, accept an RFC-822 date string in the INTERNALDATE response, + it's easy to miss this in your interoperability testing. But it will + cause a problem with some client, so be sure to generate the correct + string for this field. + +3.4.2. Special Characters + + Certain characters, currently the double-quote and the backslash, may + not be sent as-is inside a quoted string. These characters must be + preceded by the escape character if they are in a quoted string, or + else the string must be sent as a literal. Both clients and servers + must handle this, both on output (they must send these characters + properly) and on input (they must be able to receive escaped + characters in quoted strings). Example: + + C: 001 LIST "" % + S: * LIST () "" INBOX + S: * LIST () "\\" TEST + S: * LIST () "\\" {12} + S: "My" mailbox + S: 001 OK done + C: 002 LIST "" "\"My\" mailbox\\%" + S: * LIST () "\\" {17} + S: "My" mailbox\Junk + + + +Leiba Informational [Page 11] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + S: 002 OK done + + Note that in the example the server sent the hierarchy delimiter as + an escaped character in the quoted string and sent the mailbox name + containing imbedded double-quotes as a literal. The client used only + quoted strings, escaping both the backslash and the double-quote + characters. + + The CR and LF characters may be sent ONLY in literals; they are not + allowed, even if escaped, inside quoted strings. + + And while we're talking about special characters: the IMAP spec, in + the section titled "Mailbox International Naming Convention", + describes how to encode mailbox names in modified UTF-7 [UTF-7 and + RFC-2060]. Implementations must adhere to this in order to be + interoperable in the international market, and servers should + validate mailbox names sent by client and reject names that do not + conform. + + As to special characters in userids and passwords: clients must not + restrict what a user may type in for a userid or a password. The + formal grammar specifies that these are "astrings", and an astring + can be a literal. A literal, in turn can contain any 8-bit + character, and clients must allow users to enter all 8-bit characters + here, and must pass them, unchanged, to the server (being careful to + send them as literals when necessary). In particular, some server + configurations use "@" in user names, and some clients do not allow + that character to be entered; this creates a severe interoperability + problem. + +3.4.3. UIDs and UIDVALIDITY + + Servers that support existing back-end mail stores often have no good + place to save UIDs for messages. Often the existing mail store will + not have the concept of UIDs in the sense that IMAP has: strictly + increasing, never re-issued, 32-bit integers. Some servers solve + this by storing the UIDs in a place that's accessible to end users, + allowing for the possibility that the users will delete them. Others + solve it by re-assigning UIDs every time a mailbox is selected. + + The server should maintain UIDs permanently for all messages if it + can. If that's not possible, the server must change the UIDVALIDITY + value for the mailbox whenever any of the UIDs may have become + invalid. Clients must recognize that the UIDVALIDITY has changed and + must respond to that condition by throwing away any information that + they have saved about UIDs in that mailbox. There have been many + problems in this area when clients have failed to do this; in the + worst case it will result in loss of mail when a client deletes the + + + +Leiba Informational [Page 12] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + wrong piece of mail by using a stale UID. + + It seems to be a common misunderstanding that "the UIDVALIDITY and + the UID, taken together, form a 64-bit identifier that uniquely + identifies a message on a server". This is absolutely NOT TRUE. + There is no assurance that the UIDVALIDITY values of two mailboxes be + different, so the UIDVALIDITY in no way identifies a mailbox. The + ONLY purpose of UIDVALIDITY is, as its name indicates, to give the + client a way to check the validity of the UIDs it has cached. While + it is a valid implementation choice to put these values together to + make a 64-bit identifier for the message, the important concept here + is that UIDs are not unique between mailboxes; they are only unique + WITHIN a given mailbox. + + Some server implementations have attempted to make UIDs unique across + the entire server. This is inadvisable, in that it limits the life + of UIDs unnecessarily. The UID is a 32-bit number and will run out + in reasonably finite time if it's global across the server. If you + assign UIDs sequentially in one mailbox, you will not have to start + re-using them until you have had, at one time or another, 2**32 + different messages in that mailbox. In the global case, you will + have to reuse them once you have had, at one time or another, 2**32 + different messages in the entire mail store. Suppose your server has + around 8000 users registered (2**13). That gives an average of 2**19 + UIDs per user. Suppose each user gets 32 messages (2**5) per day. + That gives you 2**14 days (16000+ days = about 45 years) before you + run out. That may seem like enough, but multiply the usage just a + little (a lot of spam, a lot of mailing list subscriptions, more + users) and you limit yourself too much. + + What's worse is that if you have to wrap the UIDs, and, thus, you + have to change UIDVALIDITY and invalidate the UIDs in the mailbox, + you have to do it for EVERY mailbox in the system, since they all + share the same UID pool. If you assign UIDs per mailbox and you have + a problem, you only have to kill the UIDs for that one mailbox. + + Under extreme circumstances (and this is extreme, indeed), the server + may have to invalidate UIDs while a mailbox is in use by a client - + that is, the UIDs that the client knows about in its active mailbox + are no longer valid. In that case, the server must immediately + change the UIDVALIDITY and must communicate this to the client. The + server may do this by sending an unsolicited UIDVALIDITY message, in + the same form as in response to the SELECT command. Clients must be + prepared to handle such a message and the possibly coincident failure + of the command in process. For example: + + + + + + +Leiba Informational [Page 13] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + C: 032 UID STORE 382 +Flags.silent \Deleted + S: * OK [UIDVALIDITY 12345] New UIDVALIDITY value! + S: 032 NO UID command rejected because UIDVALIDITY changed! + C: ...invalidates local information and re-fetches... + C: 033 FETCH 1:* UID + ...etc... + + At the time of the writing of this document, the only server known to + do this does so only under the following condition: the client + selects INBOX, but there is not yet a physical INBOX file created. + Nonetheless, the SELECT succeeds, exporting an empty INBOX with a + temporary UIDVALIDITY of 1. While the INBOX remains selected, mail + is delivered to the user, which creates the real INBOX file and + assigns a permanent UIDVALIDITY (that is likely not to be 1). The + server reports the change of UIDVALIDITY, but as there were no + messages before, so no UIDs have actually changed, all the client + must do is accept the change in UIDVALIDITY. + + Alternatively, a server may force the client to re-select the + mailbox, at which time it will obtain a new UIDVALIDITY value. To do + this, the server closes this client session (see "Severed + Connections" above) and the client then reconnects and gets back in + synch. Clients must be prepared for either of these behaviours. + + We do not know of, nor do we anticipate the future existance of, a + server that changes UIDVALIDITY while there are existing messages, + but clients must be prepared to handle this eventuality. + +3.4.4. FETCH Responses + + When a client asks for certain information in a FETCH command, the + server may return the requested information in any order, not + necessarily in the order that it was requested. Further, the server + may return the information in separate FETCH responses and may also + return information that was not explicitly requested (to reflect to + the client changes in the state of the subject message). Some + examples: + + C: 001 FETCH 1 UID FLAGS INTERNALDATE + S: * 5 FETCH (FLAGS (\Deleted)) + S: * 1 FETCH (FLAGS (\Seen) INTERNALDATE "..." UID 345) + S: 001 OK done + + (In this case, the responses are in a different order. Also, the + server returned a flag update for message 5, which wasn't part of the + client's request.) + + + + + +Leiba Informational [Page 14] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + C: 002 FETCH 2 UID FLAGS INTERNALDATE + S: * 2 FETCH (INTERNALDATE "...") + S: * 2 FETCH (UID 399) + S: * 2 FETCH (FLAGS ()) + S: 002 OK done + + (In this case, the responses are in a different order and were + returned in separate responses.) + + C: 003 FETCH 2 BODY[1] + S: * 2 FETCH (FLAGS (\Seen) BODY[1] {14} + S: Hello world! + S: ) + S: 003 OK done + + (In this case, the FLAGS response was added by the server, since + fetching the body part caused the server to set the \Seen flag.) + + Because of this characteristic a client must be ready to receive any + FETCH response at any time and should use that information to update + its local information about the message to which the FETCH response + refers. A client must not assume that any FETCH responses will come + in any particular order, or even that any will come at all. If after + receiving the tagged response for a FETCH command the client finds + that it did not get all of the information requested, the client + should send a NOOP command to the server to ensure that the server + has an opportunity to send any pending EXPUNGE responses to the + client (see [RFC-2180]). + +3.4.5. RFC822.SIZE + + Some back-end mail stores keep the mail in a canonical form, rather + than retaining the original MIME format of the messages. This means + that the server must reassemble the message to produce a MIME stream + when a client does a fetch such as RFC822 or BODY[], requesting the + entire message. It also may mean that the server has no convenient + way to know the RFC822.SIZE of the message. Often, such a server + will actually have to build the MIME stream to compute the size, only + to throw the stream away and report the size to the client. + + When this is the case, some servers have chosen to estimate the size, + rather than to compute it precisely. Such an estimate allows the + client to display an approximate size to the user and to use the + estimate in flood control considerations (q.v.), but requires that + the client not use the size for things such as allocation of buffers, + because those buffers might then be too small to hold the actual MIME + stream. Instead, a client should use the size that's returned in the + literal when you fetch the data. + + + +Leiba Informational [Page 15] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + The protocol requires that the RFC822.SIZE value returned by the + server be EXACT. Estimating the size is a protocol violation, and + server designers must be aware that, despite the performance savings + they might realize in using an estimate, this practice will cause + some clients to fail in various ways. If possible, the server should + compute the RFC822.SIZE for a particular message once, and then save + it for later retrieval. If that's not possible, the server must + compute the value exactly every time. Incorrect estimates do cause + severe interoperability problems with some clients. + +3.4.6. Expunged Messages + + If the server allows multiple connections to the same mailbox, it is + often possible for messages to be expunged in one client unbeknownst + to another client. Since the server is not allowed to tell the + client about these expunged messages in response to a FETCH command, + the server may have to deal with the issue of how to return + information about an expunged message. There was extensive + discussion about this issue, and the results of that discussion are + summarized in [RFC-2180]. See that reference for a detailed + explanation and for recommendations. + +3.4.7. The Namespace Issue + + Namespaces are a very muddy area in IMAP4 implementation right now + (see [NAMESPACE] for a proposal to clear the water a bit). Until the + issue is resolved, the important thing for client developers to + understand is that some servers provide access through IMAP to more + than just the user's personal mailboxes, and, in fact, the user's + personal mailboxes may be "hidden" somewhere in the user's default + hierarchy. The client, therefore, should provide a setting wherein + the user can specify a prefix to be used when accessing mailboxes. If + the user's mailboxes are all in "~/mail/", for instance, then the + user can put that string in the prefix. The client would then put + the prefix in front of any name pattern in the LIST and LSUB + commands: + + C: 001 LIST "" ~/mail/% + + (See also "Reference Names in the LIST Command" below.) + +3.4.8. Creating Special-Use Mailboxes + + It may seem at first that this is part of the namespace issue; it is + not, and is only indirectly related to it. A number of clients like + to create special-use mailboxes with particular names. Most + commonly, clients with a "trash folder" model of message deletion + want to create a mailbox with the name "Trash" or "Deleted". Some + + + +Leiba Informational [Page 16] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + clients want to create a "Drafts" mailbox, an "Outbox" mailbox, or a + "Sent Mail" mailbox. And so on. There are two major + interoperability problems with this practice: + + 1. different clients may use different names for mailboxes with + similar functions (such as "Trash" and "Deleted"), or may manage + the same mailboxes in different ways, causing problems if a user + switches between clients and + 2. there is no guarantee that the server will allow the creation of + the desired mailbox. + + The client developer is, therefore, well advised to consider + carefully the creation of any special-use mailboxes on the server, + and, further, the client must not require such mailbox creation - + that is, if you do decide to do this, you must handle gracefully the + failure of the CREATE command and behave reasonably when your + special-use mailboxes do not exist and can not be created. + + In addition, the client developer should provide a convenient way for + the user to select the names for any special-use mailboxes, allowing + the user to make these names the same in all clients used and to put + them where the user wants them. + +3.4.9. Reference Names in the LIST Command + + Many implementers of both clients and servers are confused by the + "reference name" on the LIST command. The reference name is intended + to be used in much the way a "cd" (change directory) command is used + on Unix, PC DOS, Windows, and OS/2 systems. That is, the mailbox + name is interpreted in much the same way as a file of that name would + be found if one had done a "cd" command into the directory specified + by the reference name. For example, in Unix we have the following: + + > cd /u/jones/junk + > vi banana [file is "/u/jones/junk/banana"] + > vi stuff/banana [file is "/u/jones/junk/stuff/banana"] + > vi /etc/hosts [file is "/etc/hosts"] + + In the past, there have been several interoperability problems with + this. First, while some IMAP servers are built on Unix or PC file + systems, many others are not, and the file system semantics do not + make sense in those configurations. Second, while some IMAP servers + expose the underlying file system to the clients, others allow access + only to the user's personal mailboxes, or to some other limited set + of files, making such file-system-like semantics less meaningful. + Third, because the IMAP spec leaves the interpretation of the + reference name as "implementation-dependent", in the past the various + server implementations handled it in vastly differing ways. + + + +Leiba Informational [Page 17] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + The following recommendations are the result of significant + operational experience, and are intended to maximize + interoperability. + + Server implementations must implement the reference argument in a way + that matches the intended "change directory" operation as closely as + possible. As a minimum implementation, the reference argument may be + prepended to the mailbox name (while suppressing double delimiters; + see the next paragraph). Even servers that do not provide a way to + break out of the current hierarchy (see "breakout facility" below) + must provide a reasonable implementation of the reference argument, + as described here, so that they will interoperate with clients that + use it. + + Server implementations that prepend the reference argument to the + mailbox name should insert a hierarchy delimiter between them, and + must not insert a second if one is already present: + + C: A001 LIST ABC DEF + S: * LIST () "/" ABC/DEF <=== should do this + S: A001 OK done + + C: A002 LIST ABC/ /DEF + S: * LIST () "/" ABC//DEF <=== must not do this + S: A002 OK done + + On clients, the reference argument is chiefly used to implement a + "breakout facility", wherein the user may directly access a mailbox + outside the "current directory" hierarchy. Client implementations + should have an operational mode that does not use the reference + argument. This is to interoperate with older servers that did not + implement the reference argument properly. While it's a good idea to + give the user access to a breakout facility, clients that do not + intend to do so should not use the reference argument at all. + + Client implementations should always place a trailing hierarchy + delimiter on the reference argument. This is because some servers + prepend the reference argument to the mailbox name without inserting + a hierarchy delimiter, while others do insert a hierarchy delimiter + if one is not already present. A client that puts the delimiter in + will work with both varieties of server. + + Client implementations that implement a breakout facility should + allow the user to choose whether or not to use a leading hierarchy + delimiter on the mailbox argument. This is because the handling of a + leading mailbox hierarchy delimiter also varies from server to + server, and even between different mailstores on the same server. In + some cases, a leading hierarchy delimiter means "discard the + + + +Leiba Informational [Page 18] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + reference argument" (implementing the intended breakout facility), + thus: + + C: A001 LIST ABC/ /DEF + S: * LIST () "/" /DEF + S: A001 OK done + + In other cases, however, the two are catenated and the extra + hierarchy delimiter is discarded, thus: + + C: A001 LIST ABC/ /DEF + S: * LIST () "/" ABC/DEF + S: A001 OK done + + Client implementations must not assume that the server supports a + breakout facility, but may provide a way for the user to use one if + it is available. Any breakout facility should be exported to the + user interface. Note that there may be other "breakout" characters + besides the hierarchy delimiter (for instance, UNIX filesystem + servers are likely to use a leading "~" as well), and that their + interpretation is server-dependent. + +3.4.10. Mailbox Hierarchy Delimiters + + The server's selection of what to use as a mailbox hierarchy + delimiter is a difficult one, involving several issues: What + characters do users expect to see? What characters can they enter + for a hierarchy delimiter if it is desired (or required) that the + user enter it? What character can be used for the hierarchy + delimiter, noting that the chosen character can not otherwise be used + in the mailbox name? + + Because some interfaces show users the hierarchy delimiters or allow + users to enter qualified mailbox names containing them, server + implementations should use delimiter characters that users generally + expect to see as name separators. The most common characters used + for this are "/" (as in Unix file names), "\" (as in OS/2 and Windows + file names), and "." (as in news groups). There is little to choose + among these apart from what users may expect or what is dictated by + the underlying file system, if any. One consideration about using + "\" is that it's also a special character in the IMAP protocol. While + the use of other hierarchy delimiter characters is permissible, A + DESIGNER IS WELL ADVISED TO STAY WITH ONE FROM THIS SET unless the + server is intended for special purposes only. Implementers might be + thinking about using characters such as "-", "_", ";", "&", "#", "@", + and "!", but they should be aware of the surprise to the user as well + as of the effect on URLs and other external specifications (since + some of these characters have special meanings there). Also, a + + + +Leiba Informational [Page 19] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + server that uses "\" (and clients of such a server) must remember to + escape that character in quoted strings or to send literals instead. + Literals are recommended over escaped characters in quoted strings in + order to maintain compatibility with older IMAP versions that did not + allow escaped characters in quoted strings (but check the grammar to + see where literals are allowed): + + C: 001 LIST "" {13} + S: + send literal + C: this\%\%\%\h* + S: * LIST () "\\" {27} + S: this\is\a\mailbox\hierarchy + S: 001 OK LIST complete + + In any case, a server should not use normal alpha-numeric characters + (such as "X" or "0") as delimiters; a user would be very surprised to + find that "EXPENDITURES" actually represented a two-level hierarchy. + And a server should not use characters that are non-printable or + difficult or impossible to enter on a standard US keyboard. Control + characters, box-drawing characters, and characters from non-US + alphabets fit into this category. Their use presents + interoperability problems that are best avoided. + + The UTF-7 encoding of mailbox names also raises questions about what + to do with the hierarchy delimiters in encoded names: do we encode + each hierarchy level and separate them with delimiters, or do we + encode the fully qualified name, delimiters and all? The answer for + IMAP is the former: encode each hierarchy level separately, and + insert delimiters between. This makes it particularly important not + to use as a hierarchy delimiter a character that might cause + confusion with IMAP's modified UTF-7 [UTF-7 and RFC-2060] encoding. + + To repeat: a server should use "/", "\", or "." as its hierarchy + delimiter. The use of any other character is likely to cause + problems and is STRONGLY DISCOURAGED. + +3.4.11. ALERT Response Codes + + The protocol spec is very clear on the matter of what to do with + ALERT response codes, and yet there are many clients that violate it + so it needs to be said anyway: "The human-readable text contains a + special alert that must be presented to the user in a fashion that + calls the user's attention to the message." That should be clear + enough, but I'll repeat it here: Clients must present ALERT text + clearly to the user. + + + + + + +Leiba Informational [Page 20] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + +3.4.12. Deleting Mailboxes + + The protocol does not guarantee that a client may delete a mailbox + that is not empty, though on some servers it is permissible and is, + in fact, much faster than the alternative or deleting all the + messages from the client. If the client chooses to try to take + advantage of this possibility it must be prepared to use the other + method in the even that the more convenient one fails. Further, a + client should not try to delete the mailbox that it has selected, but + should first close that mailbox; some servers do not permit the + deletion of the selected mailbox. + + That said, a server should permit the deletion of a non-empty + mailbox; there's little reason to pass this work on to the client. + Moreover, forbidding this prevents the deletion of a mailbox that for + some reason can not be opened or expunged, leading to possible + denial-of-service problems. + + Example: + + [User tells the client to delete mailbox BANANA, which is + currently selected...] + C: 008 CLOSE + S: 008 OK done + C: 009 DELETE BANANA + S: 009 NO Delete failed; mailbox is not empty. + C: 010 SELECT BANANA + S: * ... untagged SELECT responses + S: 010 OK done + C: 011 STORE 1:* +FLAGS.SILENT \DELETED + S: 011 OK done + C: 012 CLOSE + S: 012 OK done + C: 013 DELETE BANANA + S: 013 OK done + +3.5. A Word About Testing + + Since the whole point of IMAP is interoperability, and since + interoperability can not be tested in a vacuum, the final + recommendation of this treatise is, "Test against EVERYTHING." Test + your client against every server you can get an account on. Test + your server with every client you can get your hands on. Many + clients make limited test versions available on the Web for the + downloading. Many server owners will give serious client developers + guest accounts for testing. Contact them and ask. NEVER assume that + because your client works with one or two servers, or because your + server does fine with one or two clients, you will interoperate well + + + +Leiba Informational [Page 21] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + in general. + + In particular, in addition to everything else, be sure to test + against the reference implementations: the PINE client, the + University of Washington server, and the Cyrus server. + + See the following URLs on the web for more information here: + + IMAP Products and Sources: http://www.imap.org/products.html + IMC MailConnect: http://www.imc.org/imc-mailconnect + +4. Security Considerations + + This document describes behaviour of clients and servers that use the + IMAP4 protocol, and as such, has the same security considerations as + described in [RFC-2060]. + +5. References + + [RFC-2060] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, December 1996. + + [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC + 2180, July 1997. + + [UTF-8] Yergeau, F., " UTF-8, a transformation format of Unicode + and ISO 10646", RFC 2044, October 1996. + + [UTF-7] Goldsmith, D. and M. Davis, "UTF-7, a Mail-Safe + Transformation Format of Unicode", RFC 2152, May 1997. + + [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", Work in + Progress. + +6. Author's Address + + Barry Leiba + IBM T.J. Watson Research Center + 30 Saw Mill River Road + Hawthorne, NY 10532 + + Phone: 1-914-784-7941 + EMail: leiba@watson.ibm.com + + + + + +Leiba Informational [Page 22] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + +7. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Leiba Informational [Page 23] + diff --git a/RFC/rfc821.txt b/RFC/rfc821.txt new file mode 100644 index 00000000..d877b72c --- /dev/null +++ b/RFC/rfc821.txt @@ -0,0 +1,4050 @@ + + + + RFC 821 + + + + + + SIMPLE MAIL TRANSFER PROTOCOL + + + + Jonathan B. Postel + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 1982 + + + + Information Sciences Institute + University of Southern California + 4676 Admiralty Way + Marina del Rey, California 90291 + + (213) 822-1511 + + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + TABLE OF CONTENTS + + 1. INTRODUCTION .................................................. 1 + + 2. THE SMTP MODEL ................................................ 2 + + 3. THE SMTP PROCEDURE ............................................ 4 + + 3.1. Mail ..................................................... 4 + 3.2. Forwarding ............................................... 7 + 3.3. Verifying and Expanding .................................. 8 + 3.4. Sending and Mailing ..................................... 11 + 3.5. Opening and Closing ..................................... 13 + 3.6. Relaying ................................................ 14 + 3.7. Domains ................................................. 17 + 3.8. Changing Roles .......................................... 18 + + 4. THE SMTP SPECIFICATIONS ...................................... 19 + + 4.1. SMTP Commands ........................................... 19 + 4.1.1. Command Semantics ..................................... 19 + 4.1.2. Command Syntax ........................................ 27 + 4.2. SMTP Replies ............................................ 34 + 4.2.1. Reply Codes by Function Group ......................... 35 + 4.2.2. Reply Codes in Numeric Order .......................... 36 + 4.3. Sequencing of Commands and Replies ...................... 37 + 4.4. State Diagrams .......................................... 39 + 4.5. Details ................................................. 41 + 4.5.1. Minimum Implementation ................................ 41 + 4.5.2. Transparency .......................................... 41 + 4.5.3. Sizes ................................................. 42 + + APPENDIX A: TCP ................................................. 44 + APPENDIX B: NCP ................................................. 45 + APPENDIX C: NITS ................................................ 46 + APPENDIX D: X.25 ................................................ 47 + APPENDIX E: Theory of Reply Codes ............................... 48 + APPENDIX F: Scenarios ........................................... 51 + + GLOSSARY ......................................................... 64 + + REFERENCES ....................................................... 67 + + + + +Network Working Group J. Postel +Request for Comments: DRAFT ISI +Replaces: RFC 788, 780, 772 August 1982 + + SIMPLE MAIL TRANSFER PROTOCOL + + +1. INTRODUCTION + + The objective of Simple Mail Transfer Protocol (SMTP) is to transfer + mail reliably and efficiently. + + SMTP is independent of the particular transmission subsystem and + requires only a reliable ordered data stream channel. Appendices A, + B, C, and D describe the use of SMTP with various transport services. + A Glossary provides the definitions of terms as used in this + document. + + An important feature of SMTP is its capability to relay mail across + transport service environments. A transport service provides an + interprocess communication environment (IPCE). An IPCE may cover one + network, several networks, or a subset of a network. It is important + to realize that transport systems (or IPCEs) are not one-to-one with + networks. A process can communicate directly with another process + through any mutually known IPCE. Mail is an application or use of + interprocess communication. Mail can be communicated between + processes in different IPCEs by relaying through a process connected + to two (or more) IPCEs. More specifically, mail can be relayed + between hosts on different transport systems by a host on both + transport systems. + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 1] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +2. THE SMTP MODEL + + The SMTP design is based on the following model of communication: as + the result of a user mail request, the sender-SMTP establishes a + two-way transmission channel to a receiver-SMTP. The receiver-SMTP + may be either the ultimate destination or an intermediate. SMTP + commands are generated by the sender-SMTP and sent to the + receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the + sender-SMTP in response to the commands. + + Once the transmission channel is established, the SMTP-sender sends a + MAIL command indicating the sender of the mail. If the SMTP-receiver + can accept mail it responds with an OK reply. The SMTP-sender then + sends a RCPT command identifying a recipient of the mail. If the + SMTP-receiver can accept mail for that recipient it responds with an + OK reply; if not, it responds with a reply rejecting that recipient + (but not the whole mail transaction). The SMTP-sender and + SMTP-receiver may negotiate several recipients. When the recipients + have been negotiated the SMTP-sender sends the mail data, terminating + with a special sequence. If the SMTP-receiver successfully processes + the mail data it responds with an OK reply. The dialog is purposely + lock-step, one-at-a-time. + + ------------------------------------------------------------- + + + +----------+ +----------+ + +------+ | | | | + | User |<-->| | SMTP | | + +------+ | Sender- |Commands/Replies| Receiver-| + +------+ | SMTP |<-------------->| SMTP | +------+ + | File |<-->| | and Mail | |<-->| File | + |System| | | | | |System| + +------+ +----------+ +----------+ +------+ + + + Sender-SMTP Receiver-SMTP + + Model for SMTP Use + + Figure 1 + + ------------------------------------------------------------- + + The SMTP provides mechanisms for the transmission of mail; directly + from the sending user's host to the receiving user's host when the + + + +[Page 2] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + two host are connected to the same transport service, or via one or + more relay SMTP-servers when the source and destination hosts are not + connected to the same transport service. + + To be able to provide the relay capability the SMTP-server must be + supplied with the name of the ultimate destination host as well as + the destination mailbox name. + + The argument to the MAIL command is a reverse-path, which specifies + who the mail is from. The argument to the RCPT command is a + forward-path, which specifies who the mail is to. The forward-path + is a source route, while the reverse-path is a return route (which + may be used to return a message to the sender when an error occurs + with a relayed message). + + When the same message is sent to multiple recipients the SMTP + encourages the transmission of only one copy of the data for all the + recipients at the same destination host. + + The mail commands and replies have a rigid syntax. Replies also have + a numeric code. In the following, examples appear which use actual + commands and replies. The complete lists of commands and replies + appears in Section 4 on specifications. + + Commands and replies are not case sensitive. That is, a command or + reply word may be upper case, lower case, or any mixture of upper and + lower case. Note that this is not true of mailbox user names. For + some hosts the user name is case sensitive, and SMTP implementations + must take case to preserve the case of user names as they appear in + mailbox arguments. Host names are not case sensitive. + + Commands and replies are composed of characters from the ASCII + character set [1]. When the transport service provides an 8-bit byte + (octet) transmission channel, each 7-bit character is transmitted + right justified in an octet with the high order bit cleared to zero. + + When specifying the general form of a command or reply, an argument + (or special symbol) will be denoted by a meta-linguistic variable (or + constant), for example, "" or "". Here the + angle brackets indicate these are meta-linguistic variables. + However, some arguments use the angle brackets literally. For + example, an actual reverse-path is enclosed in angle brackets, i.e., + "" is an instance of (the + angle brackets are actually transmitted in the command or reply). + + + + + +Postel [Page 3] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +3. THE SMTP PROCEDURES + + This section presents the procedures used in SMTP in several parts. + First comes the basic mail procedure defined as a mail transaction. + Following this are descriptions of forwarding mail, verifying mailbox + names and expanding mailing lists, sending to terminals instead of or + in combination with mailboxes, and the opening and closing exchanges. + At the end of this section are comments on relaying, a note on mail + domains, and a discussion of changing roles. Throughout this section + are examples of partial command and reply sequences, several complete + scenarios are presented in Appendix F. + + 3.1. MAIL + + There are three steps to SMTP mail transactions. The transaction + is started with a MAIL command which gives the sender + identification. A series of one or more RCPT commands follows + giving the receiver information. Then a DATA command gives the + mail data. And finally, the end of mail data indicator confirms + the transaction. + + The first step in the procedure is the MAIL command. The + contains the source mailbox. + + MAIL FROM: + + This command tells the SMTP-receiver that a new mail + transaction is starting and to reset all its state tables and + buffers, including any recipients or mail data. It gives the + reverse-path which can be used to report errors. If accepted, + the receiver-SMTP returns a 250 OK reply. + + The can contain more than just a mailbox. The + is a reverse source routing list of hosts and + source mailbox. The first host in the should be + the host sending this command. + + The second step in the procedure is the RCPT command. + + RCPT TO: + + This command gives a forward-path identifying one recipient. + If accepted, the receiver-SMTP returns a 250 OK reply, and + stores the forward-path. If the recipient is unknown the + receiver-SMTP returns a 550 Failure reply. This second step of + the procedure can be repeated any number of times. + + + +[Page 4] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + The can contain more than just a mailbox. The + is a source routing list of hosts and the + destination mailbox. The first host in the + should be the host receiving this command. + + The third step in the procedure is the DATA command. + + DATA + + If accepted, the receiver-SMTP returns a 354 Intermediate reply + and considers all succeeding lines to be the message text. + When the end of text is received and stored the SMTP-receiver + sends a 250 OK reply. + + Since the mail data is sent on the transmission channel the end + of the mail data must be indicated so that the command and + reply dialog can be resumed. SMTP indicates the end of the + mail data by sending a line containing only a period. A + transparency procedure is used to prevent this from interfering + with the user's text (see Section 4.5.2). + + Please note that the mail data includes the memo header + items such as Date, Subject, To, Cc, From [2]. + + The end of mail data indicator also confirms the mail + transaction and tells the receiver-SMTP to now process the + stored recipients and mail data. If accepted, the + receiver-SMTP returns a 250 OK reply. The DATA command should + fail only if the mail transaction was incomplete (for example, + no recipients), or if resources are not available. + + The above procedure is an example of a mail transaction. These + commands must be used only in the order discussed above. + Example 1 (below) illustrates the use of these commands in a mail + transaction. + + + + + + + + + + + + + + +Postel [Page 5] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Example of the SMTP Procedure + + This SMTP example shows mail sent by Smith at host Alpha.ARPA, + to Jones, Green, and Brown at host Beta.ARPA. Here we assume + that host Alpha contacts host Beta directly. + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + R: 550 No such user here + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + The mail has now been accepted for Jones and Brown. Green did + not have a mailbox at host Beta. + + Example 1 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + +[Page 6] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 3.2. FORWARDING + + There are some cases where the destination information in the + is incorrect, but the receiver-SMTP knows the + correct destination. In such cases, one of the following replies + should be used to allow the sender to contact the correct + destination. + + 251 User not local; will forward to + + This reply indicates that the receiver-SMTP knows the user's + mailbox is on another host and indicates the correct + forward-path to use in the future. Note that either the + host or user or both may be different. The receiver takes + responsibility for delivering the message. + + 551 User not local; please try + + This reply indicates that the receiver-SMTP knows the user's + mailbox is on another host and indicates the correct + forward-path to use. Note that either the host or user or + both may be different. The receiver refuses to accept mail + for this user, and the sender must either redirect the mail + according to the information provided or return an error + response to the originating user. + + Example 2 illustrates the use of these responses. + + ------------------------------------------------------------- + + Example of Forwarding + + Either + + S: RCPT TO: + R: 251 User not local; will forward to + + Or + + S: RCPT TO: + R: 551 User not local; please try + + Example 2 + + ------------------------------------------------------------- + + + + +Postel [Page 7] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + 3.3. VERIFYING AND EXPANDING + + SMTP provides as additional features, commands to verify a user + name or expand a mailing list. This is done with the VRFY and + EXPN commands, which have character string arguments. For the + VRFY command, the string is a user name, and the response may + include the full name of the user and must include the mailbox of + the user. For the EXPN command, the string identifies a mailing + list, and the multiline response may include the full name of the + users and must give the mailboxes on the mailing list. + + "User name" is a fuzzy term and used purposely. If a host + implements the VRFY or EXPN commands then at least local mailboxes + must be recognized as "user names". If a host chooses to + recognize other strings as "user names" that is allowed. + + In some hosts the distinction between a mailing list and an alias + for a single mailbox is a bit fuzzy, since a common data structure + may hold both types of entries, and it is possible to have mailing + lists of one mailbox. If a request is made to verify a mailing + list a positive response can be given if on receipt of a message + so addressed it will be delivered to everyone on the list, + otherwise an error should be reported (e.g., "550 That is a + mailing list, not a user"). If a request is made to expand a user + name a positive response can be formed by returning a list + containing one name, or an error can be reported (e.g., "550 That + is a user name, not a mailing list"). + + In the case of a multiline reply (normal for EXPN) exactly one + mailbox is to be specified on each line of the reply. In the case + of an ambiguous request, for example, "VRFY Smith", where there + are two Smith's the response must be "553 User ambiguous". + + The case of verifying a user name is straightforward as shown in + example 3. + + + + + + + + + + + + + + +[Page 8] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Example of Verifying a User Name + + Either + + S: VRFY Smith + R: 250 Fred Smith + + Or + + S: VRFY Smith + R: 251 User not local; will forward to + + Or + + S: VRFY Jones + R: 550 String does not match anything. + + Or + + S: VRFY Jones + R: 551 User not local; please try + + Or + + S: VRFY Gourzenkyinplatz + R: 553 User ambiguous. + + Example 3 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + +Postel [Page 9] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + The case of expanding a mailbox list requires a multiline reply as + shown in example 4. + + ------------------------------------------------------------- + + Example of Expanding a Mailing List + + Either + + S: EXPN Example-People + R: 250-Jon Postel + R: 250-Fred Fonebone + R: 250-Sam Q. Smith + R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250- + R: 250 + + Or + + S: EXPN Executive-Washroom-List + R: 550 Access Denied to You. + + Example 4 + + ------------------------------------------------------------- + + The character string arguments of the VRFY and EXPN commands + cannot be further restricted due to the variety of implementations + of the user name and mailbox list concepts. On some systems it + may be appropriate for the argument of the EXPN command to be a + file name for a file containing a mailing list, but again there is + a variety of file naming conventions in the Internet. + + The VRFY and EXPN commands are not included in the minimum + implementation (Section 4.5.1), and are not required to work + across relays when they are implemented. + + + + + + + + + + + + + +[Page 10] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 3.4. SENDING AND MAILING + + The main purpose of SMTP is to deliver messages to user's + mailboxes. A very similar service provided by some hosts is to + deliver messages to user's terminals (provided the user is active + on the host). The delivery to the user's mailbox is called + "mailing", the delivery to the user's terminal is called + "sending". Because in many hosts the implementation of sending is + nearly identical to the implementation of mailing these two + functions are combined in SMTP. However the sending commands are + not included in the required minimum implementation + (Section 4.5.1). Users should have the ability to control the + writing of messages on their terminals. Most hosts permit the + users to accept or refuse such messages. + + The following three command are defined to support the sending + options. These are used in the mail transaction instead of the + MAIL command and inform the receiver-SMTP of the special semantics + of this transaction: + + SEND FROM: + + The SEND command requires that the mail data be delivered to + the user's terminal. If the user is not active (or not + accepting terminal messages) on the host a 450 reply may + returned to a RCPT command. The mail transaction is + successful if the message is delivered the terminal. + + SOML FROM: + + The Send Or MaiL command requires that the mail data be + delivered to the user's terminal if the user is active (and + accepting terminal messages) on the host. If the user is + not active (or not accepting terminal messages) then the + mail data is entered into the user's mailbox. The mail + transaction is successful if the message is delivered either + to the terminal or the mailbox. + + SAML FROM: + + The Send And MaiL command requires that the mail data be + delivered to the user's terminal if the user is active (and + accepting terminal messages) on the host. In any case the + mail data is entered into the user's mailbox. The mail + transaction is successful if the message is delivered the + mailbox. + + + +Postel [Page 11] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + The same reply codes that are used for the MAIL commands are used + for these commands. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 12] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 3.5. OPENING AND CLOSING + + At the time the transmission channel is opened there is an + exchange to ensure that the hosts are communicating with the hosts + they think they are. + + The following two commands are used in transmission channel + opening and closing: + + HELO + + QUIT + + In the HELO command the host sending the command identifies + itself; the command may be interpreted as saying "Hello, I am + ". + + ------------------------------------------------------------- + + Example of Connection Opening + + R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready + S: HELO USC-ISIF.ARPA + R: 250 BBN-UNIX.ARPA + + Example 5 + + ------------------------------------------------------------- + + ------------------------------------------------------------- + + Example of Connection Closing + + S: QUIT + R: 221 BBN-UNIX.ARPA Service closing transmission channel + + Example 6 + + ------------------------------------------------------------- + + + + + + + + + + +Postel [Page 13] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + 3.6. RELAYING + + The forward-path may be a source route of the form + "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE are hosts. This + form is used to emphasize the distinction between an address and a + route. The mailbox is an absolute address, and the route is + information about how to get there. The two concepts should not + be confused. + + Conceptually the elements of the forward-path are moved to the + reverse-path as the message is relayed from one server-SMTP to + another. The reverse-path is a reverse source route, (i.e., a + source route from the current location of the message to the + originator of the message). When a server-SMTP deletes its + identifier from the forward-path and inserts it into the + reverse-path, it must use the name it is known by in the + environment it is sending into, not the environment the mail came + from, in case the server-SMTP is known by different names in + different environments. + + If when the message arrives at an SMTP the first element of the + forward-path is not the identifier of that SMTP the element is not + deleted from the forward-path and is used to determine the next + SMTP to send the message to. In any case, the SMTP adds its own + identifier to the reverse-path. + + Using source routing the receiver-SMTP receives mail to be relayed + to another server-SMTP The receiver-SMTP may accept or reject the + task of relaying the mail in the same way it accepts or rejects + mail for a local user. The receiver-SMTP transforms the command + arguments by moving its own identifier from the forward-path to + the beginning of the reverse-path. The receiver-SMTP then becomes + a sender-SMTP, establishes a transmission channel to the next SMTP + in the forward-path, and sends it the mail. + + The first host in the reverse-path should be the host sending the + SMTP commands, and the first host in the forward-path should be + the host receiving the SMTP commands. + + Notice that the forward-path and reverse-path appear in the SMTP + commands and replies, but not necessarily in the message. That + is, there is no need for these paths and especially this syntax to + appear in the "To:" , "From:", "CC:", etc. fields of the message + header. + + If a server-SMTP has accepted the task of relaying the mail and + + + +[Page 14] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + later finds that the forward-path is incorrect or that the mail + cannot be delivered for whatever reason, then it must construct an + "undeliverable mail" notification message and send it to the + originator of the undeliverable mail (as indicated by the + reverse-path). + + This notification message must be from the server-SMTP at this + host. Of course, server-SMTPs should not send notification + messages about problems with notification messages. One way to + prevent loops in error reporting is to specify a null reverse-path + in the MAIL command of a notification message. When such a + message is relayed it is permissible to leave the reverse-path + null. A MAIL command with a null reverse-path appears as follows: + + MAIL FROM:<> + + An undeliverable mail notification message is shown in example 7. + This notification is in response to a message originated by JOE at + HOSTW and sent via HOSTX to HOSTY with instructions to relay it on + to HOSTZ. What we see in the example is the transaction between + HOSTY and HOSTX, which is the first step in the return of the + notification message. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 15] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Example Undeliverable Mail Notification Message + + S: MAIL FROM:<> + R: 250 ok + S: RCPT TO:<@HOSTX.ARPA:JOE@HOSTW.ARPA> + R: 250 ok + S: DATA + R: 354 send the mail data, end with . + S: Date: 23 Oct 81 11:22:33 + S: From: SMTP@HOSTY.ARPA + S: To: JOE@HOSTW.ARPA + S: Subject: Mail System Problem + S: + S: Sorry JOE, your message to SAM@HOSTZ.ARPA lost. + S: HOSTZ.ARPA said this: + S: "550 No Such User" + S: . + R: 250 ok + + Example 7 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 16] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 3.7. DOMAINS + + Domains are a recently introduced concept in the ARPA Internet + mail system. The use of domains changes the address space from a + flat global space of simple character string host names to a + hierarchically structured rooted tree of global addresses. The + host name is replaced by a domain and host designator which is a + sequence of domain element strings separated by periods with the + understanding that the domain elements are ordered from the most + specific to the most general. + + For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and + "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers. + + Whenever domain names are used in SMTP only the official names are + used, the use of nicknames or aliases is not allowed. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 17] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + 3.8. CHANGING ROLES + + The TURN command may be used to reverse the roles of the two + programs communicating over the transmission channel. + + If program-A is currently the sender-SMTP and it sends the TURN + command and receives an ok reply (250) then program-A becomes the + receiver-SMTP. + + If program-B is currently the receiver-SMTP and it receives the + TURN command and sends an ok reply (250) then program-B becomes + the sender-SMTP. + + To refuse to change roles the receiver sends the 502 reply. + + Please note that this command is optional. It would not normally + be used in situations where the transmission channel is TCP. + However, when the cost of establishing the transmission channel is + high, this command may be quite useful. For example, this command + may be useful in supporting be mail exchange using the public + switched telephone system as a transmission channel, especially if + some hosts poll other hosts for mail exchanges. + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 18] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +4. THE SMTP SPECIFICATIONS + + 4.1. SMTP COMMANDS + + 4.1.1. COMMAND SEMANTICS + + The SMTP commands define the mail transfer or the mail system + function requested by the user. SMTP commands are character + strings terminated by . The command codes themselves are + alphabetic characters terminated by if parameters follow + and otherwise. The syntax of mailboxes must conform to + receiver site conventions. The SMTP commands are discussed + below. The SMTP replies are discussed in the Section 4.2. + + A mail transaction involves several data objects which are + communicated as arguments to different commands. The + reverse-path is the argument of the MAIL command, the + forward-path is the argument of the RCPT command, and the mail + data is the argument of the DATA command. These arguments or + data objects must be transmitted and held pending the + confirmation communicated by the end of mail data indication + which finalizes the transaction. The model for this is that + distinct buffers are provided to hold the types of data + objects, that is, there is a reverse-path buffer, a + forward-path buffer, and a mail data buffer. Specific commands + cause information to be appended to a specific buffer, or cause + one or more buffers to be cleared. + + HELLO (HELO) + + This command is used to identify the sender-SMTP to the + receiver-SMTP. The argument field contains the host name of + the sender-SMTP. + + The receiver-SMTP identifies itself to the sender-SMTP in + the connection greeting reply, and in the response to this + command. + + This command and an OK reply to it confirm that both the + sender-SMTP and the receiver-SMTP are in the initial state, + that is, there is no transaction in progress and all state + tables and buffers are cleared. + + + + + + + +Postel [Page 19] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + MAIL (MAIL) + + This command is used to initiate a mail transaction in which + the mail data is delivered to one or more mailboxes. The + argument field contains a reverse-path. + + The reverse-path consists of an optional list of hosts and + the sender mailbox. When the list of hosts is present, it + is a "reverse" source route and indicates that the mail was + relayed through each host on the list (the first host in the + list was the most recent relay). This list is used as a + source route to return non-delivery notices to the sender. + As each relay host adds itself to the beginning of the list, + it must use its name as known in the IPCE to which it is + relaying the mail rather than the IPCE from which the mail + came (if they are different). In some types of error + reporting messages (for example, undeliverable mail + notifications) the reverse-path may be null (see Example 7). + + This command clears the reverse-path buffer, the + forward-path buffer, and the mail data buffer; and inserts + the reverse-path information from this command into the + reverse-path buffer. + + RECIPIENT (RCPT) + + This command is used to identify an individual recipient of + the mail data; multiple recipients are specified by multiple + use of this command. + + The forward-path consists of an optional list of hosts and a + required destination mailbox. When the list of hosts is + present, it is a source route and indicates that the mail + must be relayed to the next host on the list. If the + receiver-SMTP does not implement the relay function it may + user the same reply it would for an unknown local user + (550). + + When mail is relayed, the relay host must remove itself from + the beginning forward-path and put itself at the beginning + of the reverse-path. When mail reaches its ultimate + destination (the forward-path contains only a destination + mailbox), the receiver-SMTP inserts it into the destination + mailbox in accordance with its host mail conventions. + + + + + +[Page 20] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + For example, mail received at relay host A with arguments + + FROM: + TO:<@HOSTA.ARPA,@HOSTB.ARPA:USERC@HOSTD.ARPA> + + will be relayed on to host B with arguments + + FROM:<@HOSTA.ARPA:USERX@HOSTY.ARPA> + TO:<@HOSTB.ARPA:USERC@HOSTD.ARPA>. + + This command causes its forward-path argument to be appended + to the forward-path buffer. + + DATA (DATA) + + The receiver treats the lines following the command as mail + data from the sender. This command causes the mail data + from this command to be appended to the mail data buffer. + The mail data may contain any of the 128 ASCII character + codes. + + The mail data is terminated by a line containing only a + period, that is the character sequence "." (see + Section 4.5.2 on Transparency). This is the end of mail + data indication. + + The end of mail data indication requires that the receiver + must now process the stored mail transaction information. + This processing consumes the information in the reverse-path + buffer, the forward-path buffer, and the mail data buffer, + and on the completion of this command these buffers are + cleared. If the processing is successful the receiver must + send an OK reply. If the processing fails completely the + receiver must send a failure reply. + + When the receiver-SMTP accepts a message either for relaying + or for final delivery it inserts at the beginning of the + mail data a time stamp line. The time stamp line indicates + the identity of the host that sent the message, and the + identity of the host that received the message (and is + inserting this time stamp), and the date and time the + message was received. Relayed messages will have multiple + time stamp lines. + + When the receiver-SMTP makes the "final delivery" of a + message it inserts at the beginning of the mail data a + + + +Postel [Page 21] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + return path line. The return path line preserves the + information in the from the MAIL command. + Here, final delivery means the message leaves the SMTP + world. Normally, this would mean it has been delivered to + the destination user, but in some cases it may be further + processed and transmitted by another mail system. + + It is possible for the mailbox in the return path be + different from the actual sender's mailbox, for example, + if error responses are to be delivered a special error + handling mailbox rather than the message senders. + + The preceding two paragraphs imply that the final mail data + will begin with a return path line, followed by one or more + time stamp lines. These lines will be followed by the mail + data header and body [2]. See Example 8. + + Special mention is needed of the response and further action + required when the processing following the end of mail data + indication is partially successful. This could arise if + after accepting several recipients and the mail data, the + receiver-SMTP finds that the mail data can be successfully + delivered to some of the recipients, but it cannot be to + others (for example, due to mailbox space allocation + problems). In such a situation, the response to the DATA + command must be an OK reply. But, the receiver-SMTP must + compose and send an "undeliverable mail" notification + message to the originator of the message. Either a single + notification which lists all of the recipients that failed + to get the message, or separate notification messages must + be sent for each failed recipient (see Example 7). All + undeliverable mail notification messages are sent using the + MAIL command (even if they result from processing a SEND, + SOML, or SAML command). + + + + + + + + + + + + + + + +[Page 22] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Example of Return Path and Received Time Stamps + + Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA> + Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST + Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST + Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST + Date: 27 Oct 81 15:01:01 PST + From: JOE@ABC.ARPA + Subject: Improved Mailing System Installed + To: SAM@JKL.ARPA + + This is to inform you that ... + + Example 8 + + ------------------------------------------------------------- + + SEND (SEND) + + This command is used to initiate a mail transaction in which + the mail data is delivered to one or more terminals. The + argument field contains a reverse-path. This command is + successful if the message is delivered to a terminal. + + The reverse-path consists of an optional list of hosts and + the sender mailbox. When the list of hosts is present, it + is a "reverse" source route and indicates that the mail was + relayed through each host on the list (the first host in the + list was the most recent relay). This list is used as a + source route to return non-delivery notices to the sender. + As each relay host adds itself to the beginning of the list, + it must use its name as known in the IPCE to which it is + relaying the mail rather than the IPCE from which the mail + came (if they are different). + + This command clears the reverse-path buffer, the + forward-path buffer, and the mail data buffer; and inserts + the reverse-path information from this command into the + reverse-path buffer. + + SEND OR MAIL (SOML) + + This command is used to initiate a mail transaction in which + the mail data is delivered to one or more terminals or + + + +Postel [Page 23] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + mailboxes. For each recipient the mail data is delivered to + the recipient's terminal if the recipient is active on the + host (and accepting terminal messages), otherwise to the + recipient's mailbox. The argument field contains a + reverse-path. This command is successful if the message is + delivered to a terminal or the mailbox. + + The reverse-path consists of an optional list of hosts and + the sender mailbox. When the list of hosts is present, it + is a "reverse" source route and indicates that the mail was + relayed through each host on the list (the first host in the + list was the most recent relay). This list is used as a + source route to return non-delivery notices to the sender. + As each relay host adds itself to the beginning of the list, + it must use its name as known in the IPCE to which it is + relaying the mail rather than the IPCE from which the mail + came (if they are different). + + This command clears the reverse-path buffer, the + forward-path buffer, and the mail data buffer; and inserts + the reverse-path information from this command into the + reverse-path buffer. + + SEND AND MAIL (SAML) + + This command is used to initiate a mail transaction in which + the mail data is delivered to one or more terminals and + mailboxes. For each recipient the mail data is delivered to + the recipient's terminal if the recipient is active on the + host (and accepting terminal messages), and for all + recipients to the recipient's mailbox. The argument field + contains a reverse-path. This command is successful if the + message is delivered to the mailbox. + + The reverse-path consists of an optional list of hosts and + the sender mailbox. When the list of hosts is present, it + is a "reverse" source route and indicates that the mail was + relayed through each host on the list (the first host in the + list was the most recent relay). This list is used as a + source route to return non-delivery notices to the sender. + As each relay host adds itself to the beginning of the list, + it must use its name as known in the IPCE to which it is + relaying the mail rather than the IPCE from which the mail + came (if they are different). + + This command clears the reverse-path buffer, the + + + +[Page 24] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + forward-path buffer, and the mail data buffer; and inserts + the reverse-path information from this command into the + reverse-path buffer. + + RESET (RSET) + + This command specifies that the current mail transaction is + to be aborted. Any stored sender, recipients, and mail data + must be discarded, and all buffers and state tables cleared. + The receiver must send an OK reply. + + VERIFY (VRFY) + + This command asks the receiver to confirm that the argument + identifies a user. If it is a user name, the full name of + the user (if known) and the fully specified mailbox are + returned. + + This command has no effect on any of the reverse-path + buffer, the forward-path buffer, or the mail data buffer. + + EXPAND (EXPN) + + This command asks the receiver to confirm that the argument + identifies a mailing list, and if so, to return the + membership of that list. The full name of the users (if + known) and the fully specified mailboxes are returned in a + multiline reply. + + This command has no effect on any of the reverse-path + buffer, the forward-path buffer, or the mail data buffer. + + HELP (HELP) + + This command causes the receiver to send helpful information + to the sender of the HELP command. The command may take an + argument (e.g., any command name) and return more specific + information as a response. + + This command has no effect on any of the reverse-path + buffer, the forward-path buffer, or the mail data buffer. + + + + + + + + +Postel [Page 25] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + NOOP (NOOP) + + This command does not affect any parameters or previously + entered commands. It specifies no action other than that + the receiver send an OK reply. + + This command has no effect on any of the reverse-path + buffer, the forward-path buffer, or the mail data buffer. + + QUIT (QUIT) + + This command specifies that the receiver must send an OK + reply, and then close the transmission channel. + + The receiver should not close the transmission channel until + it receives and replies to a QUIT command (even if there was + an error). The sender should not close the transmission + channel until it send a QUIT command and receives the reply + (even if there was an error response to a previous command). + If the connection is closed prematurely the receiver should + act as if a RSET command had been received (canceling any + pending transaction, but not undoing any previously + completed transaction), the sender should act as if the + command or transaction in progress had received a temporary + error (4xx). + + TURN (TURN) + + This command specifies that the receiver must either (1) + send an OK reply and then take on the role of the + sender-SMTP, or (2) send a refusal reply and retain the role + of the receiver-SMTP. + + If program-A is currently the sender-SMTP and it sends the + TURN command and receives an OK reply (250) then program-A + becomes the receiver-SMTP. Program-A is then in the initial + state as if the transmission channel just opened, and it + then sends the 220 service ready greeting. + + If program-B is currently the receiver-SMTP and it receives + the TURN command and sends an OK reply (250) then program-B + becomes the sender-SMTP. Program-B is then in the initial + state as if the transmission channel just opened, and it + then expects to receive the 220 service ready greeting. + + To refuse to change roles the receiver sends the 502 reply. + + + +[Page 26] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + There are restrictions on the order in which these command may + be used. + + The first command in a session must be the HELO command. + The HELO command may be used later in a session as well. If + the HELO command argument is not acceptable a 501 failure + reply must be returned and the receiver-SMTP must stay in + the same state. + + The NOOP, HELP, EXPN, and VRFY commands can be used at any + time during a session. + + The MAIL, SEND, SOML, or SAML commands begin a mail + transaction. Once started a mail transaction consists of + one of the transaction beginning commands, one or more RCPT + commands, and a DATA command, in that order. A mail + transaction may be aborted by the RSET command. There may + be zero or more transactions in a session. + + If the transaction beginning command argument is not + acceptable a 501 failure reply must be returned and the + receiver-SMTP must stay in the same state. If the commands + in a transaction are out of order a 503 failure reply must + be returned and the receiver-SMTP must stay in the same + state. + + The last command in a session must be the QUIT command. The + QUIT command can not be used at any other time in a session. + + 4.1.2. COMMAND SYNTAX + + The commands consist of a command code followed by an argument + field. Command codes are four alphabetic characters. Upper + and lower case alphabetic characters are to be treated + identically. Thus, any of the following may represent the mail + command: + + MAIL Mail mail MaIl mAIl + + This also applies to any symbols representing parameter values, + such as "TO" or "to" for the forward-path. Command codes and + the argument fields are separated by one or more spaces. + However, within the reverse-path and forward-path arguments + case is important. In particular, in some hosts the user + "smith" is different from the user "Smith". + + + + +Postel [Page 27] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + The argument field consists of a variable length character + string ending with the character sequence . The receiver + is to take no action until this sequence is received. + + Square brackets denote an optional argument field. If the + option is not taken, the appropriate default is implied. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 28] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + The following are the SMTP commands: + + HELO + + MAIL FROM: + + RCPT TO: + + DATA + + RSET + + SEND FROM: + + SOML FROM: + + SAML FROM: + + VRFY + + EXPN + + HELP [ ] + + NOOP + + QUIT + + TURN + + + + + + + + + + + + + + + + + + + + +Postel [Page 29] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + The syntax of the above argument fields (using BNF notation + where applicable) is given below. The "..." notation indicates + that a field may be repeated one or more times. + + ::= + + ::= + + ::= "<" [ ":" ] ">" + + ::= | "," + + ::= "@" + + ::= | "." + + ::= | "#" | "[" "]" + + ::= "@" + + ::= | + + ::= + + ::= | + + ::= | + + ::= | | "-" + + ::= | "." + + ::= | + + ::= """ """ + + ::= "\" | "\" | | + + ::= | "\" + + ::= "." "." "." + + ::= | + + ::= + + + + +[Page 30] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + ::= the carriage return character (ASCII code 13) + + ::= the line feed character (ASCII code 10) + + ::= the space character (ASCII code 32) + + ::= one, two, or three digits representing a decimal + integer value in the range 0 through 255 + + ::= any one of the 52 alphabetic characters A through Z + in upper case and a through z in lower case + + ::= any one of the 128 ASCII characters, but not any + or + + ::= any one of the ten digits 0 through 9 + + ::= any one of the 128 ASCII characters except , + , quote ("), or backslash (\) + + ::= any one of the 128 ASCII characters (no exceptions) + + ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "." + | "," | ";" | ":" | "@" """ | the control + characters (ASCII codes 0 through 31 inclusive and + 127) + + Note that the backslash, "\", is a quote character, which is + used to indicate that the next character is to be used + literally (instead of its normal interpretation). For example, + "Joe\,Smith" could be used to indicate a single nine character + user field with comma being the fourth character of the field. + + Hosts are generally known by names which are translated to + addresses in each host. Note that the name elements of domains + are the official names -- no use of nicknames or aliases is + allowed. + + Sometimes a host is not known to the translation function and + communication is blocked. To bypass this barrier two numeric + forms are also allowed for host "names". One form is a decimal + integer prefixed by a pound sign, "#", which indicates the + number is the address of the host. Another form is four small + decimal integers separated by dots and enclosed by brackets, + e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet + Address in four 8-bit fields. + + + +Postel [Page 31] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + The time stamp line and the return path line are formally + defined as follows: + + ::= "Return-Path:" + + ::= "Received:" + + ::= ";" + + + ::= "FROM" + + ::= "BY" + + ::= [] [] [] [] + + ::= "VIA" + + ::= "WITH" + + ::= "ID" + + ::= "FOR" + + ::= The standard names for links are registered with + the Network Information Center. + + ::= The standard names for protocols are + registered with the Network Information Center. + + ::=
::= the one or two decimal integer day of the month in + the range 1 to 31. + + ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | + "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" + + ::= the two decimal integer year of the century in the + range 00 to 99. + + + + + +[Page 32] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + ::= the two decimal integer hour of the day in the + range 00 to 24. + + ::= the two decimal integer minute of the hour in the + range 00 to 59. + + ::= the two decimal integer second of the minute in the + range 00 to 59. + + ::= "UT" for Universal Time (the default) or other + time zone designator (as in [2]). + + + + ------------------------------------------------------------- + + Return Path Example + + Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:JOE@ABLE.ARPA> + + Example 9 + + ------------------------------------------------------------- + + ------------------------------------------------------------- + + Time Stamp Line Example + + Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT + + Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25 + id M12345 for Smith@PDQ.ARPA ; 22 OCT 81 09:23:59 PDT + + Example 10 + + ------------------------------------------------------------- + + + + + + + + + + + + + +Postel [Page 33] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + 4.2. SMTP REPLIES + + Replies to SMTP commands are devised to ensure the synchronization + of requests and actions in the process of mail transfer, and to + guarantee that the sender-SMTP always knows the state of the + receiver-SMTP. Every command must generate exactly one reply. + + The details of the command-reply sequence are made explicit in + Section 5.3 on Sequencing and Section 5.4 State Diagrams. + + An SMTP reply consists of a three digit number (transmitted as + three alphanumeric characters) followed by some text. The number + is intended for use by automata to determine what state to enter + next; the text is meant for the human user. It is intended that + the three digits contain enough encoded information that the + sender-SMTP need not examine the text and may either discard it or + pass it on to the user, as appropriate. In particular, the text + may be receiver-dependent and context dependent, so there are + likely to be varying texts for each reply code. A discussion of + the theory of reply codes is given in Appendix E. Formally, a + reply is defined to be the sequence: a three-digit code, , + one line of text, and , or a multiline reply (as defined in + Appendix E). Only the EXPN and HELP commands are expected to + result in multiline replies in normal circumstances, however + multiline replies are allowed for any command. + + + + + + + + + + + + + + + + + + + + + + + + +[Page 34] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.2.1. REPLY CODES BY FUNCTION GROUPS + + 500 Syntax error, command unrecognized + [This may include errors such as command line too long] + 501 Syntax error in parameters or arguments + 502 Command not implemented + 503 Bad sequence of commands + 504 Command parameter not implemented + + 211 System status, or system help reply + 214 Help message + [Information on how to use the receiver or the meaning of a + particular non-standard command; this reply is useful only + to the human user] + + 220 Service ready + 221 Service closing transmission channel + 421 Service not available, + closing transmission channel + [This may be a reply to any command if the service knows it + must shut down] + + 250 Requested mail action okay, completed + 251 User not local; will forward to + 450 Requested mail action not taken: mailbox unavailable + [E.g., mailbox busy] + 550 Requested action not taken: mailbox unavailable + [E.g., mailbox not found, no access] + 451 Requested action aborted: error in processing + 551 User not local; please try + 452 Requested action not taken: insufficient system storage + 552 Requested mail action aborted: exceeded storage allocation + 553 Requested action not taken: mailbox name not allowed + [E.g., mailbox syntax incorrect] + 354 Start mail input; end with . + 554 Transaction failed + + + + + + + + + + + + + +Postel [Page 35] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + 4.2.2. NUMERIC ORDER LIST OF REPLY CODES + + 211 System status, or system help reply + 214 Help message + [Information on how to use the receiver or the meaning of a + particular non-standard command; this reply is useful only + to the human user] + 220 Service ready + 221 Service closing transmission channel + 250 Requested mail action okay, completed + 251 User not local; will forward to + + 354 Start mail input; end with . + + 421 Service not available, + closing transmission channel + [This may be a reply to any command if the service knows it + must shut down] + 450 Requested mail action not taken: mailbox unavailable + [E.g., mailbox busy] + 451 Requested action aborted: local error in processing + 452 Requested action not taken: insufficient system storage + + 500 Syntax error, command unrecognized + [This may include errors such as command line too long] + 501 Syntax error in parameters or arguments + 502 Command not implemented + 503 Bad sequence of commands + 504 Command parameter not implemented + 550 Requested action not taken: mailbox unavailable + [E.g., mailbox not found, no access] + 551 User not local; please try + 552 Requested mail action aborted: exceeded storage allocation + 553 Requested action not taken: mailbox name not allowed + [E.g., mailbox syntax incorrect] + 554 Transaction failed + + + + + + + + + + + + + +[Page 36] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.3. SEQUENCING OF COMMANDS AND REPLIES + + The communication between the sender and receiver is intended to + be an alternating dialogue, controlled by the sender. As such, + the sender issues a command and the receiver responds with a + reply. The sender must wait for this response before sending + further commands. + + One important reply is the connection greeting. Normally, a + receiver will send a 220 "Service ready" reply when the connection + is completed. The sender should wait for this greeting message + before sending any commands. + + Note: all the greeting type replies have the official name of + the server host as the first word following the reply code. + + For example, + + 220 USC-ISIF.ARPA Service ready + + The table below lists alternative success and failure replies for + each command. These must be strictly adhered to; a receiver may + substitute text in the replies, but the meaning and action implied + by the code numbers and by the specific command reply sequence + cannot be altered. + + COMMAND-REPLY SEQUENCES + + Each command is listed with its possible replies. The prefixes + used before the possible replies are "P" for preliminary (not + used in SMTP), "I" for intermediate, "S" for success, "F" for + failure, and "E" for error. The 421 reply (service not + available, closing transmission channel) may be given to any + command if the SMTP-receiver knows it must shut down. This + listing forms the basis for the State Diagrams in Section 4.4. + + CONNECTION ESTABLISHMENT + S: 220 + F: 421 + HELO + S: 250 + E: 500, 501, 504, 421 + MAIL + S: 250 + F: 552, 451, 452 + E: 500, 501, 421 + + + +Postel [Page 37] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + RCPT + S: 250, 251 + F: 550, 551, 552, 553, 450, 451, 452 + E: 500, 501, 503, 421 + DATA + I: 354 -> data -> S: 250 + F: 552, 554, 451, 452 + F: 451, 554 + E: 500, 501, 503, 421 + RSET + S: 250 + E: 500, 501, 504, 421 + SEND + S: 250 + F: 552, 451, 452 + E: 500, 501, 502, 421 + SOML + S: 250 + F: 552, 451, 452 + E: 500, 501, 502, 421 + SAML + S: 250 + F: 552, 451, 452 + E: 500, 501, 502, 421 + VRFY + S: 250, 251 + F: 550, 551, 553 + E: 500, 501, 502, 504, 421 + EXPN + S: 250 + F: 550 + E: 500, 501, 502, 504, 421 + HELP + S: 211, 214 + E: 500, 501, 502, 504, 421 + NOOP + S: 250 + E: 500, 421 + QUIT + S: 221 + E: 500 + TURN + S: 250 + F: 502 + E: 500, 503 + + + + +[Page 38] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.4. STATE DIAGRAMS + + Following are state diagrams for a simple-minded SMTP + implementation. Only the first digit of the reply codes is used. + There is one state diagram for each group of SMTP commands. The + command groupings were determined by constructing a model for each + command and then collecting together the commands with + structurally identical models. + + For each command there are three possible outcomes: "success" + (S), "failure" (F), and "error" (E). In the state diagrams below + we use the symbol B for "begin", and the symbol W for "wait for + reply". + + First, the diagram that represents most of the SMTP commands: + + + 1,3 +---+ + ----------->| E | + | +---+ + | + +---+ cmd +---+ 2 +---+ + | B |---------->| W |---------->| S | + +---+ +---+ +---+ + | + | 4,5 +---+ + ----------->| F | + +---+ + + + This diagram models the commands: + + HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP, + NOOP, QUIT, TURN. + + + + + + + + + + + + + + + +Postel [Page 39] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + A more complex diagram models the DATA command: + + + +---+ DATA +---+ 1,2 +---+ + | B |---------->| W |-------------------->| E | + +---+ +---+ ------------>+---+ + 3| |4,5 | + | | | + -------------- ----- | + | | | +---+ + | ---------- -------->| S | + | | | | +---+ + | | ------------ + | | | | + V 1,3| |2 | + +---+ data +---+ --------------->+---+ + | |---------->| W | | F | + +---+ +---+-------------------->+---+ + 4,5 + + + Note that the "data" here is a series of lines sent from the + sender to the receiver with no response expected until the last + line is sent. + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 40] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.5. DETAILS + + 4.5.1. MINIMUM IMPLEMENTATION + + In order to make SMTP workable, the following minimum + implementation is required for all receivers: + + COMMANDS -- HELO + MAIL + RCPT + DATA + RSET + NOOP + QUIT + + 4.5.2. TRANSPARENCY + + Without some provision for data transparency the character + sequence "." ends the mail text and cannot be sent + by the user. In general, users are not aware of such + "forbidden" sequences. To allow all user composed text to be + transmitted transparently the following procedures are used. + + 1. Before sending a line of mail text the sender-SMTP checks + the first character of the line. If it is a period, one + additional period is inserted at the beginning of the line. + + 2. When a line of mail text is received by the receiver-SMTP + it checks the line. If the line is composed of a single + period it is the end of mail. If the first character is a + period and there are other characters on the line, the first + character is deleted. + + The mail data may contain any of the 128 ASCII characters. All + characters are to be delivered to the recipient's mailbox + including format effectors and other control characters. If + the transmission channel provides an 8-bit byte (octets) data + stream, the 7-bit ASCII codes are transmitted right justified + in the octets with the high order bits cleared to zero. + + In some systems it may be necessary to transform the data as + it is received and stored. This may be necessary for hosts + that use a different character set than ASCII as their local + character set, or that store data in records rather than + + + + + +Postel [Page 41] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + strings. If such transforms are necessary, they must be + reversible -- especially if such transforms are applied to + mail being relayed. + + 4.5.3. SIZES + + There are several objects that have required minimum maximum + sizes. That is, every implementation must be able to receive + objects of at least these sizes, but must not send objects + larger than these sizes. + + + **************************************************** + * * + * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * + * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * + * OF THESE OBJECTS SHOULD BE USED. * + * * + **************************************************** + + user + + The maximum total length of a user name is 64 characters. + + domain + + The maximum total length of a domain name or number is 64 + characters. + + path + + The maximum total length of a reverse-path or + forward-path is 256 characters (including the punctuation + and element separators). + + command line + + The maximum total length of a command line including the + command word and the is 512 characters. + + reply line + + The maximum total length of a reply line including the + reply code and the is 512 characters. + + + + + +[Page 42] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + text line + + The maximum total length of a text line including the + is 1000 characters (but not counting the leading + dot duplicated for transparency). + + recipients buffer + + The maximum total number of recipients that must be + buffered is 100 recipients. + + + **************************************************** + * * + * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * + * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * + * OF THESE OBJECTS SHOULD BE USED. * + * * + **************************************************** + + Errors due to exceeding these limits may be reported by using + the reply codes, for example: + + 500 Line too long. + + 501 Path too long + + 552 Too many recipients. + + 552 Too much mail data. + + + + + + + + + + + + + + + + + + + +Postel [Page 43] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +APPENDIX A + + TCP Transport service + + The Transmission Control Protocol [3] is used in the ARPA + Internet, and in any network following the US DoD standards for + internetwork protocols. + + Connection Establishment + + The SMTP transmission channel is a TCP connection established + between the sender process port U and the receiver process port + L. This single full duplex connection is used as the + transmission channel. This protocol is assigned the service + port 25 (31 octal), that is L=25. + + Data Transfer + + The TCP connection supports the transmission of 8-bit bytes. + The SMTP data is 7-bit ASCII characters. Each character is + transmitted as an 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 44] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +APPENDIX B + + NCP Transport service + + The ARPANET Host-to-Host Protocol [4] (implemented by the Network + Control Program) may be used in the ARPANET. + + Connection Establishment + + The SMTP transmission channel is established via NCP between + the sender process socket U and receiver process socket L. The + Initial Connection Protocol [5] is followed resulting in a pair + of simplex connections. This pair of connections is used as + the transmission channel. This protocol is assigned the + contact socket 25 (31 octal), that is L=25. + + Data Transfer + + The NCP data connections are established in 8-bit byte mode. + The SMTP data is 7-bit ASCII characters. Each character is + transmitted as an 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 45] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +APPENDIX C + + NITS + + The Network Independent Transport Service [6] may be used. + + Connection Establishment + + The SMTP transmission channel is established via NITS between + the sender process and receiver process. The sender process + executes the CONNECT primitive, and the waiting receiver + process executes the ACCEPT primitive. + + Data Transfer + + The NITS connection supports the transmission of 8-bit bytes. + The SMTP data is 7-bit ASCII characters. Each character is + transmitted as an 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 46] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +APPENDIX D + + X.25 Transport service + + It may be possible to use the X.25 service [7] as provided by the + Public Data Networks directly, however, it is suggested that a + reliable end-to-end protocol such as TCP be used on top of X.25 + connections. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 47] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +APPENDIX E + + Theory of Reply Codes + + The three digits of the reply each have a special significance. + The first digit denotes whether the response is good, bad or + incomplete. An unsophisticated sender-SMTP will be able to + determine its next action (proceed as planned, redo, retrench, + etc.) by simply examining this first digit. A sender-SMTP that + wants to know approximately what kind of error occurred (e.g., + mail system error, command syntax error) may examine the second + digit, reserving the third digit for the finest gradation of + information. + + There are five values for the first digit of the reply code: + + 1yz Positive Preliminary reply + + The command has been accepted, but the requested action + is being held in abeyance, pending confirmation of the + information in this reply. The sender-SMTP should send + another command specifying whether to continue or abort + the action. + + [Note: SMTP does not have any commands that allow this + type of reply, and so does not have the continue or + abort commands.] + + 2yz Positive Completion reply + + The requested action has been successfully completed. A + new request may be initiated. + + 3yz Positive Intermediate reply + + The command has been accepted, but the requested action + is being held in abeyance, pending receipt of further + information. The sender-SMTP should send another command + specifying this information. This reply is used in + command sequence groups. + + 4yz Transient Negative Completion reply + + The command was not accepted and the requested action did + not occur. However, the error condition is temporary and + the action may be requested again. The sender should + + + +[Page 48] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + return to the beginning of the command sequence (if any). + It is difficult to assign a meaning to "transient" when + two different sites (receiver- and sender- SMTPs) must + agree on the interpretation. Each reply in this category + might have a different time value, but the sender-SMTP is + encouraged to try again. A rule of thumb to determine if + a reply fits into the 4yz or the 5yz category (see below) + is that replies are 4yz if they can be repeated without + any change in command form or in properties of the sender + or receiver. (E.g., the command is repeated identically + and the receiver does not put up a new implementation.) + + 5yz Permanent Negative Completion reply + + The command was not accepted and the requested action did + not occur. The sender-SMTP is discouraged from repeating + the exact request (in the same sequence). Even some + "permanent" error conditions can be corrected, so the + human user may want to direct the sender-SMTP to + reinitiate the command sequence by direct action at some + point in the future (e.g., after the spelling has been + changed, or the user has altered the account status). + + The second digit encodes responses in specific categories: + + x0z Syntax -- These replies refer to syntax errors, + syntactically correct commands that don't fit any + functional category, and unimplemented or superfluous + commands. + + x1z Information -- These are replies to requests for + information, such as status or help. + + x2z Connections -- These are replies referring to the + transmission channel. + + x3z Unspecified as yet. + + x4z Unspecified as yet. + + x5z Mail system -- These replies indicate the status of + the receiver mail system vis-a-vis the requested + transfer or other mail system action. + + The third digit gives a finer gradation of meaning in each + category specified by the second digit. The list of replies + + + +Postel [Page 49] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + illustrates this. Each reply text is recommended rather than + mandatory, and may even change according to the command with + which it is associated. On the other hand, the reply codes + must strictly follow the specifications in this section. + Receiver implementations should not invent new codes for + slightly different situations from the ones described here, but + rather adapt codes already defined. + + For example, a command such as NOOP whose successful execution + does not offer the sender-SMTP any new information will return + a 250 reply. The response is 502 when the command requests an + unimplemented non-site-specific action. A refinement of that + is the 504 reply for a command that is implemented, but that + requests an unimplemented parameter. + + The reply text may be longer than a single line; in these cases + the complete text must be marked so the sender-SMTP knows when it + can stop reading the reply. This requires a special format to + indicate a multiple line reply. + + The format for multiline replies requires that every line, + except the last, begin with the reply code, followed + immediately by a hyphen, "-" (also known as minus), followed by + text. The last line will begin with the reply code, followed + immediately by , optionally some text, and . + + For example: + 123-First line + 123-Second line + 123-234 text beginning with numbers + 123 The last line + + In many cases the sender-SMTP then simply needs to search for + the reply code followed by at the beginning of a line, and + ignore all preceding lines. In a few cases, there is important + data for the sender in the reply "text". The sender will know + these cases from the current context. + + + + + + + + + + + + +[Page 50] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +APPENDIX F + + Scenarios + + This section presents complete scenarios of several types of SMTP + sessions. + + A Typical SMTP Transaction Scenario + + This SMTP example shows mail sent by Smith at host USC-ISIF, to + Jones, Green, and Brown at host BBN-UNIX. Here we assume that + host USC-ISIF contacts host BBN-UNIX directly. The mail is + accepted for Jones and Brown. Green does not have a mailbox at + host BBN-UNIX. + + ------------------------------------------------------------- + + R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready + S: HELO USC-ISIF.ARPA + R: 250 BBN-UNIX.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + R: 550 No such user here + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 BBN-UNIX.ARPA Service closing transmission channel + + Scenario 1 + + ------------------------------------------------------------- + + + +Postel [Page 51] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Aborted SMTP Transaction Scenario + + ------------------------------------------------------------- + + R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready + S: HELO ISI-VAXA.ARPA + R: 250 MIT-Multics.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + R: 550 No such user here + + S: RSET + R: 250 OK + + S: QUIT + R: 221 MIT-Multics.ARPA Service closing transmission channel + + Scenario 2 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + + + + + +[Page 52] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Relayed Mail Scenario + + ------------------------------------------------------------- + + Step 1 -- Source Host to Relay Host + + R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-AI.ARPA + R: 250 USC-ISIE.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Date: 2 Nov 81 22:33:44 + S: From: John Q. Public + S: Subject: The Next Meeting of the Board + S: To: Jones@BBN-Vax.ARPA + S: + S: Bill: + S: The next meeting of the board of directors will be + S: on Tuesday. + S: John. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIE.ARPA Service closing transmission channel + + + + + + + + + + + + + + + + + +Postel [Page 53] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Step 2 -- Relay Host to Destination Host + + R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready + S: HELO USC-ISIE.ARPA + R: 250 BBN-VAX.ARPA + + S: MAIL FROM:<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA> + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ; + 2 Nov 81 22:40:10 UT + S: Date: 2 Nov 81 22:33:44 + S: From: John Q. Public + S: Subject: The Next Meeting of the Board + S: To: Jones@BBN-Vax.ARPA + S: + S: Bill: + S: The next meeting of the board of directors will be + S: on Tuesday. + S: John. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIE.ARPA Service closing transmission channel + + Scenario 3 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + +[Page 54] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Verifying and Sending Scenario + + ------------------------------------------------------------- + + R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-MC.ARPA + R: 250 SU-SCORE.ARPA + + S: VRFY Crispin + R: 250 Mark Crispin + + S: SEND FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 SU-SCORE.ARPA Service closing transmission channel + + Scenario 4 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + +Postel [Page 55] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Sending and Mailing Scenarios + + First the user's name is verified, then an attempt is made to + send to the user's terminal. When that fails, the messages is + mailed to the user's mailbox. + + ------------------------------------------------------------- + + R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-MC.ARPA + R: 250 SU-SCORE.ARPA + + S: VRFY Crispin + R: 250 Mark Crispin + + S: SEND FROM: + R: 250 OK + + S: RCPT TO: + R: 450 User not active now + + S: RSET + R: 250 OK + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 SU-SCORE.ARPA Service closing transmission channel + + Scenario 5 + + ------------------------------------------------------------- + + + + + + +[Page 56] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Doing the preceding scenario more efficiently. + + ------------------------------------------------------------- + + R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-MC.ARPA + R: 250 SU-SCORE.ARPA + + S: VRFY Crispin + R: 250 Mark Crispin + + S: SOML FROM: + R: 250 OK + + S: RCPT TO: + R: 250 User not active now, so will do mail. + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 SU-SCORE.ARPA Service closing transmission channel + + Scenario 6 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + +Postel [Page 57] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Mailing List Scenario + + First each of two mailing lists are expanded in separate sessions + with different hosts. Then the message is sent to everyone that + appeared on either list (but no duplicates) via a relay host. + + ------------------------------------------------------------- + + Step 1 -- Expanding the First List + + R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready + S: HELO SU-SCORE.ARPA + R: 250 MIT-AI.ARPA + + S: EXPN Example-People + R: 250- + R: 250-Fred Fonebone + R: 250-Xenon Y. Zither + R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250- + R: 250 + + S: QUIT + R: 221 MIT-AI.ARPA Service closing transmission channel + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 58] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Step 2 -- Expanding the Second List + + R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready + S: HELO SU-SCORE.ARPA + R: 250 MIT-MC.ARPA + + S: EXPN Interested-Parties + R: 250-Al Calico + R: 250- + R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250- + R: 250 + + S: QUIT + R: 221 MIT-MC.ARPA Service closing transmission channel + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 59] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Step 3 -- Mailing to All via a Relay Host + + R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready + S: HELO SU-SCORE.ARPA + R: 250 USC-ISIE.ARPA + + S: MAIL FROM: + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:ABC@MIT-MC.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:Fonebone@USC-ISIQA.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:XYZ@MIT-AI.ARPA> + R: 250 OK + S: RCPT + TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:joe@FOO-UNIX.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:xyz@BAR-UNIX.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:fred@BBN-UNIX.ARPA> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIE.ARPA Service closing transmission channel + + Scenario 7 + + ------------------------------------------------------------- + + + + + + + + + + + + +[Page 60] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Forwarding Scenarios + + ------------------------------------------------------------- + + R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready + S: HELO LBL-UNIX.ARPA + R: 250 USC-ISIF.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 251 User not local; will forward to + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIF.ARPA Service closing transmission channel + + Scenario 8 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 61] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Step 1 -- Trying the Mailbox at the First Host + + R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready + S: HELO LBL-UNIX.ARPA + R: 250 USC-ISIF.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 251 User not local; will forward to + + S: RSET + R: 250 OK + + S: QUIT + R: 221 USC-ISIF.ARPA Service closing transmission channel + + Step 2 -- Delivering the Mail at the Second Host + + R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready + S: HELO LBL-UNIX.ARPA + R: 250 USC-ISI.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISI.ARPA Service closing transmission channel + + Scenario 9 + + ------------------------------------------------------------- + + + + +[Page 62] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Too Many Recipients Scenario + + ------------------------------------------------------------- + + R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready + S: HELO USC-ISIF.ARPA + R: 250 BERKELEY.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + R: 552 Recipient storage full, try again in another transaction + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 BERKELEY.ARPA Service closing transmission channel + + Scenario 10 + + ------------------------------------------------------------- + + Note that a real implementation must handle many recipients as + specified in Section 4.5.3. + + + +Postel [Page 63] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +GLOSSARY + + ASCII + + American Standard Code for Information Interchange [1]. + + command + + A request for a mail service action sent by the sender-SMTP to the + receiver-SMTP. + + domain + + The hierarchially structured global character string address of a + host computer in the mail system. + + end of mail data indication + + A special sequence of characters that indicates the end of the + mail data. In particular, the five characters carriage return, + line feed, period, carriage return, line feed, in that order. + + host + + A computer in the internetwork environment on which mailboxes or + SMTP processes reside. + + line + + A a sequence of ASCII characters ending with a . + + mail data + + A sequence of ASCII characters of arbitrary length, which conforms + to the standard set in the Standard for the Format of ARPA + Internet Text Messages (RFC 822 [2]). + + mailbox + + A character string (address) which identifies a user to whom mail + is to be sent. Mailbox normally consists of the host and user + specifications. The standard mailbox naming convention is defined + to be "user@domain". Additionally, the "container" in which mail + is stored. + + + + + +[Page 64] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + receiver-SMTP process + + A process which transfers mail in cooperation with a sender-SMTP + process. It waits for a connection to be established via the + transport service. It receives SMTP commands from the + sender-SMTP, sends replies, and performs the specified operations. + + reply + + A reply is an acknowledgment (positive or negative) sent from + receiver to sender via the transmission channel in response to a + command. The general form of a reply is a completion code + (including error codes) followed by a text string. The codes are + for use by programs and the text is usually intended for human + users. + + sender-SMTP process + + A process which transfers mail in cooperation with a receiver-SMTP + process. A local language may be used in the user interface + command/reply dialogue. The sender-SMTP initiates the transport + service connection. It initiates SMTP commands, receives replies, + and governs the transfer of mail. + + session + + The set of exchanges that occur while the transmission channel is + open. + + transaction + + The set of exchanges required for one message to be transmitted + for one or more recipients. + + transmission channel + + A full-duplex communication path between a sender-SMTP and a + receiver-SMTP for the exchange of commands, replies, and mail + text. + + transport service + + Any reliable stream-oriented data communication services. For + example, NCP, TCP, NITS. + + + + + +Postel [Page 65] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + user + + A human being (or a process on behalf of a human being) wishing to + obtain mail transfer service. In addition, a recipient of + computer mail. + + word + + A sequence of printing characters. + + + + The characters carriage return and line feed (in that order). + + + + The space character. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 66] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +REFERENCES + + [1] ASCII + + ASCII, "USA Code for Information Interchange", United States of + America Standards Institute, X3.4, 1968. Also in: Feinler, E. + and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for + the Defense Communications Agency by SRI International, Menlo + Park, California, Revised January 1978. + + [2] RFC 822 + + Crocker, D., "Standard for the Format of ARPA Internet Text + Messages," RFC 822, Department of Electrical Engineering, + University of Delaware, August 1982. + + [3] TCP + + Postel, J., ed., "Transmission Control Protocol - DARPA Internet + Program Protocol Specification", RFC 793, USC/Information Sciences + Institute, NTIS AD Number A111091, September 1981. Also in: + Feinler, E. and J. Postel, eds., "Internet Protocol Transition + Workbook", SRI International, Menlo Park, California, March 1982. + + [4] NCP + + McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246, + January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET + Protocol Handbook", NIC 7104, for the Defense Communications + Agency by SRI International, Menlo Park, California, Revised + January 1978. + + [5] Initial Connection Protocol + + Postel, J., "Official Initial Connection Protocol", NIC 7101, + 11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET + Protocol Handbook", NIC 7104, for the Defense Communications + Agency by SRI International, Menlo Park, California, Revised + January 1978. + + [6] NITS + + PSS/SG3, "A Network Independent Transport Service", Study Group 3, + The Post Office PSS Users Group, February 1980. Available from + the DCPU, National Physical Laboratory, Teddington, UK. + + + + +Postel [Page 67] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + [7] X.25 + + CCITT, "Recommendation X.25 - Interface Between Data Terminal + Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for + Terminals Operating in the Packet Mode on Public Data Networks," + CCITT Orange Book, Vol. VIII.2, International Telephone and + Telegraph Consultative Committee, Geneva, 1976. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 68] Postel + diff --git a/RFC/rfc822.txt b/RFC/rfc822.txt new file mode 100644 index 00000000..35b09a3c --- /dev/null +++ b/RFC/rfc822.txt @@ -0,0 +1,2901 @@ + + + + + + + RFC # 822 + + Obsoletes: RFC #733 (NIC #41952) + + + + + + + + + + + + + STANDARD FOR THE FORMAT OF + + ARPA INTERNET TEXT MESSAGES + + + + + + + August 13, 1982 + + + + + + + Revised by + + David H. Crocker + + + Dept. of Electrical Engineering + University of Delaware, Newark, DE 19711 + Network: DCrocker @ UDel-Relay + + + + + + + + + + + + + + + + Standard for ARPA Internet Text Messages + + + TABLE OF CONTENTS + + + PREFACE .................................................... ii + + 1. INTRODUCTION ........................................... 1 + + 1.1. Scope ............................................ 1 + 1.2. Communication Framework .......................... 2 + + 2. NOTATIONAL CONVENTIONS ................................. 3 + + 3. LEXICAL ANALYSIS OF MESSAGES ........................... 5 + + 3.1. General Description .............................. 5 + 3.2. Header Field Definitions ......................... 9 + 3.3. Lexical Tokens ................................... 10 + 3.4. Clarifications ................................... 11 + + 4. MESSAGE SPECIFICATION .................................. 17 + + 4.1. Syntax ........................................... 17 + 4.2. Forwarding ....................................... 19 + 4.3. Trace Fields ..................................... 20 + 4.4. Originator Fields ................................ 21 + 4.5. Receiver Fields .................................. 23 + 4.6. Reference Fields ................................. 23 + 4.7. Other Fields ..................................... 24 + + 5. DATE AND TIME SPECIFICATION ............................ 26 + + 5.1. Syntax ........................................... 26 + 5.2. Semantics ........................................ 26 + + 6. ADDRESS SPECIFICATION .................................. 27 + + 6.1. Syntax ........................................... 27 + 6.2. Semantics ........................................ 27 + 6.3. Reserved Address ................................. 33 + + 7. BIBLIOGRAPHY ........................................... 34 + + + APPENDIX + + A. EXAMPLES ............................................... 36 + B. SIMPLE FIELD PARSING ................................... 40 + C. DIFFERENCES FROM RFC #733 .............................. 41 + D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44 + + + August 13, 1982 - i - RFC #822 + + + + + Standard for ARPA Internet Text Messages + + + PREFACE + + + By 1977, the Arpanet employed several informal standards for + the text messages (mail) sent among its host computers. It was + felt necessary to codify these practices and provide for those + features that seemed imminent. The result of that effort was + Request for Comments (RFC) #733, "Standard for the Format of ARPA + Network Text Message", by Crocker, Vittal, Pogran, and Henderson. + The specification attempted to avoid major changes in existing + software, while permitting several new features. + + This document revises the specifications in RFC #733, in + order to serve the needs of the larger and more complex ARPA + Internet. Some of RFC #733's features failed to gain adequate + acceptance. In order to simplify the standard and the software + that follows it, these features have been removed. A different + addressing scheme is used, to handle the case of inter-network + mail; and the concept of re-transmission has been introduced. + + This specification is intended for use in the ARPA Internet. + However, an attempt has been made to free it of any dependence on + that environment, so that it can be applied to other network text + message systems. + + The specification of RFC #733 took place over the course of + one year, using the ARPANET mail environment, itself, to provide + an on-going forum for discussing the capabilities to be included. + More than twenty individuals, from across the country, partici- + pated in the original discussion. The development of this + revised specification has, similarly, utilized network mail-based + group discussion. Both specification efforts greatly benefited + from the comments and ideas of the participants. + + The syntax of the standard, in RFC #733, was originally + specified in the Backus-Naur Form (BNF) meta-language. Ken L. + Harrenstien, of SRI International, was responsible for re-coding + the BNF into an augmented BNF that makes the representation + smaller and easier to understand. + + + + + + + + + + + + + August 13, 1982 - ii - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 1. INTRODUCTION + + 1.1. SCOPE + + This standard specifies a syntax for text messages that are + sent among computer users, within the framework of "electronic + mail". The standard supersedes the one specified in ARPANET + Request for Comments #733, "Standard for the Format of ARPA Net- + work Text Messages". + + In this context, messages are viewed as having an envelope + and contents. The envelope contains whatever information is + needed to accomplish transmission and delivery. The contents + compose the object to be delivered to the recipient. This stan- + dard applies only to the format and some of the semantics of mes- + sage contents. It contains no specification of the information + in the envelope. + + However, some message systems may use information from the + contents to create the envelope. It is intended that this stan- + dard facilitate the acquisition of such information by programs. + + Some message systems may store messages in formats that + differ from the one specified in this standard. This specifica- + tion is intended strictly as a definition of what message content + format is to be passed BETWEEN hosts. + + Note: This standard is NOT intended to dictate the internal for- + mats used by sites, the specific message system features + that they are expected to support, or any of the charac- + teristics of user interface programs that create or read + messages. + + A distinction should be made between what the specification + REQUIRES and what it ALLOWS. Messages can be made complex and + rich with formally-structured components of information or can be + kept small and simple, with a minimum of such information. Also, + the standard simplifies the interpretation of differing visual + formats in messages; only the visual aspect of a message is + affected and not the interpretation of information within it. + Implementors may choose to retain such visual distinctions. + + The formal definition is divided into four levels. The bot- + tom level describes the meta-notation used in this document. The + second level describes basic lexical analyzers that feed tokens + to higher-level parsers. Next is an overall specification for + messages; it permits distinguishing individual fields. Finally, + there is definition of the contents of several structured fields. + + + + August 13, 1982 - 1 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 1.2. COMMUNICATION FRAMEWORK + + Messages consist of lines of text. No special provisions + are made for encoding drawings, facsimile, speech, or structured + text. No significant consideration has been given to questions + of data compression or to transmission and storage efficiency, + and the standard tends to be free with the number of bits con- + sumed. For example, field names are specified as free text, + rather than special terse codes. + + A general "memo" framework is used. That is, a message con- + sists of some information in a rigid format, followed by the main + part of the message, with a format that is not specified in this + document. The syntax of several fields of the rigidly-formated + ("headers") section is defined in this specification; some of + these fields must be included in all messages. + + The syntax that distinguishes between header fields is + specified separately from the internal syntax for particular + fields. This separation is intended to allow simple parsers to + operate on the general structure of messages, without concern for + the detailed structure of individual header fields. Appendix B + is provided to facilitate construction of these parsers. + + In addition to the fields specified in this document, it is + expected that other fields will gain common use. As necessary, + the specifications for these "extension-fields" will be published + through the same mechanism used to publish this document. Users + may also wish to extend the set of fields that they use + privately. Such "user-defined fields" are permitted. + + The framework severely constrains document tone and appear- + ance and is primarily useful for most intra-organization communi- + cations and well-structured inter-organization communication. + It also can be used for some types of inter-process communica- + tion, such as simple file transfer and remote job entry. A more + robust framework might allow for multi-font, multi-color, multi- + dimension encoding of information. A less robust one, as is + present in most single-machine message systems, would more + severely constrain the ability to add fields and the decision to + include specific fields. In contrast with paper-based communica- + tion, it is interesting to note that the RECEIVER of a message + can exercise an extraordinary amount of control over the + message's appearance. The amount of actual control available to + message receivers is contingent upon the capabilities of their + individual message systems. + + + + + + August 13, 1982 - 2 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 2. NOTATIONAL CONVENTIONS + + This specification uses an augmented Backus-Naur Form (BNF) + notation. The differences from standard BNF involve naming rules + and indicating repetition and "local" alternatives. + + 2.1. RULE NAMING + + Angle brackets ("<", ">") are not used, in general. The + name of a rule is simply the name itself, rather than "". + Quotation-marks enclose literal text (which may be upper and/or + lower case). Certain basic rules are in uppercase, such as + SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used in + rule definitions, and in the rest of this document, whenever + their presence will facilitate discerning the use of rule names. + + 2.2. RULE1 / RULE2: ALTERNATIVES + + Elements separated by slash ("/") are alternatives. There- + fore "foo / bar" will accept foo or bar. + + 2.3. (RULE1 RULE2): LOCAL ALTERNATIVES + + Elements enclosed in parentheses are treated as a single + element. Thus, "(elem (foo / bar) elem)" allows the token + sequences "elem foo elem" and "elem bar elem". + + 2.4. *RULE: REPETITION + + The character "*" preceding an element indicates repetition. + The full form is: + + *element + + indicating at least and at most occurrences of element. + Default values are 0 and infinity so that "*(element)" allows any + number, including zero; "1*element" requires at least one; and + "1*2element" allows one or two. + + 2.5. [RULE]: OPTIONAL + + Square brackets enclose optional elements; "[foo bar]" is + equivalent to "*1(foo bar)". + + 2.6. NRULE: SPECIFIC REPETITION + + "(element)" is equivalent to "*(element)"; that is, + exactly occurrences of (element). Thus 2DIGIT is a 2-digit + number, and 3ALPHA is a string of three alphabetic characters. + + + August 13, 1982 - 3 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 2.7. #RULE: LISTS + + A construct "#" is defined, similar to "*", as follows: + + #element + + indicating at least and at most elements, each separated + by one or more commas (","). This makes the usual form of lists + very easy; a rule such as '(element *("," element))' can be shown + as "1#element". Wherever this construct is used, null elements + are allowed, but do not contribute to the count of elements + present. That is, "(element),,(element)" is permitted, but + counts as only two elements. Therefore, where at least one ele- + ment is required, at least one non-null element must be present. + Default values are 0 and infinity so that "#(element)" allows any + number, including zero; "1#element" requires at least one; and + "1#2element" allows one or two. + + 2.8. ; COMMENTS + + A semi-colon, set off some distance to the right of rule + text, starts a comment that continues to the end of line. This + is a simple way of including useful notes in parallel with the + specifications. + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 4 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3. LEXICAL ANALYSIS OF MESSAGES + + 3.1. GENERAL DESCRIPTION + + A message consists of header fields and, optionally, a body. + The body is simply a sequence of lines containing ASCII charac- + ters. It is separated from the headers by a null line (i.e., a + line with nothing preceding the CRLF). + + 3.1.1. LONG HEADER FIELDS + + Each header field can be viewed as a single, logical line of + ASCII characters, comprising a field-name and a field-body. + For convenience, the field-body portion of this conceptual + entity can be split into a multiple-line representation; this + is called "folding". The general rule is that wherever there + may be linear-white-space (NOT simply LWSP-chars), a CRLF + immediately followed by AT LEAST one LWSP-char may instead be + inserted. Thus, the single line + + To: "Joe & J. Harvey" , JJV @ BBN + + can be represented as: + + To: "Joe & J. Harvey" , + JJV@BBN + + and + + To: "Joe & J. Harvey" + , JJV + @BBN + + and + + To: "Joe & + J. Harvey" , JJV @ BBN + + The process of moving from this folded multiple-line + representation of a header field to its single line represen- + tation is called "unfolding". Unfolding is accomplished by + regarding CRLF immediately followed by a LWSP-char as + equivalent to the LWSP-char. + + Note: While the standard permits folding wherever linear- + white-space is permitted, it is recommended that struc- + tured fields, such as those containing addresses, limit + folding to higher-level syntactic breaks. For address + fields, it is recommended that such folding occur + + + August 13, 1982 - 5 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + between addresses, after the separating comma. + + 3.1.2. STRUCTURE OF HEADER FIELDS + + Once a field has been unfolded, it may be viewed as being com- + posed of a field-name followed by a colon (":"), followed by a + field-body, and terminated by a carriage-return/line-feed. + The field-name must be composed of printable ASCII characters + (i.e., characters that have values between 33. and 126., + decimal, except colon). The field-body may be composed of any + ASCII characters, except CR or LF. (While CR and/or LF may be + present in the actual text, they are removed by the action of + unfolding the field.) + + Certain field-bodies of headers may be interpreted according + to an internal syntax that some systems may wish to parse. + These fields are called "structured fields". Examples + include fields containing dates and addresses. Other fields, + such as "Subject" and "Comments", are regarded simply as + strings of text. + + Note: Any field which has a field-body that is defined as + other than simply is to be treated as a struc- + tured field. + + Field-names, unstructured field bodies and structured + field bodies each are scanned by their own, independent + "lexical" analyzers. + + 3.1.3. UNSTRUCTURED FIELD BODIES + + For some fields, such as "Subject" and "Comments", no struc- + turing is assumed, and they are treated simply as s, as + in the message body. Rules of folding apply to these fields, + so that such field bodies which occupy several lines must + therefore have the second and successive lines indented by at + least one LWSP-char. + + 3.1.4. STRUCTURED FIELD BODIES + + To aid in the creation and reading of structured fields, the + free insertion of linear-white-space (which permits folding + by inclusion of CRLFs) is allowed between lexical tokens. + Rather than obscuring the syntax specifications for these + structured fields with explicit syntax for this linear-white- + space, the existence of another "lexical" analyzer is assumed. + This analyzer does not apply for unstructured field bodies + that are simply strings of text, as described above. The + analyzer provides an interpretation of the unfolded text + + + August 13, 1982 - 6 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + composing the body of the field as a sequence of lexical sym- + bols. + + These symbols are: + + - individual special characters + - quoted-strings + - domain-literals + - comments + - atoms + + The first four of these symbols are self-delimiting. Atoms + are not; they are delimited by the self-delimiting symbols and + by linear-white-space. For the purposes of regenerating + sequences of atoms and quoted-strings, exactly one SPACE is + assumed to exist, and should be used, between them. (Also, in + the "Clarifications" section on "White Space", below, note the + rules about treatment of multiple contiguous LWSP-chars.) + + So, for example, the folded body of an address field + + ":sysmail"@ Some-Group. Some-Org, + Muhammed.(I am the greatest) Ali @(the)Vegas.WBA + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 7 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + is analyzed into the following lexical symbols and types: + + :sysmail quoted string + @ special + Some-Group atom + . special + Some-Org atom + , special + Muhammed atom + . special + (I am the greatest) comment + Ali atom + @ atom + (the) comment + Vegas atom + . special + WBA atom + + The canonical representations for the data in these addresses + are the following strings: + + ":sysmail"@Some-Group.Some-Org + + and + + Muhammed.Ali@Vegas.WBA + + Note: For purposes of display, and when passing such struc- + tured information to other systems, such as mail proto- + col services, there must be NO linear-white-space + between s that are separated by period (".") or + at-sign ("@") and exactly one SPACE between all other + s. Also, headers should be in a folded form. + + + + + + + + + + + + + + + + + + + August 13, 1982 - 8 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.2. HEADER FIELD DEFINITIONS + + These rules show a field meta-syntax, without regard for the + particular type or internal syntax. Their purpose is to permit + detection of fields; also, they present to higher-level parsers + an image of each field as fitting on one line. + + field = field-name ":" [ field-body ] CRLF + + field-name = 1* + + field-body = field-body-contents + [CRLF LWSP-char field-body] + + field-body-contents = + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 9 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.3. LEXICAL TOKENS + + The following rules are used to define an underlying lexical + analyzer, which feeds tokens to higher level parsers. See the + ANSI references, in the Bibliography. + + ; ( Octal, Decimal.) + CHAR = ; ( 0-177, 0.-127.) + ALPHA = + ; (101-132, 65.- 90.) + ; (141-172, 97.-122.) + DIGIT = ; ( 60- 71, 48.- 57.) + CTL = ; ( 177, 127.) + CR = ; ( 15, 13.) + LF = ; ( 12, 10.) + SPACE = ; ( 40, 32.) + HTAB = ; ( 11, 9.) + <"> = ; ( 42, 34.) + CRLF = CR LF + + LWSP-char = SPACE / HTAB ; semantics = SPACE + + linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE + ; CRLF => folding + + specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- + / "," / ";" / ":" / "\" / <"> ; string, to use + / "." / "[" / "]" ; within a word. + + delimiters = specials / linear-white-space / comment + + text = atoms, specials, + CR & bare LF, but NOT ; comments and + including CRLF> ; quoted-strings are + ; NOT recognized. + + atom = 1* + + quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or + ; quoted chars. + + qtext = , ; => may be folded + "\" & CR, and including + linear-white-space> + + domain-literal = "[" *(dtext / quoted-pair) "]" + + + + + August 13, 1982 - 10 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + dtext = may be folded + "]", "\" & CR, & including + linear-white-space> + + comment = "(" *(ctext / quoted-pair / comment) ")" + + ctext = may be folded + ")", "\" & CR, & including + linear-white-space> + + quoted-pair = "\" CHAR ; may quote any char + + phrase = 1*word ; Sequence of words + + word = atom / quoted-string + + + 3.4. CLARIFICATIONS + + 3.4.1. QUOTING + + Some characters are reserved for special interpretation, such + as delimiting lexical tokens. To permit use of these charac- + ters as uninterpreted data, a quoting mechanism is provided. + To quote a character, precede it with a backslash ("\"). + + This mechanism is not fully general. Characters may be quoted + only within a subset of the lexical constructs. In particu- + lar, quoting is limited to use within: + + - quoted-string + - domain-literal + - comment + + Within these constructs, quoting is REQUIRED for CR and "\" + and for the character(s) that delimit the token (e.g., "(" and + ")" for a comment). However, quoting is PERMITTED for any + character. + + Note: In particular, quoting is NOT permitted within atoms. + For example when the local-part of an addr-spec must + contain a special character, a quoted string must be + used. Therefore, a specification such as: + + Full\ Name@Domain + + is not legal and must be specified as: + + "Full Name"@Domain + + + August 13, 1982 - 11 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.4.2. WHITE SPACE + + Note: In structured field bodies, multiple linear space ASCII + characters (namely HTABs and SPACEs) are treated as + single spaces and may freely surround any symbol. In + all header fields, the only place in which at least one + LWSP-char is REQUIRED is at the beginning of continua- + tion lines in a folded field. + + When passing text to processes that do not interpret text + according to this standard (e.g., mail protocol servers), then + NO linear-white-space characters should occur between a period + (".") or at-sign ("@") and a . Exactly ONE SPACE should + be used in place of arbitrary linear-white-space and comment + sequences. + + Note: Within systems conforming to this standard, wherever a + member of the list of delimiters is allowed, LWSP-chars + may also occur before and/or after it. + + Writers of mail-sending (i.e., header-generating) programs + should realize that there is no network-wide definition of the + effect of ASCII HT (horizontal-tab) characters on the appear- + ance of text at another network host; therefore, the use of + tabs in message headers, though permitted, is discouraged. + + 3.4.3. COMMENTS + + A comment is a set of ASCII characters, which is enclosed in + matching parentheses and which is not within a quoted-string + The comment construct permits message originators to add text + which will be useful for human readers, but which will be + ignored by the formal semantics. Comments should be retained + while the message is subject to interpretation according to + this standard. However, comments must NOT be included in + other cases, such as during protocol exchanges with mail + servers. + + Comments nest, so that if an unquoted left parenthesis occurs + in a comment string, there must also be a matching right + parenthesis. When a comment acts as the delimiter between a + sequence of two lexical symbols, such as two atoms, it is lex- + ically equivalent with a single SPACE, for the purposes of + regenerating the sequence, such as when passing the sequence + onto a mail protocol server. Comments are detected as such + only within field-bodies of structured fields. + + If a comment is to be "folded" onto multiple lines, then the + syntax for folding must be adhered to. (See the "Lexical + + + August 13, 1982 - 12 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Analysis of Messages" section on "Folding Long Header Fields" + above, and the section on "Case Independence" below.) Note + that the official semantics therefore do not "see" any + unquoted CRLFs that are in comments, although particular pars- + ing programs may wish to note their presence. For these pro- + grams, it would be reasonable to interpret a "CRLF LWSP-char" + as being a CRLF that is part of the comment; i.e., the CRLF is + kept and the LWSP-char is discarded. Quoted CRLFs (i.e., a + backslash followed by a CR followed by a LF) still must be + followed by at least one LWSP-char. + + 3.4.4. DELIMITING AND QUOTING CHARACTERS + + The quote character (backslash) and characters that delimit + syntactic units are not, generally, to be taken as data that + are part of the delimited or quoted unit(s). In particular, + the quotation-marks that define a quoted-string, the + parentheses that define a comment and the backslash that + quotes a following character are NOT part of the quoted- + string, comment or quoted character. A quotation-mark that is + to be part of a quoted-string, a parenthesis that is to be + part of a comment and a backslash that is to be part of either + must each be preceded by the quote-character backslash ("\"). + Note that the syntax allows any character to be quoted within + a quoted-string or comment; however only certain characters + MUST be quoted to be included as data. These characters are + the ones that are not part of the alternate text group (i.e., + ctext or qtext). + + The one exception to this rule is that a single SPACE is + assumed to exist between contiguous words in a phrase, and + this interpretation is independent of the actual number of + LWSP-chars that the creator places between the words. To + include more than one SPACE, the creator must make the LWSP- + chars be part of a quoted-string. + + Quotation marks that delimit a quoted string and backslashes + that quote the following character should NOT accompany the + quoted-string when the string is passed to processes that do + not interpret data according to this specification (e.g., mail + protocol servers). + + 3.4.5. QUOTED-STRINGS + + Where permitted (i.e., in words in structured fields) quoted- + strings are treated as a single symbol. That is, a quoted- + string is equivalent to an atom, syntactically. If a quoted- + string is to be "folded" onto multiple lines, then the syntax + for folding must be adhered to. (See the "Lexical Analysis of + + + August 13, 1982 - 13 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Messages" section on "Folding Long Header Fields" above, and + the section on "Case Independence" below.) Therefore, the + official semantics do not "see" any bare CRLFs that are in + quoted-strings; however particular parsing programs may wish + to note their presence. For such programs, it would be rea- + sonable to interpret a "CRLF LWSP-char" as being a CRLF which + is part of the quoted-string; i.e., the CRLF is kept and the + LWSP-char is discarded. Quoted CRLFs (i.e., a backslash fol- + lowed by a CR followed by a LF) are also subject to rules of + folding, but the presence of the quoting character (backslash) + explicitly indicates that the CRLF is data to the quoted + string. Stripping off the first following LWSP-char is also + appropriate when parsing quoted CRLFs. + + 3.4.6. BRACKETING CHARACTERS + + There is one type of bracket which must occur in matched pairs + and may have pairs nested within each other: + + o Parentheses ("(" and ")") are used to indicate com- + ments. + + There are three types of brackets which must occur in matched + pairs, and which may NOT be nested: + + o Colon/semi-colon (":" and ";") are used in address + specifications to indicate that the included list of + addresses are to be treated as a group. + + o Angle brackets ("<" and ">") are generally used to + indicate the presence of a one machine-usable refer- + ence (e.g., delimiting mailboxes), possibly including + source-routing to the machine. + + o Square brackets ("[" and "]") are used to indicate the + presence of a domain-literal, which the appropriate + name-domain is to use directly, bypassing normal + name-resolution mechanisms. + + 3.4.7. CASE INDEPENDENCE + + Except as noted, alphabetic strings may be represented in any + combination of upper and lower case. The only syntactic units + + + + + + + + + August 13, 1982 - 14 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + which requires preservation of case information are: + + - text + - qtext + - dtext + - ctext + - quoted-pair + - local-part, except "Postmaster" + + When matching any other syntactic unit, case is to be ignored. + For example, the field-names "From", "FROM", "from", and even + "FroM" are semantically equal and should all be treated ident- + ically. + + When generating these units, any mix of upper and lower case + alphabetic characters may be used. The case shown in this + specification is suggested for message-creating processes. + + Note: The reserved local-part address unit, "Postmaster", is + an exception. When the value "Postmaster" is being + interpreted, it must be accepted in any mixture of + case, including "POSTMASTER", and "postmaster". + + 3.4.8. FOLDING LONG HEADER FIELDS + + Each header field may be represented on exactly one line con- + sisting of the name of the field and its body, and terminated + by a CRLF; this is what the parser sees. For readability, the + field-body portion of long header fields may be "folded" onto + multiple lines of the actual field. "Long" is commonly inter- + preted to mean greater than 65 or 72 characters. The former + length serves as a limit, when the message is to be viewed on + most simple terminals which use simple display software; how- + ever, the limit is not imposed by this standard. + + Note: Some display software often can selectively fold lines, + to suit the display terminal. In such cases, sender- + provided folding can interfere with the display + software. + + 3.4.9. BACKSPACE CHARACTERS + + ASCII BS characters (Backspace, decimal 8) may be included in + texts and quoted-strings to effect overstriking. However, any + use of backspaces which effects an overstrike to the left of + the beginning of the text or quoted-string is prohibited. + + + + + + August 13, 1982 - 15 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS + + During transmission through heterogeneous networks, it may be + necessary to force data to conform to a network's local con- + ventions. For example, it may be required that a CR be fol- + lowed either by LF, making a CRLF, or by , if the CR is + to stand alone). Such transformations are reversed, when the + message exits that network. + + When crossing network boundaries, the message should be + treated as passing through two modules. It will enter the + first module containing whatever network-specific transforma- + tions that were necessary to permit migration through the + "current" network. It then passes through the modules: + + o Transformation Reversal + + The "current" network's idiosyncracies are removed and + the message is returned to the canonical form speci- + fied in this standard. + + o Transformation + + The "next" network's local idiosyncracies are imposed + on the message. + + ------------------ + From ==> | Remove Net-A | + Net-A | idiosyncracies | + ------------------ + || + \/ + Conformance + with standard + || + \/ + ------------------ + | Impose Net-B | ==> To + | idiosyncracies | Net-B + ------------------ + + + + + + + + + + + + August 13, 1982 - 16 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 4. MESSAGE SPECIFICATION + + 4.1. SYNTAX + + Note: Due to an artifact of the notational conventions, the syn- + tax indicates that, when present, some fields, must be in + a particular order. Header fields are NOT required to + occur in any particular order, except that the message + body must occur AFTER the headers. It is recommended + that, if present, headers be sent in the order "Return- + Path", "Received", "Date", "From", "Subject", "Sender", + "To", "cc", etc. + + This specification permits multiple occurrences of most + fields. Except as noted, their interpretation is not + specified here, and their use is discouraged. + + The following syntax for the bodies of various fields should + be thought of as describing each field body as a single long + string (or line). The "Lexical Analysis of Message" section on + "Long Header Fields", above, indicates how such long strings can + be represented on more than one line in the actual transmitted + message. + + message = fields *( CRLF *text ) ; Everything after + ; first null line + ; is message body + + fields = dates ; Creation time, + source ; author id & one + 1*destination ; address required + *optional-field ; others optional + + source = [ trace ] ; net traversals + originator ; original mail + [ resent ] ; forwarded + + trace = return ; path to sender + 1*received ; receipt tags + + return = "Return-path" ":" route-addr ; return address + + received = "Received" ":" ; one per relay + ["from" domain] ; sending host + ["by" domain] ; receiving host + ["via" atom] ; physical path + *("with" atom) ; link/mail protocol + ["id" msg-id] ; receiver msg id + ["for" addr-spec] ; initial form + + + August 13, 1982 - 17 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + ";" date-time ; time received + + originator = authentic ; authenticated addr + [ "Reply-To" ":" 1#address] ) + + authentic = "From" ":" mailbox ; Single author + / ( "Sender" ":" mailbox ; Actual submittor + "From" ":" 1#mailbox) ; Multiple authors + ; or not sender + + resent = resent-authentic + [ "Resent-Reply-To" ":" 1#address] ) + + resent-authentic = + = "Resent-From" ":" mailbox + / ( "Resent-Sender" ":" mailbox + "Resent-From" ":" 1#mailbox ) + + dates = orig-date ; Original + [ resent-date ] ; Forwarded + + orig-date = "Date" ":" date-time + + resent-date = "Resent-Date" ":" date-time + + destination = "To" ":" 1#address ; Primary + / "Resent-To" ":" 1#address + / "cc" ":" 1#address ; Secondary + / "Resent-cc" ":" 1#address + / "bcc" ":" #address ; Blind carbon + / "Resent-bcc" ":" #address + + optional-field = + / "Message-ID" ":" msg-id + / "Resent-Message-ID" ":" msg-id + / "In-Reply-To" ":" *(phrase / msg-id) + / "References" ":" *(phrase / msg-id) + / "Keywords" ":" #phrase + / "Subject" ":" *text + / "Comments" ":" *text + / "Encrypted" ":" 1#2word + / extension-field ; To be defined + / user-defined-field ; May be pre-empted + + msg-id = "<" addr-spec ">" ; Unique message id + + + + + + + August 13, 1982 - 18 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + extension-field = + + + user-defined-field = + + + 4.2. FORWARDING + + Some systems permit mail recipients to forward a message, + retaining the original headers, by adding some new fields. This + standard supports such a service, through the "Resent-" prefix to + field names. + + Whenever the string "Resent-" begins a field name, the field + has the same semantics as a field whose name does not have the + prefix. However, the message is assumed to have been forwarded + by an original recipient who attached the "Resent-" field. This + new field is treated as being more recent than the equivalent, + original field. For example, the "Resent-From", indicates the + person that forwarded the message, whereas the "From" field indi- + cates the original author. + + Use of such precedence information depends upon partici- + pants' communication needs. For example, this standard does not + dictate when a "Resent-From:" address should receive replies, in + lieu of sending them to the "From:" address. + + Note: In general, the "Resent-" fields should be treated as con- + taining a set of information that is independent of the + set of original fields. Information for one set should + not automatically be taken from the other. The interpre- + tation of multiple "Resent-" fields, of the same type, is + undefined. + + In the remainder of this specification, occurrence of legal + "Resent-" fields are treated identically with the occurrence of + + + + + + + + + August 13, 1982 - 19 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + fields whose names do not contain this prefix. + + 4.3. TRACE FIELDS + + Trace information is used to provide an audit trail of mes- + sage handling. In addition, it indicates a route back to the + sender of the message. + + The list of known "via" and "with" values are registered + with the Network Information Center, SRI International, Menlo + Park, California. + + 4.3.1. RETURN-PATH + + This field is added by the final transport system that + delivers the message to its recipient. The field is intended + to contain definitive information about the address and route + back to the message's originator. + + Note: The "Reply-To" field is added by the originator and + serves to direct replies, whereas the "Return-Path" + field is used to identify a path back to the origina- + tor. + + While the syntax indicates that a route specification is + optional, every attempt should be made to provide that infor- + mation in this field. + + 4.3.2. RECEIVED + + A copy of this field is added by each transport service that + relays the message. The information in the field can be quite + useful for tracing transport problems. + + The names of the sending and receiving hosts and time-of- + receipt may be specified. The "via" parameter may be used, to + indicate what physical mechanism the message was sent over, + such as Arpanet or Phonenet, and the "with" parameter may be + used to indicate the mail-, or connection-, level protocol + that was used, such as the SMTP mail protocol, or X.25 tran- + sport protocol. + + Note: Several "with" parameters may be included, to fully + specify the set of protocols that were used. + + Some transport services queue mail; the internal message iden- + tifier that is assigned to the message may be noted, using the + "id" parameter. When the sending host uses a destination + address specification that the receiving host reinterprets, by + + + August 13, 1982 - 20 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + expansion or transformation, the receiving host may wish to + record the original specification, using the "for" parameter. + For example, when a copy of mail is sent to the member of a + distribution list, this parameter may be used to record the + original address that was used to specify the list. + + 4.4. ORIGINATOR FIELDS + + The standard allows only a subset of the combinations possi- + ble with the From, Sender, Reply-To, Resent-From, Resent-Sender, + and Resent-Reply-To fields. The limitation is intentional. + + 4.4.1. FROM / RESENT-FROM + + This field contains the identity of the person(s) who wished + this message to be sent. The message-creation process should + default this field to be a single, authenticated machine + address, indicating the AGENT (person, system or process) + entering the message. If this is not done, the "Sender" field + MUST be present. If the "From" field IS defaulted this way, + the "Sender" field is optional and is redundant with the + "From" field. In all cases, addresses in the "From" field + must be machine-usable (addr-specs) and may not contain named + lists (groups). + + 4.4.2. SENDER / RESENT-SENDER + + This field contains the authenticated identity of the AGENT + (person, system or process) that sends the message. It is + intended for use when the sender is not the author of the mes- + sage, or to indicate who among a group of authors actually + sent the message. If the contents of the "Sender" field would + be completely redundant with the "From" field, then the + "Sender" field need not be present and its use is discouraged + (though still legal). In particular, the "Sender" field MUST + be present if it is NOT the same as the "From" Field. + + The Sender mailbox specification includes a word sequence + which must correspond to a specific agent (i.e., a human user + or a computer program) rather than a standard address. This + indicates the expectation that the field will identify the + single AGENT (person, system, or process) responsible for + sending the mail and not simply include the name of a mailbox + from which the mail was sent. For example in the case of a + shared login name, the name, by itself, would not be adequate. + The local-part address unit, which refers to this agent, is + expected to be a computer system term, and not (for example) a + generalized person reference which can be used outside the + network text message context. + + + August 13, 1982 - 21 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Since the critical function served by the "Sender" field is + identification of the agent responsible for sending mail and + since computer programs cannot be held accountable for their + behavior, it is strongly recommended that when a computer pro- + gram generates a message, the HUMAN who is responsible for + that program be referenced as part of the "Sender" field mail- + box specification. + + 4.4.3. REPLY-TO / RESENT-REPLY-TO + + This field provides a general mechanism for indicating any + mailbox(es) to which responses are to be sent. Three typical + uses for this feature can be distinguished. In the first + case, the author(s) may not have regular machine-based mail- + boxes and therefore wish(es) to indicate an alternate machine + address. In the second case, an author may wish additional + persons to be made aware of, or responsible for, replies. A + somewhat different use may be of some help to "text message + teleconferencing" groups equipped with automatic distribution + services: include the address of that service in the "Reply- + To" field of all messages submitted to the teleconference; + then participants can "reply" to conference submissions to + guarantee the correct distribution of any submission of their + own. + + Note: The "Return-Path" field is added by the mail transport + service, at the time of final deliver. It is intended + to identify a path back to the orginator of the mes- + sage. The "Reply-To" field is added by the message + originator and is intended to direct replies. + + 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO + + For systems which automatically generate address lists for + replies to messages, the following recommendations are made: + + o The "Sender" field mailbox should be sent notices of + any problems in transport or delivery of the original + messages. If there is no "Sender" field, then the + "From" field mailbox should be used. + + o The "Sender" field mailbox should NEVER be used + automatically, in a recipient's reply message. + + o If the "Reply-To" field exists, then the reply should + go to the addresses indicated in that field and not to + the address(es) indicated in the "From" field. + + + + + August 13, 1982 - 22 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + o If there is a "From" field, but no "Reply-To" field, + the reply should be sent to the address(es) indicated + in the "From" field. + + Sometimes, a recipient may actually wish to communicate with + the person that initiated the message transfer. In such + cases, it is reasonable to use the "Sender" address. + + This recommendation is intended only for automated use of + originator-fields and is not intended to suggest that replies + may not also be sent to other recipients of messages. It is + up to the respective mail-handling programs to decide what + additional facilities will be provided. + + Examples are provided in Appendix A. + + 4.5. RECEIVER FIELDS + + 4.5.1. TO / RESENT-TO + + This field contains the identity of the primary recipients of + the message. + + 4.5.2. CC / RESENT-CC + + This field contains the identity of the secondary (informa- + tional) recipients of the message. + + 4.5.3. BCC / RESENT-BCC + + This field contains the identity of additional recipients of + the message. The contents of this field are not included in + copies of the message sent to the primary and secondary reci- + pients. Some systems may choose to include the text of the + "Bcc" field only in the author(s)'s copy, while others may + also include it in the text sent to all those indicated in the + "Bcc" list. + + 4.6. REFERENCE FIELDS + + 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID + + This field contains a unique identifier (the local-part + address unit) which refers to THIS version of THIS message. + The uniqueness of the message identifier is guaranteed by the + host which generates it. This identifier is intended to be + machine readable and not necessarily meaningful to humans. A + message identifier pertains to exactly one instantiation of a + particular message; subsequent revisions to the message should + + + August 13, 1982 - 23 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + each receive new message identifiers. + + 4.6.2. IN-REPLY-TO + + The contents of this field identify previous correspon- + dence which this message answers. Note that if message iden- + tifiers are used in this field, they must use the msg-id + specification format. + + 4.6.3. REFERENCES + + The contents of this field identify other correspondence + which this message references. Note that if message identif- + iers are used, they must use the msg-id specification format. + + 4.6.4. KEYWORDS + + This field contains keywords or phrases, separated by + commas. + + 4.7. OTHER FIELDS + + 4.7.1. SUBJECT + + This is intended to provide a summary, or indicate the + nature, of the message. + + 4.7.2. COMMENTS + + Permits adding text comments onto the message without + disturbing the contents of the message's body. + + 4.7.3. ENCRYPTED + + Sometimes, data encryption is used to increase the + privacy of message contents. If the body of a message has + been encrypted, to keep its contents private, the "Encrypted" + field can be used to note the fact and to indicate the nature + of the encryption. The first parameter indicates the + software used to encrypt the body, and the second, optional + is intended to aid the recipient in selecting the + proper decryption key. This code word may be viewed as an + index to a table of keys held by the recipient. + + Note: Unfortunately, headers must contain envelope, as well + as contents, information. Consequently, it is neces- + sary that they remain unencrypted, so that mail tran- + sport services may access them. Since names, + addresses, and "Subject" field contents may contain + + + August 13, 1982 - 24 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + sensitive information, this requirement limits total + message privacy. + + Names of encryption software are registered with the Net- + work Information Center, SRI International, Menlo Park, Cali- + fornia. + + 4.7.4. EXTENSION-FIELD + + A limited number of common fields have been defined in + this document. As network mail requirements dictate, addi- + tional fields may be standardized. To provide user-defined + fields with a measure of safety, in name selection, such + extension-fields will never have names that begin with the + string "X-". + + Names of Extension-fields are registered with the Network + Information Center, SRI International, Menlo Park, California. + + 4.7.5. USER-DEFINED-FIELD + + Individual users of network mail are free to define and + use additional header fields. Such fields must have names + which are not already used in the current specification or in + any definitions of extension-fields, and the overall syntax of + these user-defined-fields must conform to this specification's + rules for delimiting and folding fields. Due to the + extension-field publishing process, the name of a user- + defined-field may be pre-empted + + Note: The prefatory string "X-" will never be used in the + names of Extension-fields. This provides user-defined + fields with a protected set of names. + + + + + + + + + + + + + + + + + + + August 13, 1982 - 25 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 5. DATE AND TIME SPECIFICATION + + 5.1. SYNTAX + + date-time = [ day "," ] date time ; dd mm yy + ; hh:mm:ss zzz + + day = "Mon" / "Tue" / "Wed" / "Thu" + / "Fri" / "Sat" / "Sun" + + date = 1*2DIGIT month 2DIGIT ; day month year + ; e.g. 20 Jun 82 + + month = "Jan" / "Feb" / "Mar" / "Apr" + / "May" / "Jun" / "Jul" / "Aug" + / "Sep" / "Oct" / "Nov" / "Dec" + + time = hour zone ; ANSI and Military + + hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] + ; 00:00:00 - 23:59:59 + + zone = "UT" / "GMT" ; Universal Time + ; North American : UT + / "EST" / "EDT" ; Eastern: - 5/ - 4 + / "CST" / "CDT" ; Central: - 6/ - 5 + / "MST" / "MDT" ; Mountain: - 7/ - 6 + / "PST" / "PDT" ; Pacific: - 8/ - 7 + / 1ALPHA ; Military: Z = UT; + ; A:-1; (J not used) + ; M:-12; N:+1; Y:+12 + / ( ("+" / "-") 4DIGIT ) ; Local differential + ; hours+min. (HHMM) + + 5.2. SEMANTICS + + If included, day-of-week must be the day implied by the date + specification. + + Time zone may be indicated in several ways. "UT" is Univer- + sal Time (formerly called "Greenwich Mean Time"); "GMT" is per- + mitted as a reference to Universal Time. The military standard + uses a single character for each zone. "Z" is Universal Time. + "A" indicates one hour earlier, and "M" indicates 12 hours ear- + lier; "N" is one hour later, and "Y" is 12 hours later. The + letter "J" is not used. The other remaining two forms are taken + from ANSI standard X3.51-1975. One allows explicit indication of + the amount of offset from UT; the other uses common 3-character + strings for indicating time zones in North America. + + + August 13, 1982 - 26 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 6. ADDRESS SPECIFICATION + + 6.1. SYNTAX + + address = mailbox ; one addressee + / group ; named list + + group = phrase ":" [#mailbox] ";" + + mailbox = addr-spec ; simple address + / phrase route-addr ; name & addr-spec + + route-addr = "<" [route] addr-spec ">" + + route = 1#("@" domain) ":" ; path-relative + + addr-spec = local-part "@" domain ; global address + + local-part = word *("." word) ; uninterpreted + ; case-preserved + + domain = sub-domain *("." sub-domain) + + sub-domain = domain-ref / domain-literal + + domain-ref = atom ; symbolic reference + + 6.2. SEMANTICS + + A mailbox receives mail. It is a conceptual entity which + does not necessarily pertain to file storage. For example, some + sites may choose to print mail on their line printer and deliver + the output to the addressee's desk. + + A mailbox specification comprises a person, system or pro- + cess name reference, a domain-dependent string, and a name-domain + reference. The name reference is optional and is usually used to + indicate the human name of a recipient. The name-domain refer- + ence specifies a sequence of sub-domains. The domain-dependent + string is uninterpreted, except by the final sub-domain; the rest + of the mail service merely transmits it as a literal string. + + 6.2.1. DOMAINS + + A name-domain is a set of registered (mail) names. A name- + domain specification resolves to a subordinate name-domain + specification or to a terminal domain-dependent string. + Hence, domain specification is extensible, permitting any + number of registration levels. + + + August 13, 1982 - 27 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Name-domains model a global, logical, hierarchical addressing + scheme. The model is logical, in that an address specifica- + tion is related to name registration and is not necessarily + tied to transmission path. The model's hierarchy is a + directed graph, called an in-tree, such that there is a single + path from the root of the tree to any node in the hierarchy. + If more than one path actually exists, they are considered to + be different addresses. + + The root node is common to all addresses; consequently, it is + not referenced. Its children constitute "top-level" name- + domains. Usually, a service has access to its own full domain + specification and to the names of all top-level name-domains. + + The "top" of the domain addressing hierarchy -- a child of the + root -- is indicated by the right-most field, in a domain + specification. Its child is specified to the left, its child + to the left, and so on. + + Some groups provide formal registration services; these con- + stitute name-domains that are independent logically of + specific machines. In addition, networks and machines impli- + citly compose name-domains, since their membership usually is + registered in name tables. + + In the case of formal registration, an organization implements + a (distributed) data base which provides an address-to-route + mapping service for addresses of the form: + + person@registry.organization + + Note that "organization" is a logical entity, separate from + any particular communication network. + + A mechanism for accessing "organization" is universally avail- + able. That mechanism, in turn, seeks an instantiation of the + registry; its location is not indicated in the address specif- + ication. It is assumed that the system which operates under + the name "organization" knows how to find a subordinate regis- + try. The registry will then use the "person" string to deter- + mine where to send the mail specification. + + The latter, network-oriented case permits simple, direct, + attachment-related address specification, such as: + + user@host.network + + Once the network is accessed, it is expected that a message + will go directly to the host and that the host will resolve + + + August 13, 1982 - 28 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + the user name, placing the message in the user's mailbox. + + 6.2.2. ABBREVIATED DOMAIN SPECIFICATION + + Since any number of levels is possible within the domain + hierarchy, specification of a fully qualified address can + become inconvenient. This standard permits abbreviated domain + specification, in a special case: + + For the address of the sender, call the left-most + sub-domain Level N. In a header address, if all of + the sub-domains above (i.e., to the right of) Level N + are the same as those of the sender, then they do not + have to appear in the specification. Otherwise, the + address must be fully qualified. + + This feature is subject to approval by local sub- + domains. Individual sub-domains may require their + member systems, which originate mail, to provide full + domain specification only. When permitted, abbrevia- + tions may be present only while the message stays + within the sub-domain of the sender. + + Use of this mechanism requires the sender's sub-domain + to reserve the names of all top-level domains, so that + full specifications can be distinguished from abbrevi- + ated specifications. + + For example, if a sender's address is: + + sender@registry-A.registry-1.organization-X + + and one recipient's address is: + + recipient@registry-B.registry-1.organization-X + + and another's is: + + recipient@registry-C.registry-2.organization-X + + then ".registry-1.organization-X" need not be specified in the + the message, but "registry-C.registry-2" DOES have to be + specified. That is, the first two addresses may be abbrevi- + ated, but the third address must be fully specified. + + When a message crosses a domain boundary, all addresses must + be specified in the full format, ending with the top-level + name-domain in the right-most field. It is the responsibility + of mail forwarding services to ensure that addresses conform + + + August 13, 1982 - 29 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + with this requirement. In the case of abbreviated addresses, + the relaying service must make the necessary expansions. It + should be noted that it often is difficult for such a service + to locate all occurrences of address abbreviations. For exam- + ple, it will not be possible to find such abbreviations within + the body of the message. The "Return-Path" field can aid + recipients in recovering from these errors. + + Note: When passing any portion of an addr-spec onto a process + which does not interpret data according to this stan- + dard (e.g., mail protocol servers). There must be NO + LWSP-chars preceding or following the at-sign or any + delimiting period ("."), such as shown in the above + examples, and only ONE SPACE between contiguous + s. + + 6.2.3. DOMAIN TERMS + + A domain-ref must be THE official name of a registry, network, + or host. It is a symbolic reference, within a name sub- + domain. At times, it is necessary to bypass standard mechan- + isms for resolving such references, using more primitive + information, such as a network host address rather than its + associated host name. + + To permit such references, this standard provides the domain- + literal construct. Its contents must conform with the needs + of the sub-domain in which it is interpreted. + + Domain-literals which refer to domains within the ARPA Inter- + net specify 32-bit Internet addresses, in four 8-bit fields + noted in decimal, as described in Request for Comments #820, + "Assigned Numbers." For example: + + [10.0.3.19] + + Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It + is permitted only as a means of bypassing temporary + system limitations, such as name tables which are not + complete. + + The names of "top-level" domains, and the names of domains + under in the ARPA Internet, are registered with the Network + Information Center, SRI International, Menlo Park, California. + + 6.2.4. DOMAIN-DEPENDENT LOCAL STRING + + The local-part of an addr-spec in a mailbox specification + (i.e., the host's name for the mailbox) is understood to be + + + August 13, 1982 - 30 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + whatever the receiving mail protocol server allows. For exam- + ple, some systems do not understand mailbox references of the + form "P. D. Q. Bach", but others do. + + This specification treats periods (".") as lexical separators. + Hence, their presence in local-parts which are not quoted- + strings, is detected. However, such occurrences carry NO + semantics. That is, if a local-part has periods within it, an + address parser will divide the local-part into several tokens, + but the sequence of tokens will be treated as one uninter- + preted unit. The sequence will be re-assembled, when the + address is passed outside of the system such as to a mail pro- + tocol service. + + For example, the address: + + First.Last@Registry.Org + + is legal and does not require the local-part to be surrounded + with quotation-marks. (However, "First Last" DOES require + quoting.) The local-part of the address, when passed outside + of the mail system, within the Registry.Org domain, is + "First.Last", again without quotation marks. + + 6.2.5. BALANCING LOCAL-PART AND DOMAIN + + In some cases, the boundary between local-part and domain can + be flexible. The local-part may be a simple string, which is + used for the final determination of the recipient's mailbox. + All other levels of reference are, therefore, part of the + domain. + + For some systems, in the case of abbreviated reference to the + local and subordinate sub-domains, it may be possible to + specify only one reference within the domain part and place + the other, subordinate name-domain references within the + local-part. This would appear as: + + mailbox.sub1.sub2@this-domain + + Such a specification would be acceptable to address parsers + which conform to RFC #733, but do not support this newer + Internet standard. While contrary to the intent of this stan- + dard, the form is legal. + + Also, some sub-domains have a specification syntax which does + not conform to this standard. For example: + + sub-net.mailbox@sub-domain.domain + + + August 13, 1982 - 31 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + uses a different parsing sequence for local-part than for + domain. + + Note: As a rule, the domain specification should contain + fields which are encoded according to the syntax of + this standard and which contain generally-standardized + information. The local-part specification should con- + tain only that portion of the address which deviates + from the form or intention of the domain field. + + 6.2.6. MULTIPLE MAILBOXES + + An individual may have several mailboxes and wish to receive + mail at whatever mailbox is convenient for the sender to + access. This standard does not provide a means of specifying + "any member of" a list of mailboxes. + + A set of individuals may wish to receive mail as a single unit + (i.e., a distribution list). The construct permits + specification of such a list. Recipient mailboxes are speci- + fied within the bracketed part (":" - ";"). A copy of the + transmitted message is to be sent to each mailbox listed. + This standard does not permit recursive specification of + groups within groups. + + While a list must be named, it is not required that the con- + tents of the list be included. In this case, the
+ serves only as an indication of group distribution and would + appear in the form: + + name:; + + Some mail services may provide a group-list distribution + facility, accepting a single mailbox reference, expanding it + to the full distribution list, and relaying the mail to the + list's members. This standard provides no additional syntax + for indicating such a service. Using the address + alternative, while listing one mailbox in it, can mean either + that the mailbox reference will be expanded to a list or that + there is a group with one member. + + 6.2.7. EXPLICIT PATH SPECIFICATION + + At times, a message originator may wish to indicate the + transmission path that a message should follow. This is + called source routing. The normal addressing scheme, used in + an addr-spec, is carefully separated from such information; + the portion of a route-addr is provided for such occa- + sions. It specifies the sequence of hosts and/or transmission + + + August 13, 1982 - 32 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + services that are to be traversed. Both domain-refs and + domain-literals may be used. + + Note: The use of source routing is discouraged. Unless the + sender has special need of path restriction, the choice + of transmission route should be left to the mail tran- + sport service. + + 6.3. RESERVED ADDRESS + + It often is necessary to send mail to a site, without know- + ing any of its valid addresses. For example, there may be mail + system dysfunctions, or a user may wish to find out a person's + correct address, at that site. + + This standard specifies a single, reserved mailbox address + (local-part) which is to be valid at each site. Mail sent to + that address is to be routed to a person responsible for the + site's mail system or to a person with responsibility for general + site operation. The name of the reserved local-part address is: + + Postmaster + + so that "Postmaster@domain" is required to be valid. + + Note: This reserved local-part must be matched without sensi- + tivity to alphabetic case, so that "POSTMASTER", "postmas- + ter", and even "poStmASteR" is to be accepted. + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 33 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 7. BIBLIOGRAPHY + + + ANSI. "USA Standard Code for Information Interchange," X3.4. + American National Standards Institute: New York (1968). Also + in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand- + book", NIC 7104. + + ANSI. "Representations of Universal Time, Local Time Differen- + tials, and United States Time Zone References for Information + Interchange," X3.51-1975. American National Standards Insti- + tute: New York (1975). + + Bemer, R.W., "Time and the Computer." In: Interface Age (Feb. + 1979). + + Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Ruther- + ford and Appleton Laboratory: Didcot, England. + + Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E. + "Standardizing Network Mail Headers," ARPANET Request for + Comments No. 561, Network Information Center No. 18516; SRI + International: Menlo Park (September 1973). + + Birrell, A.D., Levin, R., Needham, R.M., and Schroeder, M.D. + "Grapevine: An Exercise in Distributed Computing," Communica- + tions of the ACM 25, 4 (April 1982), 260-274. + + Crocker, D.H., Vittal, J.J., Pogran, K.T., Henderson, D.A. + "Standard for the Format of ARPA Network Text Message," + ARPANET Request for Comments No. 733, Network Information + Center No. 41952. SRI International: Menlo Park (November + 1977). + + Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook, Net- + work Information Center No. 7104 (NTIS AD A003890). SRI + International: Menlo Park (April 1976). + + Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass. + (1969). + + Levin, R. and Schroeder, M. "Transport of Electronic Messages + through a Network," TeleInformatics 79, pp. 29-33. North + Holland (1979). Also as Xerox Palo Alto Research Center + Technical Report CSL-79-4. + + Myer, T.H. and Henderson, D.A. "Message Transmission Protocol," + ARPANET Request for Comments, No. 680, Network Information + Center No. 32116. SRI International: Menlo Park (1975). + + + August 13, 1982 - 34 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + NBS. "Specification of Message Format for Computer Based Message + Systems, Recommended Federal Information Processing Standard." + National Bureau of Standards: Gaithersburg, Maryland + (October 1981). + + NIC. Internet Protocol Transition Workbook. Network Information + Center, SRI-International, Menlo Park, California (March + 1982). + + Oppen, D.C. and Dalal, Y.K. "The Clearinghouse: A Decentralized + Agent for Locating Named Objects in a Distributed Environ- + ment," OPD-T8103. Xerox Office Products Division: Palo Alto, + CA. (October 1981). + + Postel, J.B. "Assigned Numbers," ARPANET Request for Comments, + No. 820. SRI International: Menlo Park (August 1982). + + Postel, J.B. "Simple Mail Transfer Protocol," ARPANET Request + for Comments, No. 821. SRI International: Menlo Park (August + 1982). + + Shoch, J.F. "Internetwork naming, addressing and routing," in + Proc. 17th IEEE Computer Society International Conference, pp. + 72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C. + + Su, Z. and Postel, J. "The Domain Naming Convention for Internet + User Applications," ARPANET Request for Comments, No. 819. + SRI International: Menlo Park (August 1982). + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 35 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + APPENDIX + + + A. EXAMPLES + + A.1. ADDRESSES + + A.1.1. Alfred Neuman + + A.1.2. Neuman@BBN-TENEXA + + These two "Alfred Neuman" examples have identical seman- + tics, as far as the operation of the local host's mail sending + (distribution) program (also sometimes called its "mailer") + and the remote host's mail protocol server are concerned. In + the first example, the "Alfred Neuman" is ignored by the + mailer, as "Neuman@BBN-TENEXA" completely specifies the reci- + pient. The second example contains no superfluous informa- + tion, and, again, "Neuman@BBN-TENEXA" is the intended reci- + pient. + + Note: When the message crosses name-domain boundaries, then + these specifications must be changed, so as to indicate + the remainder of the hierarchy, starting with the top + level. + + A.1.3. "George, Ted" + + This form might be used to indicate that a single mailbox + is shared by several users. The quoted string is ignored by + the originating host's mailer, because "Shared@Group.Arpanet" + completely specifies the destination mailbox. + + A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US + + The "(the Stilt)" is a comment, which is NOT included in + the destination mailbox address handed to the originating + system's mailer. The local-part of the address is the string + "Wilt.Chamberlain", with NO space between the first and second + words. + + A.1.5. Address Lists + + Gourmets: Pompous Person , + Childs@WGBH.Boston, Galloping Gourmet@ + ANT.Down-Under (Australian National Television), + Cheapie@Discount-Liquors;, + Cruisers: Port@Portugal, Jones@SEA;, + Another@Somewhere.SomeOrg + + + August 13, 1982 - 36 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + This group list example points out the use of comments and the + mixing of addresses and groups. + + A.2. ORIGINATOR ITEMS + + A.2.1. Author-sent + + George Jones logs into his host as "Jones". He sends + mail himself. + + From: Jones@Group.Org + + or + + From: George Jones + + A.2.2. Secretary-sent + + George Jones logs in as Jones on his host. His secre- + tary, who logs in as Secy sends mail for him. Replies to the + mail should go to George. + + From: George Jones + Sender: Secy@Other-Group + + A.2.3. Secretary-sent, for user of shared directory + + George Jones' secretary sends mail for George. Replies + should go to George. + + From: George Jones + Sender: Secy@Other-Group + + Note that there need not be a space between "Jones" and the + "<", but adding a space enhances readability (as is the case + in other examples. + + A.2.4. Committee activity, with one author + + George is a member of a committee. He wishes to have any + replies to his message go to all committee members. + + From: George Jones + Sender: Jones@Host + Reply-To: The Committee: Jones@Host.Net, + Smith@Other.Org, + Doe@Somewhere-Else; + + Note that if George had not included himself in the + + + August 13, 1982 - 37 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + enumeration of The Committee, he would not have gotten an + implicit reply; the presence of the "Reply-to" field SUPER- + SEDES the sending of a reply to the person named in the "From" + field. + + A.2.5. Secretary acting as full agent of author + + George Jones asks his secretary (Secy@Host) to send a + message for him in his capacity as Group. He wants his secre- + tary to handle all replies. + + From: George Jones + Sender: Secy@Host + Reply-To: Secy@Host + + A.2.6. Agent for user without online mailbox + + A friend of George's, Sarah, is visiting. George's + secretary sends some mail to a friend of Sarah in computer- + land. Replies should go to George, whose mailbox is Jones at + Registry. + + From: Sarah Friendly + Sender: Secy-Name + Reply-To: Jones@Registry. + + A.2.7. Agent for member of a committee + + George's secretary sends out a message which was authored + jointly by all the members of a committee. Note that the name + of the committee cannot be specified, since names are + not permitted in the From field. + + From: Jones@Host, + Smith@Other-Host, + Doe@Somewhere-Else + Sender: Secy@SHost + + + + + + + + + + + + + + + August 13, 1982 - 38 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + A.3. COMPLETE HEADERS + + A.3.1. Minimum required + + Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT + From: Jones@Registry.Org or From: Jones@Registry.Org + Bcc: To: Smith@Registry.Org + + Note that the "Bcc" field may be empty, while the "To" field + is required to have at least one address. + + A.3.2. Using some of the additional fields + + Date: 26 Aug 76 1430 EDT + From: George Jones + Sender: Secy@SHOST + To: "Al Neuman"@Mad-Host, + Sam.Irving@Other-Host + Message-ID: + + A.3.3. About as complex as you're going to get + + Date : 27 Aug 76 0932 PDT + From : Ken Davis + Subject : Re: The Syntax in the RFC + Sender : KSecy@Other-Host + Reply-To : Sam.Irving@Reg.Organization + To : George Jones , + Al.Neuman@MAD.Publisher + cc : Important folk: + Tom Softwood , + "Sam Irving"@Other-Host;, + Standard Distribution: + /main/davis/people/standard@Other-Host, + "standard.dist.3"@Tops-20-Host>; + Comment : Sam is away on business. He asked me to handle + his mail for him. He'll be able to provide a + more accurate explanation when he returns + next week. + In-Reply-To: , George's message + X-Special-action: This is a sample of user-defined field- + names. There could also be a field-name + "Special-action", but its name might later be + preempted + Message-ID: <4231.629.XYzi-What@Other-Host> + + + + + + + August 13, 1982 - 39 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + B. SIMPLE FIELD PARSING + + Some mail-reading software systems may wish to perform only + minimal processing, ignoring the internal syntax of structured + field-bodies and treating them the same as unstructured-field- + bodies. Such software will need only to distinguish: + + o Header fields from the message body, + + o Beginnings of fields from lines which continue fields, + + o Field-names from field-contents. + + The abbreviated set of syntactic rules which follows will + suffice for this purpose. It describes a limited view of mes- + sages and is a subset of the syntactic rules provided in the main + part of this specification. One small exception is that the con- + tents of field-bodies consist only of text: + + B.1. SYNTAX + + + message = *field *(CRLF *text) + + field = field-name ":" [field-body] CRLF + + field-name = 1* + + field-body = *text [CRLF LWSP-char field-body] + + + B.2. SEMANTICS + + Headers occur before the message body and are terminated by + a null line (i.e., two contiguous CRLFs). + + A line which continues a header field begins with a SPACE or + HTAB character, while a line beginning a field starts with a + printable character which is not a colon. + + A field-name consists of one or more printable characters + (excluding colon, space, and control-characters). A field-name + MUST be contained on one line. Upper and lower case are not dis- + tinguished when comparing field-names. + + + + + + + + August 13, 1982 - 40 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C. DIFFERENCES FROM RFC #733 + + The following summarizes the differences between this stan- + dard and the one specified in Arpanet Request for Comments #733, + "Standard for the Format of ARPA Network Text Messages". The + differences are listed in the order of their occurrence in the + current specification. + + C.1. FIELD DEFINITIONS + + C.1.1. FIELD NAMES + + These now must be a sequence of printable characters. They + may not contain any LWSP-chars. + + C.2. LEXICAL TOKENS + + C.2.1. SPECIALS + + The characters period ("."), left-square bracket ("["), and + right-square bracket ("]") have been added. For presentation + purposes, and when passing a specification to a system that + does not conform to this standard, periods are to be contigu- + ous with their surrounding lexical tokens. No linear-white- + space is permitted between them. The presence of one LWSP- + char between other tokens is still directed. + + C.2.2. ATOM + + Atoms may not contain SPACE. + + C.2.3. SPECIAL TEXT + + ctext and qtext have had backslash ("\") added to the list of + prohibited characters. + + C.2.4. DOMAINS + + The lexical tokens and have been + added. + + C.3. MESSAGE SPECIFICATION + + C.3.1. TRACE + + The "Return-path:" and "Received:" fields have been specified. + + + + + + August 13, 1982 - 41 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C.3.2. FROM + + The "From" field must contain machine-usable addresses (addr- + spec). Multiple addresses may be specified, but named-lists + (groups) may not. + + C.3.3. RESENT + + The meta-construct of prefacing field names with the string + "Resent-" has been added, to indicate that a message has been + forwarded by an intermediate recipient. + + C.3.4. DESTINATION + + A message must contain at least one destination address field. + "To" and "CC" are required to contain at least one address. + + C.3.5. IN-REPLY-TO + + The field-body is no longer a comma-separated list, although a + sequence is still permitted. + + C.3.6. REFERENCE + + The field-body is no longer a comma-separated list, although a + sequence is still permitted. + + C.3.7. ENCRYPTED + + A field has been specified that permits senders to indicate + that the body of a message has been encrypted. + + C.3.8. EXTENSION-FIELD + + Extension fields are prohibited from beginning with the char- + acters "X-". + + C.4. DATE AND TIME SPECIFICATION + + C.4.1. SIMPLIFICATION + + Fewer optional forms are permitted and the list of three- + letter time zones has been shortened. + + C.5. ADDRESS SPECIFICATION + + + + + + + August 13, 1982 - 42 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C.5.1. ADDRESS + + The use of quoted-string, and the ":"-atom-":" construct, have + been removed. An address now is either a single mailbox + reference or is a named list of addresses. The latter indi- + cates a group distribution. + + C.5.2. GROUPS + + Group lists are now required to to have a name. Group lists + may not be nested. + + C.5.3. MAILBOX + + A mailbox specification may indicate a person's name, as + before. Such a named list no longer may specify multiple + mailboxes and may not be nested. + + C.5.4. ROUTE ADDRESSING + + Addresses now are taken to be absolute, global specifications, + independent of transmission paths. The construct has + been provided, to permit explicit specification of transmis- + sion path. RFC #733's use of multiple at-signs ("@") was + intended as a general syntax for indicating routing and/or + hierarchical addressing. The current standard separates these + specifications and only one at-sign is permitted. + + C.5.5. AT-SIGN + + The string " at " no longer is used as an address delimiter. + Only at-sign ("@") serves the function. + + C.5.6. DOMAINS + + Hierarchical, logical name-domains have been added. + + C.6. RESERVED ADDRESS + + The local-part "Postmaster" has been reserved, so that users can + be guaranteed at least one valid address at a site. + + + + + + + + + + + August 13, 1982 - 43 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + D. ALPHABETICAL LISTING OF SYNTAX RULES + + address = mailbox ; one addressee + / group ; named list + addr-spec = local-part "@" domain ; global address + ALPHA = + ; (101-132, 65.- 90.) + ; (141-172, 97.-122.) + atom = 1* + authentic = "From" ":" mailbox ; Single author + / ( "Sender" ":" mailbox ; Actual submittor + "From" ":" 1#mailbox) ; Multiple authors + ; or not sender + CHAR = ; ( 0-177, 0.-127.) + comment = "(" *(ctext / quoted-pair / comment) ")" + CR = ; ( 15, 13.) + CRLF = CR LF + ctext = may be folded + ")", "\" & CR, & including + linear-white-space> + CTL = ; ( 177, 127.) + date = 1*2DIGIT month 2DIGIT ; day month year + ; e.g. 20 Jun 82 + dates = orig-date ; Original + [ resent-date ] ; Forwarded + date-time = [ day "," ] date time ; dd mm yy + ; hh:mm:ss zzz + day = "Mon" / "Tue" / "Wed" / "Thu" + / "Fri" / "Sat" / "Sun" + delimiters = specials / linear-white-space / comment + destination = "To" ":" 1#address ; Primary + / "Resent-To" ":" 1#address + / "cc" ":" 1#address ; Secondary + / "Resent-cc" ":" 1#address + / "bcc" ":" #address ; Blind carbon + / "Resent-bcc" ":" #address + DIGIT = ; ( 60- 71, 48.- 57.) + domain = sub-domain *("." sub-domain) + domain-literal = "[" *(dtext / quoted-pair) "]" + domain-ref = atom ; symbolic reference + dtext = may be folded + "]", "\" & CR, & including + linear-white-space> + extension-field = + + + + August 13, 1982 - 44 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + field = field-name ":" [ field-body ] CRLF + fields = dates ; Creation time, + source ; author id & one + 1*destination ; address required + *optional-field ; others optional + field-body = field-body-contents + [CRLF LWSP-char field-body] + field-body-contents = + + field-name = 1* + group = phrase ":" [#mailbox] ";" + hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] + ; 00:00:00 - 23:59:59 + HTAB = ; ( 11, 9.) + LF = ; ( 12, 10.) + linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE + ; CRLF => folding + local-part = word *("." word) ; uninterpreted + ; case-preserved + LWSP-char = SPACE / HTAB ; semantics = SPACE + mailbox = addr-spec ; simple address + / phrase route-addr ; name & addr-spec + message = fields *( CRLF *text ) ; Everything after + ; first null line + ; is message body + month = "Jan" / "Feb" / "Mar" / "Apr" + / "May" / "Jun" / "Jul" / "Aug" + / "Sep" / "Oct" / "Nov" / "Dec" + msg-id = "<" addr-spec ">" ; Unique message id + optional-field = + / "Message-ID" ":" msg-id + / "Resent-Message-ID" ":" msg-id + / "In-Reply-To" ":" *(phrase / msg-id) + / "References" ":" *(phrase / msg-id) + / "Keywords" ":" #phrase + / "Subject" ":" *text + / "Comments" ":" *text + / "Encrypted" ":" 1#2word + / extension-field ; To be defined + / user-defined-field ; May be pre-empted + orig-date = "Date" ":" date-time + originator = authentic ; authenticated addr + [ "Reply-To" ":" 1#address] ) + phrase = 1*word ; Sequence of words + + + + + August 13, 1982 - 45 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + qtext = , ; => may be folded + "\" & CR, and including + linear-white-space> + quoted-pair = "\" CHAR ; may quote any char + quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or + ; quoted chars. + received = "Received" ":" ; one per relay + ["from" domain] ; sending host + ["by" domain] ; receiving host + ["via" atom] ; physical path + *("with" atom) ; link/mail protocol + ["id" msg-id] ; receiver msg id + ["for" addr-spec] ; initial form + ";" date-time ; time received + + resent = resent-authentic + [ "Resent-Reply-To" ":" 1#address] ) + resent-authentic = + = "Resent-From" ":" mailbox + / ( "Resent-Sender" ":" mailbox + "Resent-From" ":" 1#mailbox ) + resent-date = "Resent-Date" ":" date-time + return = "Return-path" ":" route-addr ; return address + route = 1#("@" domain) ":" ; path-relative + route-addr = "<" [route] addr-spec ">" + source = [ trace ] ; net traversals + originator ; original mail + [ resent ] ; forwarded + SPACE = ; ( 40, 32.) + specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- + / "," / ";" / ":" / "\" / <"> ; string, to use + / "." / "[" / "]" ; within a word. + sub-domain = domain-ref / domain-literal + text = atoms, specials, + CR & bare LF, but NOT ; comments and + including CRLF> ; quoted-strings are + ; NOT recognized. + time = hour zone ; ANSI and Military + trace = return ; path to sender + 1*received ; receipt tags + user-defined-field = + + word = atom / quoted-string + + + + + August 13, 1982 - 46 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + zone = "UT" / "GMT" ; Universal Time + ; North American : UT + / "EST" / "EDT" ; Eastern: - 5/ - 4 + / "CST" / "CDT" ; Central: - 6/ - 5 + / "MST" / "MDT" ; Mountain: - 7/ - 6 + / "PST" / "PDT" ; Pacific: - 8/ - 7 + / 1ALPHA ; Military: Z = UT; + <"> = ; ( 42, 34.) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 47 - RFC #822 + diff --git a/RFC/rfc937.txt b/RFC/rfc937.txt new file mode 100644 index 00000000..ae154ea8 --- /dev/null +++ b/RFC/rfc937.txt @@ -0,0 +1,1392 @@ + + +Network Working Group M. Butler +Request for Comments: 937 J. Postel + D. Chase + J. Goldberger + J. K. Reynolds +Obsoletes: RFC 918 ISI + February 1985 + + + POST OFFICE PROTOCOL - VERSION 2 + + +Status of this Memo + + This RFC suggests a simple method for workstations to dynamically + access mail from a mailbox server. This RFC specifies a proposed + protocol for the ARPA-Internet community, and requests discussion and + suggestions for improvement. This memo is a revision of RFC 918. + Distribution of this memo is unlimited. + +Introduction + + The intent of the Post Office Protocol Version 2 (POP2) is to allow a + user's workstation to access mail from a mailbox server. It is + expected that mail will be posted from the workstation to the mailbox + server via the Simple Mail Transfer Protocol (SMTP). For further + information see RFC-821 [1] and RFC-822 [2]. + + This protocol assumes a reliable data stream such as provided by TCP + or any similar protocol. When TCP is used, the POP2 server listens + on port 109 [4]. + +System Model and Philosophy + + While we view the workstation as an Internet host in the sense that + it implements IP, we do not expect the workstation to contain the + user's mailbox. We expect the mailbox to be on a server machine. + + We believe it is important for the mailbox to be on an "always up" + machine and that a workstation may be frequently powered down, or + otherwise unavailable as an SMTP server. + + POP2 is designed for an environment of workstations and servers on a + low-delay, high-throughput, local networks (such as Ethernets). POP2 + may be useful in other environments as well, but if the environment + is substantially different, a different division of labor between the + client and server may be appropriate, and a different protocol + required. + + Suppose the user's real name is John Smith, the user's machine is + called FIDO, and that the mailbox server is called DOG-HOUSE. Then + + + +Butler, et. al. [Page 1] + + + +RFC 937 February 1985 +Post Office Protocol + + + we expect the user's mail to be addressed to JSmith@DOG-HOUSE.ARPA + (not JSmith@FIDO.ARPA). + + That is, the destination of the mail is the mailbox on the server + machine. The POP2 protocol and the workstation are merely a + mechanism for viewing the messages in the mailbox. + + The user is not tied to any particular workstation for accessing his + mail. The workstation does not appear as any part of the mailbox + address. + + This is a very simple protocol. This is not a user interface. We + expect that there is a program in the workstation that is friendly to + the user. This protocol is not "user friendly". One basic rule of + this protocol is "if anything goes wrong close the connection". + Another basic rule is to have few options. + + POP2 does not parse messages in any way. It does not analyze message + headers (Date:, From:, To:, Cc:, or Subject:). POP2 simply transmits + whole messages from a mailbox server to a client workstation. + +The Protocol + + The POP2 protocol is a sequence of commands and replies. The design + draws from many previous protocols of the ARPA-Internet community. + + The server must be listening for a connection. When a connection + is opened the server sends a greeting message and waits for + commands. When commands are received the server acts on them and + responds with replies. + + The client opens a connection, waits for the greeting, then sends + the HELO command with the user name and password arguments to + establish authorization to access mailboxes. The server returns + the number of messages in the default mailbox. + + The client may read the default mailbox associated with the user + name or may select another mailbox by using the FOLD command. The + server returns the number of messages in the mailbox selected. + + The client begins a message reading transaction with a READ + command. The read command may optionally indicate which message + number to read, the default is the current message (incremented + when a message is read and set to one when a new folder is + selected). The server returns the number of characters in the + message. + + + + +Butler, et. al. [Page 2] + + + +RFC 937 February 1985 +Post Office Protocol + + + The client asks for the content of the message to be sent with the + RETR command. The server sends the message data. + + When all the data has been received the client sends an + acknowledgment command. This is one of ACKS, ACKD, and NACK. + + ACKS means "I've received the message successfully and please + keep it in the mailbox". + + ACKD means "I've received the message successfully and please + delete it from the mailbox". + + NACK means "I did not receive the message and please keep it in + the mailbox". + + In the case of ACKS or ACKD the server increments the current + message indicator. In the case of NACK the current message + indicator stays the same. + + In all cases the server returns the number of characters in the + (now) current message. + + The client terminates the session with the QUIT command. The + server returns an ok. + + + + + + + + + + + + + + + + + + + + + + + + + + +Butler, et. al. [Page 3] + + + +RFC 937 February 1985 +Post Office Protocol + + + The Normal Scenario + + Client Server + ------ ------ + Wait for Connection + Open Connection --> + <-- + POP2 Server Ready + Wait for Command + HELO Fred Secret --> + <-- #13 messages for you + Wait for Command + READ 13 --> + <-- =537 characters in that message + Wait for Command + RETR --> + <-- (send the message data) + Wait for Command + ACKS --> + <-- =0 no more messages + Wait for Command + QUIT --> + <-- + OK + Close connection --> <-- Close connection + Wait for Connection (go back to start) + +Conventions + + Arguments + + These arguments have system specific definitions. + + user - A login account name. + + password - The password for the login account. + + mailbox - A mailbox name (also called a mail folder). + + + + + + + + + + + + + + +Butler, et. al. [Page 4] + + + +RFC 937 February 1985 +Post Office Protocol + + + Default Mailboxes + + TOPS-20 + + MAIL.TXT.1 - from login directory + + UNIX + + both + /usr/spool/mail/user + and + /usr/user/Mail/inbox/* + + where "user" is the user value supplied in the HELO command. + + End of Line + + End of Line is Carriage Return (CR) followed by Line Feed (LF). + This sequence is indicated by "CRLF" in this document. This end + of line convention must be used for commands and replies. + + Message Length + + The reply to the READ command or an acknowledgment command (ACKS, + ACKD, NACK) is the length (a character count) of the next message + to be transmitted. This includes all the characters in the data + transmitted. CRLF counts as two characters. A length of zero + means the message does not exist or is empty. A request to + transmit a message of zero length will result in the server + closing the connection. The message is transmitted in the + standard internet format described in RFC-822 [2] and NVT-ASCII. + This may be different from the storage format and may make + computing the message length from the stored message non-trivial. + + Message Numbers + + The reply to the HELO and FOLD commands is a count of the number + of messages in a the selected mailbox. The READ command has a + message number as an optional argument. These numbers are + decimal, start at one, and computed with respect to the current + mailbox. That is, the first message in a mailbox is message + number 1. + + Numbers + + All numbers in this memo and protocol are decimal. + + + + +Butler, et. al. [Page 5] + + + +RFC 937 February 1985 +Post Office Protocol + + + Quoting + + In a few cases, there may be a need to have a special character in + an argument (user, password, or mailbox) that is not allowed by + the syntax. For example, a space in a password. To allow for + this, a quoting convention is defined. Unfortunately, such + quoting conventions "use up" another otherwise uninteresting + character. In this protocol the back slash "\" is used as the + quote character. To include a space in an argument the two + character sequence "back-slash, space" is transmitted. To include + a back-slash in an argument the two character sequence + "back-slash, back-slash" is transmitted. This quoting convention + is used in the command arguments only, it is not used in the mail + data transmitted in response to a RETR command. + + Reply Strings + + The first character is required to be as specified (i.e., + "+", "-", "=", "#"). The optional strings that follow can be + whatever the implementer thinks is appropriate. + +Definitions of Commands and Replies + + Summary of Commands and Replies + + Commands Replies + -------- ------- + HELO user password + OK + FOLD mailbox - Error + READ [n] #xxx + RETR =yyy + ACKS + ACKD + NACK + QUIT + + + + + + + + + + + + + + + +Butler, et. al. [Page 6] + + + +RFC 937 February 1985 +Post Office Protocol + + + Commands + + HELO user password + + The Hello command identifies the user to the server and carries + the password authenticating this user. This information is + used by the server to control access to the mailboxes. The + Hello command is the "HELO" keyword, followed by the user + argument, followed by the password argument, followed by CRLF. + + Possible responses: + + "#nnn" + + where nnn is the number of messages in the default + mailbox," + + "- error report" and Close the connection. + + FOLD mailbox + + The Folder command selects another mailbox or mail folder. The + server must check that the user is permitted read access to + this mailbox. If the mailbox is empty or does not exist, the + number of messages reported is zero. The Folder command is the + "FOLD" keyword, followed by the mailbox argument, followed by + CRLF. + + Possible responses: + + "#nnn" + + where nnn is the number of messages in this mailbox. + + READ [nnn] + + The Read command begins a message reading transaction. If the + Read command is given without an argument the current message + is implied (the current message indicator is incremented by + the ACKS or ACKD commands). If an argument is used with the + Read command it is the message number to be read, and this + command sets the current message indicator to that value. The + server returns the count of characters in the message to be + transmitted. If there is no message to be read, the count of + zero is returned. If the message was previously deleted with + the ACKD command, the count of zero is returned. The Read + command is followed by the RETR command, the READ command, the + FOLD command, or the QUIT command. Do not attempt to RETR a + + +Butler, et. al. [Page 7] + + + +RFC 937 February 1985 +Post Office Protocol + + + message of zero characters. The Read command is the "READ" + keyword, optionally followed by the message number argument, + followed by CRLF. + + Possible responses: + + "=ccc" + + where ccc is the number of characters in this message. + + RETR + + The Retrieve command confirms that the client is ready to + receive the mail data. It must be followed by an + acknowledgment command. The server will close the connection + if asked to transmit a message of zero characters (i.e., + transmit a non-existent message). The message is transmitted + according to the Internet mail format standard RFC-822 [2] in + NVT-ASCII. The Retrieve command is the "RETR" keyword, + followed by CRLF. + + Possible responses: + + the message data + + Close the connection + + ACKS + + The Acknowledge and Save command confirms that the client has + received and accepted the message. The ACKS command ends the + message reading transaction. The message is kept in the + mailbox. The current message indicator is incremented. The + server returns the count of characters in the now current + message to be transmitted. If there is no message to be read + or the message is marked deleted, the count of zero is + returned. The Acknowledge and Save command is the "ACKS" + keyword, followed by CRLF. + + Possible responses: + + "=ccc" + + where ccc is the number of characters in the next + message. + + + + + +Butler, et. al. [Page 8] + + + +RFC 937 February 1985 +Post Office Protocol + + + ACKD + + The Acknowledge and Delete command confirms that the client has + received and accepted the message. The ACKD command ends the + message reading transaction. If the user is authorized to have + write access to the mailbox, the message is deleted from the + mailbox. Actually, the message is only marked for deletion. + The actual change is made when the mailbox is released at the + end of the session or when the client selects another mailbox + with the FOLD command. The messages are not renumbered until + the mailbox is released. If the user does not have write + access to the mailbox no change is made to the mailbox. The + response is the same whether or not the message was actually + deleted. The current message indicator is incremented. The + server returns the count of characters in the now current + message to be transmitted. If there is no message to be read + or the message is marked deleted, the count of zero is + returned. The Acknowledge and Delete command is the "ACKD" + keyword, followed by CRLF. + + Possible responses: + + "=ccc" + + where ccc is the number of characters in the next + message. + + NACK + + The Negative Acknowledge command reports that the client did + not receive the message. The NACK command ends the message + reading transaction. The message is kept in the mailbox. The + current message indicator remains the same. The server returns + the count of characters in the current message. Since the + count to be returned is for the message just transmitted it the + message must exist and not be marked deleted, and the count + must be positive (non-zero). The Negative Acknowledge command + is the "NACK" keyword, followed by CRLF. + + Possible responses: + + "=ccc" + + where ccc is the number of characters in this message. + + + + + + +Butler, et. al. [Page 9] + + + +RFC 937 February 1985 +Post Office Protocol + + + QUIT + + The Quit command indicates the client is done with the session. + The server sends an OK response and then closes the connection. + The Quit command is the "QUIT" keyword, followed by CRLF. + + Possible responses: + + "+ OK" and Close the connection + + Replies + + Greeting + + The greeting is sent by the server as soon as the connection is + established. The greeting is a plus sign, followed by the + protocol name ("POP2"), followed by the server host name, + optionally followed by text, and ending with a CRLF. + + + + + The success or plus sign response indicates successful + completion of the operation specified in the command. The + success response is a plus sign, optionally followed by text, + and ending with a CRLF. + + - + + The failure or minus sign response indicates the failure of the + operation specified in the command. The failure response is a + minus sign, optionally followed by text, and ending with a + CRLF. + + = + + The length or equal sign response tells the length in + characters of the message referenced by the command. The + length response is a equal sign, followed by a number, + optionally followed by text, and ending with a CRLF. + + # + + The count or number sign response tells the number of messages + in a folder or mailbox referenced by the command. The count + response is a number sign, followed by a number, optionally + followed by text, and ending with a CRLF. + + + + +Butler, et. al. [Page 10] + + + +RFC 937 February 1985 +Post Office Protocol + + + Timeouts + + In any protocol of this type there have to be timeouts. Neither + side wants to get stuck waiting forever for the other side + (particularly is the other side has gone crazy or crashed). + + The client expects a reply to a command fairly quickly and so + should have a short timeout for this. This timeout is called T1. + + For some servers, it may take some processing to compute the + number of messages in a mailbox, or the length of a message, or + to reformat a stored message for transmission, so this time out + has to allow for such processing time. Also care must be taken + not to timeout waiting for the completion of a RETR reply while + a long message is in fact being transfered. + + The server expects the session to progress with some but not + excessive delay between commands and so should have a long timeout + waiting for the next command. This time out is T2. + + One model of use of this protocol is that any number of + different types of clients can be built with different ways of + interacting with the human user and the server, but still + expecting the client to open the connection to the server, + present a sequence of commands, and close the connection, + without waiting for intervention by the human user. With such + client implementations, it is reasonable for the server to have + a fairly small value for timeout T2. + + On the other hand, one could easily have the client be very + human user directed with the user making decisions between + commands. This would cause arbitrary delays between client + commands to the server, and require the value of timeout T2 to + be quite large. + +Implementation Discussion + + Comments on a Server on TOPS-20 + + On TOPS-20, a mailbox is a single file. New messages are appended + to the file. There is a separator line between messages. + + The tricky part of implementing a POP2 server on TOPS-20 is to + provide for deleting messages. This only has to be done for the + mailboxes (files) for which the user has write access. The + problem is to avoid both (1) preventing other users from accessing + or updating the mailbox for long periods, and (2) accidentally + deleting a message the user has not seen. + + +Butler, et. al. [Page 11] + + + +RFC 937 February 1985 +Post Office Protocol + + + One suggestion is as follows: + + When a mailbox is first selected, if the user has write access, + rename the mailbox file to some temporary name. Thus new + messages will be placed in a new instance of the mailbox file. + Conduct all POP2 operation on the temporary mailbox file + (including deleting messages). When the POP2 session is over + or another mailbox is selected, prepend any messages left + undeleted in the temporary file to the new instance of the + mailbox file. + + Sizes + + The maximum length of a command line is 512 characters (including + the command word and the CRLF). + + The maximum length of a reply line is 512 characters (including + the success indicator (+, -, =, #) and the CRLF). + + The maximum length of a text line is 1000 characters (including + CRLF). + + ISI has developed a POP2 server for TOPS-20 and for Berkeley 4.2 + Unix, and a POP2 client for an IBM-PC and for Berkeley 4.2 Unix. + +Extensions Not Supported + + POP2 does not examine the internal data of messages. In particular, + the server does not parse message headers. + + The server doesn't have any state information (i.e., it doesn't know + from one session to the next what has happened). For example, the + server doesn't know which messages were received since the last time + the user used POP2, so it can't send just the "new" messages. + + + + + + + + + + + + + + + + +Butler, et. al. [Page 12] + + + +RFC 937 February 1985 +Post Office Protocol + + +Examples + + Example 1: + + Client Server + ------ ------ + Wait for connection + Open connection --> + <-- + POP2 USC-ISIF.ARPA Server + HELO POSTEL SECRET --> + <-- #2 messages in your mailbox + READ --> + <-- =537 characters in message 1 + RETR --> + <-- [data of message 1] + ACKD --> + <-- =234 characters in message 2 + RETR --> + <-- [data of message 2] + ACKD --> + <-- =0 no more messages + QUIT --> + <-- + OK, bye, bye + Close connection --> <-- Close connection + Go back to start + + + + + + + + + + + + + + + + + + + + + + + + + +Butler, et. al. [Page 13] + + + +RFC 937 February 1985 +Post Office Protocol + + + Example 2: + + Client Server + ------ ------ + Wait for connection + Open connection --> + <-- + POP2 ISI-VAXA.ARPA server here + HELO smith secret --> + <-- #35 messages + FOLD /usr/spool/mail/smith --> + <-- #27 messages + READ 27 --> + <-- =10123 characters in that message + RETR --> + <-- [data of message 27] + ACKS --> + <-- =0 no more messages + QUIT --> + <-- + bye, call again sometime. + Close connection --> <-- Close connection + Go back to start + + Example 3: + + Client Server + ------ ------ + Wait for connection + Open connection --> + <-- + POP2 ISI-VAXA.ARPA server here + HELO Jones secret --> + <-- #0 messages + READ --> + <-- Close connection + Close connection --> + Go back to start + + + + + + + + + + + + + + + +Butler, et. al. [Page 14] + + + +RFC 937 February 1985 +Post Office Protocol + + +Formal Syntax + + = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 + + = A | B | C | ... | Z + a | b | c | ... | z + + = ! | " | # | $ | % | & | ' | ( | ) | * | + + | , | - | / | : | < | = | > | ? | @ | + [ | ] | ^ | _ | ` | { | | | } | ~ + + = \ + + = any one of the 128 ASCII codes + + = carriage return, code 10 + + = line feed, code 13 + + = space, code 32 + + = + + = | | | + + = | + + = | + + = | + + = | + + = | | - + + = | + + = [ [ ] ] + + = | . + + = + + = + + = + + = | + + +Butler, et. al. [Page 15] + + + +RFC 937 February 1985 +Post Office Protocol + + + = HELO + + = FOLD + + = READ [ ] + + = RETR + + = ACKS + + = ACKD + + = NACK + + = QUIT + + = + [ ] + + = - [ ] + + = # [ ] + + = + POP2 [ ] + + = = [ ] + + = | | | | + | | | + + = | | | | + + + + + + + + + + + + + + + + + + + + +Butler, et. al. [Page 16] + + + +RFC 937 February 1985 +Post Office Protocol + + +Client State Diagram + + + | ^ + BYE + | Open | ----- + | Greet | Close + V ----- | + +-------+ QUIT +-------+ + | CALL |-------------->| EXIT | + +-------+ +-------+ + | ^ + | Greet | + | ----- | + | HELO | + +---->+ | | + #NNN ^ | | #NNN | + ---- | V V ---- | + FOLD | +-------+ QUIT | + +<---| NMBR |--------------------->+ + +-------+ ^ + ^ | | + | | #NNN | + | | ---- | + =CCC | | READ | + ---- | | | + FOLD | | =CCC | + | V ---- | + =CCC +--->+-------+ QUIT | + ---- ^ | SIZE |--------------------->+ + READ +<---+-------+ + ^ | + | | =CCC + data | | ---- + ---- | | RETR + ack | | + | V + +-------+ + | XFER | + +-------+ + + + + + + + + + + + +Butler, et. al. [Page 17] + + + +RFC 937 February 1985 +Post Office Protocol + + +Server State Diagram + + + +<----------------------+ Close + | | ----- + Listen | | Close + V | + +-------+ +-------+ + | LSTN | | DONE | + +-------+ +-------+ + | ^ + | Open | + | ----- | + | Greet | + | | + | QUIT | + V ----- | + +-------+ + BYE | + | AUTH |--------------------->+ + +-------+ ^ + | | + | HELO | + | ---- | + | #NNN | + | | + | QUIT | + V ----- | + FOLD +--->+-------+ + BYE | + ---- ^ | MBOX |--------------------->+ + #NNN +<---+-------+ ^ + ^ | | + | | READ | + FOLD | | ---- | + ---- | | =CCC | + #NNN | | QUIT | + | V ----- | + READ +--->+-------+ + BYE | + ---- ^ | ITEM |--------------------->+ + =CCC +<---+-------+ + ^ | + | | RETR + ack | | ---- + ---- | | data + =CCC | | + | V + +-------+ + | NEXT | + +-------+ + + +Butler, et. al. [Page 18] + + + +RFC 937 February 1985 +Post Office Protocol + + +Combined Flow Diagram + + + +----+ + |CALL|<------------------------------------------------------------+ + |LSTN| ^ + +----+ | + | Greet | + | | + | +----------------------------------------------------->+ | + | ^ QUIT | | + V | V | + +----+ +----+ +----+ | + |CALL| HELO |NMBR| |EXIT| | + |AUTH|------->|AUTH| |AUTH| | + +----+ +----+ +----+ | + | #NNN + Bye | | + | | | + | +------------------------------------>+ | | + | ^ QUIT | | | + V | V | | + +--->+----+ +----+ +----+ | | + FOLD ^ |NMBR| READ |SIZE| |EXIT| | | + ---- | |MBOX|------->|MBOX| |MBOX| | | + #NNN +<---+----+ +----+ +----+ | | + ^ | =CCC + Bye | | | + | | | | | + FOLD +<--------+ | +------------------->+ | | | + ---- ^ | ^ QUIT | | | | + #NNN | V | V | | | + +--->+-----+ +----+ +----+ | | | + READ ^ |SIZE | RETR |XFER| |EXIT| | | | + ---- | | ITEM|------->|ITEM| |ITEM| | | | + =CCC +<---+-----+ +----+ +----+ | | | + ^ | data | | | | + | | | | | | + =CCC | V + Bye | | | | + +----+ +----+ | | | | + |SIZE| Ack |XFER| | | | | + |NEXT|<-------|NEXT| | | | | + +----+ +----+ | | | | + | | | | + | | | | + V V V | + +-------+ | + | EXIT |-->+ + | DONE | + +-------+ + + +Butler, et. al. [Page 19] + + + +RFC 937 February 1985 +Post Office Protocol + + +Client Decision Table + + + | STATE | + -------+----------------------------------| + INPUT | CALL | NMBR | SIZE | XFER | EXIT | + -------+----------------------------------| + Greet | 2 | 1 | 1 | 1 | 6 | + -------+----------------------------------| + #NNN | 1 | 3 | 1 | 1 | 6 | + -------+----------------------------------| + =CCC | 1 | 1 | 4 | 1 | 6 | + -------+----------------------------------| + data | 1 | 1 | 1 | 5 | 6 | + -------+----------------------------------| + + Bye | 1 | 1 | 1 | 1 | 6 | + -------+----------------------------------| + Close | 1 | 1 | 1 | 1 | 6 | + -------+----------------------------------| + other | 1 | 1 | 1 | 1 | 6 | + -------+----------------------------------| + Timeout| 1 | 1 | 1 | 1 | 6 | + -------+----------------------------------| + + + + + + + + + + + + + + + + + + + + + + + + + + + +Butler, et. al. [Page 20] + + + +RFC 937 February 1985 +Post Office Protocol + + + Actions: + + 1. This is garbage. Send "QUIT", and go to EXIT state. + + 2. (a) If the greeting is right then send "HELO" + and go to NMBR state, + (b) Else send "QUIT" and go to EXIT state. + + 3. (a) If user wants this folder and NNN > 0 + then send "READ" and go to SIZE state, + (b) If user wants a this folder and NNN = 0 + then send "QUIT" and go to EXIT state, + (c) If user wants a different folder + then send "FOLD" and go to NMBR state. + + 4. (a) If user wants this message and CCC > 0 + then send "RETR" and go to XFER state, + (b) If user wants a this message and CCC = 0 + then send "QUIT" and go to EXIT state, + (c) If user wants a different message + then send "READ" and go to SIZE state. + + 5. (a) If user wants this message kept + then send "ACKS" and go to SIZE state, + (b) If user wants a this message deleted + then send "ACKD" and go to SIZE state, + (c) If user wants a this message again + then send "NACK" and go to SIZE state. + + 6. Close the connection. + + + + + + + + + + + + + + + + + + + + +Butler, et. al. [Page 21] + + + +RFC 937 February 1985 +Post Office Protocol + + +Server Decision Table + + + | STATE + -------+----------------------------------------- + INPUT | LSTN | AUTH | MBOX | ITEM | NEXT | DONE | + -------+-----------------------------------------| + Open | 2 | 1 | 1 | 1 | 1 | 1 | + -------+-----------------------------------------| + HELO | 1 | 3 | 1 | 1 | 1 | 1 | + -------+-----------------------------------------| + FOLD | 1 | 1 | 5 | 5 | 1 | 1 | + -------+-----------------------------------------| + READ | 1 | 1 | 6 | 6 | 1 | 1 | + -------+-----------------------------------------| + RETR | 1 | 1 | 1 | 7 | 1 | 1 | + -------+-----------------------------------------| + ACKS | 1 | 1 | 1 | 1 | 8 | 1 | + -------+-----------------------------------------| + ACKD | 1 | 1 | 1 | 1 | 8 | 1 | + -------+-----------------------------------------| + NACK | 1 | 1 | 1 | 1 | 8 | 1 | + -------+-----------------------------------------| + QUIT | 1 | 4 | 4 | 4 | 1 | 1 | + -------+-----------------------------------------| + Close | 1 | 1 | 1 | 1 | 1 | 9 | + -------+-----------------------------------------| + other | 1 | 1 | 1 | 1 | 1 | 1 | + -------+-----------------------------------------| + Timeout| | 1 | 1 | 1 | 1 | 1 | + -------+-----------------------------------------| + + + + + + + + + + + + + + + + + + + +Butler, et. al. [Page 22] + + + +RFC 937 February 1985 +Post Office Protocol + + + Actions: + + 1. This is garbage. Send "- error", and Close the connection. + + 2. Send the greeting. Go to AUTH state. + + 3. (a) If authorized user then send "#NNN" and go tp MBOX state, + (b) Else send "- error" and Close the connection. + + 4. Send "+ Bye" and go to DONE state. + + 5. Send "+NNN" and go to MBOX state. + + 6. Send "=CCC" and go to ITEM state. + + 7. If message exists then send the data and got to NEXT state, + Else Close the connection. + + 8. Do what ACKS/ACKD/NACK require and go to ITEM state. + + 9. Close the connection. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Butler, et. al. [Page 23] + + + +RFC 937 February 1985 +Post Office Protocol + + +Acknowledgment + + We would like to acknowledge the helpful comments that we received on + the first version of POP described in RFC 918, and the draft of POP2 + distributed to interested parties. + +References + + [1] Postel, J., "Simple Mail Transfer Protocol", RFC 821, + USC/Information Sciences Institute, August 1982. + + [2] Crocker, D., "Standard for the Format of ARPA-Internet Text + Messages", RFC 822, University of Delaware, August 1982. + + [3] Reynolds, J.K., "Post Office Protocol", RFC 918, USC/Information + Sciences Institute, October 1984. + + [4] Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC 923, + USC/Information Sciences Institute, October 1984. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Butler, et. al. [Page 24] + diff --git a/RFC/rfc977.txt b/RFC/rfc977.txt new file mode 100644 index 00000000..0f965c48 --- /dev/null +++ b/RFC/rfc977.txt @@ -0,0 +1,1539 @@ + + +Network Working Group Brian Kantor (U.C. San Diego) +Request for Comments: 977 Phil Lapsley (U.C. Berkeley) + February 1986 + + Network News Transfer Protocol + + A Proposed Standard for the Stream-Based + Transmission of News + +Status of This Memo + + NNTP specifies a protocol for the distribution, inquiry, retrieval, + and posting of news articles using a reliable stream-based + transmission of news among the ARPA-Internet community. NNTP is + designed so that news articles are stored in a central database + allowing a subscriber to select only those items he wishes to read. + Indexing, cross-referencing, and expiration of aged messages are also + provided. This RFC suggests a proposed protocol for the ARPA-Internet + community, and requests discussion and suggestions for improvements. + Distribution of this memo is unlimited. + +1. Introduction + + For many years, the ARPA-Internet community has supported the + distribution of bulletins, information, and data in a timely fashion + to thousands of participants. We collectively refer to such items of + information as "news". Such news provides for the rapid + dissemination of items of interest such as software bug fixes, new + product reviews, technical tips, and programming pointers, as well as + rapid-fire discussions of matters of concern to the working computer + professional. News is very popular among its readers. + + There are popularly two methods of distributing such news: the + Internet method of direct mailing, and the USENET news system. + +1.1. Internet Mailing Lists + + The Internet community distributes news by the use of mailing lists. + These are lists of subscriber's mailbox addresses and remailing + sublists of all intended recipients. These mailing lists operate by + remailing a copy of the information to be distributed to each + subscriber on the mailing list. Such remailing is inefficient when a + mailing list grows beyond a dozen or so people, since sending a + separate copy to each of the subscribers occupies large quantities of + network bandwidth, CPU resources, and significant amounts of disk + storage at the destination host. There is also a significant problem + in maintenance of the list itself: as subscribers move from one job + to another; as new subscribers join and old ones leave; and as hosts + come in and out of service. + + + + +Kantor & Lapsley [Page 1] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + +1.2. The USENET News System + + Clearly, a worthwhile reduction of the amount of these resources used + can be achieved if articles are stored in a central database on the + receiving host instead of in each subscriber's mailbox. The USENET + news system provides a method of doing just this. There is a central + repository of the news articles in one place (customarily a spool + directory of some sort), and a set of programs that allow a + subscriber to select those items he wishes to read. Indexing, + cross-referencing, and expiration of aged messages are also provided. + +1.3. Central Storage of News + + For clusters of hosts connected together by fast local area networks + (such as Ethernet), it makes even more sense to consolidate news + distribution onto one (or a very few) hosts, and to allow access to + these news articles using a server and client model. Subscribers may + then request only the articles they wish to see, without having to + wastefully duplicate the storage of a copy of each item on each host. + +1.4. A Central News Server + + A way to achieve these economies is to have a central computer system + that can provide news service to the other systems on the local area + network. Such a server would manage the collection of news articles + and index files, with each person who desires to read news bulletins + doing so over the LAN. For a large cluster of computer systems, the + savings in total disk space is clearly worthwhile. Also, this allows + workstations with limited disk storage space to participate in the + news without incoming items consuming oppressive amounts of the + workstation's disk storage. + + We have heard rumors of somewhat successful attempts to provide + centralized news service using IBIS and other shared or distributed + file systems. While it is possible that such a distributed file + system implementation might work well with a group of similar + computers running nearly identical operating systems, such a scheme + is not general enough to offer service to a wide range of client + systems, especially when many diverse operating systems may be in use + among a group of clients. There are few (if any) shared or networked + file systems that can offer the generality of service that stream + connections using Internet TCP provide, particularly when a wide + range of host hardware and operating systems are considered. + + NNTP specifies a protocol for the distribution, inquiry, retrieval, + and posting of news articles using a reliable stream (such as TCP) + server-client model. NNTP is designed so that news articles need only + + +Kantor & Lapsley [Page 2] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + + be stored on one (presumably central) host, and subscribers on other + hosts attached to the LAN may read news articles using stream + connections to the news host. + + NNTP is modelled upon the news article specifications in RFC 850, + which describes the USENET news system. However, NNTP makes few + demands upon the structure, content, or storage of news articles, and + thus we believe it easily can be adapted to other non-USENET news + systems. + + Typically, the NNTP server runs as a background process on one host, + and would accept connections from other hosts on the LAN. This works + well when there are a number of small computer systems (such as + workstations, with only one or at most a few users each), and a large + central server. + +1.5. Intermediate News Servers + + For clusters of machines with many users (as might be the case in a + university or large industrial environment), an intermediate server + might be used. This intermediate or "slave" server runs on each + computer system, and is responsible for mediating news reading + requests and performing local caching of recently-retrieved news + articles. + + Typically, a client attempting to obtain news service would first + attempt to connect to the news service port on the local machine. If + this attempt were unsuccessful, indicating a failed server, an + installation might choose to either deny news access, or to permit + connection to the central "master" news server. + + For workstations or other small systems, direct connection to the + master server would probably be the normal manner of operation. + + This specification does not cover the operation of slave NNTP + servers. We merely suggest that slave servers are a logical addition + to NNTP server usage which would enhance operation on large local + area networks. + +1.6. News Distribution + + NNTP has commands which provide a straightforward method of + exchanging articles between cooperating hosts. Hosts which are well + connected on a local area or other fast network and who wish to + actually obtain copies of news articles for local storage might well + find NNTP to be a more efficient way to distribute news than more + traditional transfer methods (such as UUCP). + + +Kantor & Lapsley [Page 3] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + + In the traditional method of distributing news articles, news is + propagated from host to host by flooding - that is, each host will + send all its new news articles on to each host that it feeds. These + hosts will then in turn send these new articles on to other hosts + that they feed. Clearly, sending articles that a host already has + obtained a copy of from another feed (many hosts that receive news + are redundantly fed) again is a waste of time and communications + resources, but for transport mechanisms that are single-transaction + based rather than interactive (such as UUCP in the UNIX-world <1>), + distribution time is diminished by sending all articles and having + the receiving host simply discard the duplicates. This is an + especially true when communications sessions are limited to once a + day. + + Using NNTP, hosts exchanging news articles have an interactive + mechanism for deciding which articles are to be transmitted. A host + desiring new news, or which has new news to send, will typically + contact one or more of its neighbors using NNTP. First it will + inquire if any new news groups have been created on the serving host + by means of the NEWGROUPS command. If so, and those are appropriate + or desired (as established by local site-dependent rules), those new + newsgroups can be created. + + The client host will then inquire as to which new articles have + arrived in all or some of the newsgroups that it desires to receive, + using the NEWNEWS command. It will receive a list of new articles + from the server, and can request transmission of those articles that + it desires and does not already have. + + Finally, the client can advise the server of those new articles which + the client has recently received. The server will indicate those + articles that it has already obtained copies of, and which articles + should be sent to add to its collection. + + In this manner, only those articles which are not duplicates and + which are desired are transferred. + + + + + + + + + + + + + +Kantor & Lapsley [Page 4] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + +2. The NNTP Specification + +2.1. Overview + + The news server specified by this document uses a stream connection + (such as TCP) and SMTP-like commands and responses. It is designed + to accept connections from hosts, and to provide a simple interface + to the news database. + + This server is only an interface between programs and the news + databases. It does not perform any user interaction or presentation- + level functions. These "user-friendly" functions are better left to + the client programs, which have a better understanding of the + environment in which they are operating. + + When used via Internet TCP, the contact port assigned for this + service is 119. + +2.2. Character Codes + + Commands and replies are composed of characters from the ASCII + character set. When the transport service provides an 8-bit byte + (octet) transmission channel, each 7-bit character is transmitted + right justified in an octet with the high order bit cleared to zero. + +2.3. Commands + + Commands consist of a command word, which in some cases may be + followed by a parameter. Commands with parameters must separate the + parameters from each other and from the command by one or more space + or tab characters. Command lines must be complete with all required + parameters, and may not contain more than one command. + + Commands and command parameters are not case sensitive. That is, a + command or parameter word may be upper case, lower case, or any + mixture of upper and lower case. + + Each command line must be terminated by a CR-LF (Carriage Return - + Line Feed) pair. + + Command lines shall not exceed 512 characters in length, counting all + characters including spaces, separators, punctuation, and the + trailing CR-LF (thus there are 510 characters maximum allowed for the + command and its parameters). There is no provision for continuation + command lines. + + + + +Kantor & Lapsley [Page 5] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + +2.4. Responses + + Responses are of two kinds, textual and status. + +2.4.1. Text Responses + + Text is sent only after a numeric status response line has been sent + that indicates that text will follow. Text is sent as a series of + successive lines of textual matter, each terminated with CR-LF pair. + A single line containing only a period (.) is sent to indicate the + end of the text (i.e., the server will send a CR-LF pair at the end + of the last line of text, a period, and another CR-LF pair). + + If the text contained a period as the first character of the text + line in the original, that first period is doubled. Therefore, the + client must examine the first character of each line received, and + for those beginning with a period, determine either that this is the + end of the text or whether to collapse the doubled period to a single + one. + + The intention is that text messages will usually be displayed on the + user's terminal whereas command/status responses will be interpreted + by the client program before any possible display is done. + +2.4.2. Status Responses + + These are status reports from the server and indicate the response to + the last command received from the client. + + Status response lines begin with a 3 digit numeric code which is + sufficient to distinguish all responses. Some of these may herald + the subsequent transmission of text. + + The first digit of the response broadly indicates the success, + failure, or progress of the previous command. + + 1xx - Informative message + 2xx - Command ok + 3xx - Command ok so far, send the rest of it. + 4xx - Command was correct, but couldn't be performed for + some reason. + 5xx - Command unimplemented, or incorrect, or a serious + program error occurred. + + + + + + +Kantor & Lapsley [Page 6] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + + The next digit in the code indicates the function response category. + + x0x - Connection, setup, and miscellaneous messages + x1x - Newsgroup selection + x2x - Article selection + x3x - Distribution functions + x4x - Posting + x8x - Nonstandard (private implementation) extensions + x9x - Debugging output + + The exact response codes that should be expected from each command + are detailed in the description of that command. In addition, below + is listed a general set of response codes that may be received at any + time. + + Certain status responses contain parameters such as numbers and + names. The number and type of such parameters is fixed for each + response code to simplify interpretation of the response. + + Parameters are separated from the numeric response code and from each + other by a single space. All numeric parameters are decimal, and may + have leading zeros. All string parameters begin after the separating + space, and end before the following separating space or the CR-LF + pair at the end of the line. (String parameters may not, therefore, + contain spaces.) All text, if any, in the response which is not a + parameter of the response must follow and be separated from the last + parameter by a space. Also, note that the text following a response + number may vary in different implementations of the server. The + 3-digit numeric code should be used to determine what response was + sent. + + Response codes not specified in this standard may be used for any + installation-specific additional commands also not specified. These + should be chosen to fit the pattern of x8x specified above. (Note + that debugging is provided for explicitly in the x9x response codes.) + The use of unspecified response codes for standard commands is + prohibited. + + We have provided a response pattern x9x for debugging. Since much + debugging output may be classed as "informative messages", we would + expect, therefore, that responses 190 through 199 would be used for + various debugging outputs. There is no requirement in this + specification for debugging output, but if such is provided over the + connected stream, it must use these response codes. If appropriate + to a specific implementation, other x9x codes may be used for + debugging. (An example might be to use e.g., 290 to acknowledge a + remote debugging request.) + + +Kantor & Lapsley [Page 7] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + +2.4.3. General Responses + + The following is a list of general response codes that may be sent by + the NNTP server. These are not specific to any one command, but may + be returned as the result of a connection, a failure, or some unusual + condition. + + In general, 1xx codes may be ignored or displayed as desired; code + 200 or 201 is sent upon initial connection to the NNTP server + depending upon posting permission; code 400 will be sent when the + NNTP server discontinues service (by operator request, for example); + and 5xx codes indicate that the command could not be performed for + some unusual reason. + + 100 help text + 190 + through + 199 debug output + + 200 server ready - posting allowed + 201 server ready - no posting allowed + + 400 service discontinued + + 500 command not recognized + 501 command syntax error + 502 access restriction or permission denied + 503 program fault - command not performed + +3. Command and Response Details + + On the following pages are descriptions of each command recognized by + the NNTP server and the responses which will be returned by those + commands. + + Each command is shown in upper case for clarity, although case is + ignored in the interpretation of commands by the NNTP server. Any + parameters are shown in lower case. A parameter shown in [square + brackets] is optional. For example, [GMT] indicates that the + triglyph GMT may present or omitted. + + Every command described in this section must be implemented by all + NNTP servers. + + + + + + +Kantor & Lapsley [Page 8] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + + There is no prohibition against additional commands being added; + however, it is recommended that any such unspecified command begin + with the letter "X" to avoid conflict with later revisions of this + specification. + + Implementors are reminded that such additional commands may not + redefine specified status response codes. Using additional + unspecified responses for standard commands is also prohibited. + +3.1. The ARTICLE, BODY, HEAD, and STAT commands + + There are two forms to the ARTICLE command (and the related BODY, + HEAD, and STAT commands), each using a different method of specifying + which article is to be retrieved. When the ARTICLE command is + followed by a message-id in angle brackets ("<" and ">"), the first + form of the command is used; when a numeric parameter or no parameter + is supplied, the second form is invoked. + + The text of the article is returned as a textual response, as + described earlier in this document. + + The HEAD and BODY commands are identical to the ARTICLE command + except that they respectively return only the header lines or text + body of the article. + + The STAT command is similar to the ARTICLE command except that no + text is returned. When selecting by message number within a group, + the STAT command serves to set the current article pointer without + sending text. The returned acknowledgement response will contain the + message-id, which may be of some value. Using the STAT command to + select by message-id is valid but of questionable value, since a + selection by message-id does NOT alter the "current article pointer". + +3.1.1. ARTICLE (selection by message-id) + + ARTICLE + + Display the header, a blank line, then the body (text) of the + specified article. Message-id is the message id of an article as + shown in that article's header. It is anticipated that the client + will obtain the message-id from a list provided by the NEWNEWS + command, from references contained within another article, or from + the message-id provided in the response to some other commands. + + Please note that the internally-maintained "current article pointer" + is NOT ALTERED by this command. This is both to facilitate the + presentation of articles that may be referenced within an article + + +Kantor & Lapsley [Page 9] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + + being read, and because of the semantic difficulties of determining + the proper sequence and membership of an article which may have been + posted to more than one newsgroup. + +3.1.2. ARTICLE (selection by number) + + ARTICLE [nnn] + + Displays the header, a blank line, then the body (text) of the + current or specified article. The optional parameter nnn is the + + numeric id of an article in the current newsgroup and must be chosen + from the range of articles provided when the newsgroup was selected. + If it is omitted, the current article is assumed. + + The internally-maintained "current article pointer" is set by this + command if a valid article number is specified. + + [the following applies to both forms of the article command.] A + response indicating the current article number, a message-id string, + and that text is to follow will be returned. + + The message-id string returned is an identification string contained + within angle brackets ("<" and ">"), which is derived from the header + of the article itself. The Message-ID header line (required by + RFC850) from the article must be used to supply this information. If + the message-id header line is missing from the article, a single + digit "0" (zero) should be supplied within the angle brackets. + + Since the message-id field is unique with each article, it may be + used by a news reading program to skip duplicate displays of articles + that have been posted more than once, or to more than one newsgroup. + +3.1.3. Responses + + 220 n article retrieved - head and body follow + (n = article number, = message-id) + 221 n article retrieved - head follows + 222 n article retrieved - body follows + 223 n article retrieved - request text separately + 412 no newsgroup has been selected + 420 no current article has been selected + 423 no such article number in this group + 430 no such article found + + + + + +Kantor & Lapsley [Page 10] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + +3.2. The GROUP command + +3.2.1. GROUP + + GROUP ggg + + The required parameter ggg is the name of the newsgroup to be + selected (e.g. "net.news"). A list of valid newsgroups may be + obtained from the LIST command. + + The successful selection response will return the article numbers of + the first and last articles in the group, and an estimate of the + number of articles on file in the group. It is not necessary that + the estimate be correct, although that is helpful; it must only be + equal to or larger than the actual number of articles on file. (Some + implementations will actually count the number of articles on file. + Others will just subtract first article number from last to get an + estimate.) + + When a valid group is selected by means of this command, the + internally maintained "current article pointer" is set to the first + article in the group. If an invalid group is specified, the + previously selected group and article remain selected. If an empty + newsgroup is selected, the "current article pointer" is in an + indeterminate state and should not be used. + + Note that the name of the newsgroup is not case-dependent. It must + otherwise match a newsgroup obtained from the LIST command or an + error will result. + +3.2.2. Responses + + 211 n f l s group selected + (n = estimated number of articles in group, + f = first article number in the group, + l = last article number in the group, + s = name of the group.) + 411 no such news group + + + + + + + + + + + +Kantor & Lapsley [Page 11] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + +3.3. The HELP command + +3.3.1. HELP + + HELP + + Provides a short summary of commands that are understood by this + implementation of the server. The help text will be presented as a + textual response, terminated by a single period on a line by itself. + + 3.3.2. Responses + + 100 help text follows + +3.4. The IHAVE command + +3.4.1. IHAVE + + IHAVE + + The IHAVE command informs the server that the client has an article + whose id is . If the server desires a copy of that + article, it will return a response instructing the client to send the + entire article. If the server does not want the article (if, for + example, the server already has a copy of it), a response indicating + that the article is not wanted will be returned. + + If transmission of the article is requested, the client should send + the entire article, including header and body, in the manner + specified for text transmission from the server. A response code + indicating success or failure of the transferral of the article will + be returned. + + This function differs from the POST command in that it is intended + for use in transferring already-posted articles between hosts. + Normally it will not be used when the client is a personal + newsreading program. In particular, this function will invoke the + server's news posting program with the appropriate settings (flags, + options, etc) to indicate that the forthcoming article is being + forwarded from another host. + + The server may, however, elect not to post or forward the article if + after further examination of the article it deems it inappropriate to + do so. The 436 or 437 error codes may be returned as appropriate to + the situation. + + Reasons for such subsequent rejection of an article may include such + + +Kantor & Lapsley [Page 12] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + + problems as inappropriate newsgroups or distributions, disk space + limitations, article lengths, garbled headers, and the like. These + are typically restrictions enforced by the server host's news + software and not necessarily the NNTP server itself. + +3.4.2. Responses + + 235 article transferred ok + 335 send article to be transferred. End with . + 435 article not wanted - do not send it + 436 transfer failed - try again later + 437 article rejected - do not try again + + An implementation note: + + Because some host news posting software may not be able to decide + immediately that an article is inappropriate for posting or + forwarding, it is acceptable to acknowledge the successful transfer + of the article and to later silently discard it. Thus it is + permitted to return the 235 acknowledgement code and later discard + the received article. This is not a fully satisfactory solution to + the problem. Perhaps some implementations will wish to send mail to + the author of the article in certain of these cases. + +3.5. The LAST command + +3.5.1. LAST + + LAST + + The internally maintained "current article pointer" is set to the + previous article in the current newsgroup. If already positioned at + the first article of the newsgroup, an error message is returned and + the current article remains selected. + + The internally-maintained "current article pointer" is set by this + command. + + A response indicating the current article number, and a message-id + string will be returned. No text is sent in response to this + command. + +3.5.2. Responses + + 223 n a article retrieved - request text separately + (n = article number, a = unique article id) + + + +Kantor & Lapsley [Page 13] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + + 412 no newsgroup selected + 420 no current article has been selected + 422 no previous article in this group + +3.6. The LIST command + +3.6.1. LIST + + LIST + + Returns a list of valid newsgroups and associated information. Each + newsgroup is sent as a line of text in the following format: + + group last first p + + where is the name of the newsgroup, is the number of + the last known article currently in that newsgroup, is the + number of the first article currently in the newsgroup, and

is + either 'y' or 'n' indicating whether posting to this newsgroup is + allowed ('y') or prohibited ('n'). + + The and fields will always be numeric. They may have + leading zeros. If the field evaluates to less than the + field, there are no articles currently on file in the + newsgroup. + + Note that posting may still be prohibited to a client even though the + LIST command indicates that posting is permitted to a particular + newsgroup. See the POST command for an explanation of client + prohibitions. The posting flag exists for each newsgroup because + some newsgroups are moderated or are digests, and therefore cannot be + posted to; that is, articles posted to them must be mailed to a + moderator who will post them for the submitter. This is independent + of the posting permission granted to a client by the NNTP server. + + Please note that an empty list (i.e., the text body returned by this + command consists only of the terminating period) is a possible valid + response, and indicates that there are currently no valid newsgroups. + +3.6.2. Responses + + 215 list of newsgroups follows + + + + + + + +Kantor & Lapsley [Page 14] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + +3.7. The NEWGROUPS command + +3.7.1. NEWGROUPS + + NEWGROUPS date time [GMT] [] + + A list of newsgroups created since will be listed in + the same format as the LIST command. + + The date is sent as 6 digits in the format YYMMDD, where YY is the + last two digits of the year, MM is the two digits of the month (with + leading zero, if appropriate), and DD is the day of the month (with + leading zero, if appropriate). The closest century is assumed as + part of the year (i.e., 86 specifies 1986, 30 specifies 2030, 99 is + 1999, 00 is 2000). + + Time must also be specified. It must be as 6 digits HHMMSS with HH + being hours on the 24-hour clock, MM minutes 00-59, and SS seconds + 00-59. The time is assumed to be in the server's timezone unless the + token "GMT" appears, in which case both time and date are evaluated + at the 0 meridian. + + The optional parameter "distributions" is a list of distribution + groups, enclosed in angle brackets. If specified, the distribution + portion of a new newsgroup (e.g, 'net' in 'net.wombat') will be + examined for a match with the distribution categories listed, and + only those new newsgroups which match will be listed. If more than + one distribution group is to be listed, they must be separated by + commas within the angle brackets. + + Please note that an empty list (i.e., the text body returned by this + command consists only of the terminating period) is a possible valid + response, and indicates that there are currently no new newsgroups. + +3.7.2. Responses + + 231 list of new newsgroups follows + + + + + + + + + + + + +Kantor & Lapsley [Page 15] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + +3.8. The NEWNEWS command + +3.8.1. NEWNEWS + + NEWNEWS newsgroups date time [GMT] [] + + A list of message-ids of articles posted or received to the specified + newsgroup since "date" will be listed. The format of the listing will + be one message-id per line, as though text were being sent. A single + line consisting solely of one period followed by CR-LF will terminate + the list. + + Date and time are in the same format as the NEWGROUPS command. + + A newsgroup name containing a "*" (an asterisk) may be specified to + broaden the article search to some or all newsgroups. The asterisk + will be extended to match any part of a newsgroup name (e.g., + net.micro* will match net.micro.wombat, net.micro.apple, etc). Thus + if only an asterisk is given as the newsgroup name, all newsgroups + will be searched for new news. + + (Please note that the asterisk "*" expansion is a general + replacement; in particular, the specification of e.g., net.*.unix + should be correctly expanded to embrace names such as net.wombat.unix + and net.whocares.unix.) + + Conversely, if no asterisk appears in a given newsgroup name, only + the specified newsgroup will be searched for new articles. Newsgroup + names must be chosen from those returned in the listing of available + groups. Multiple newsgroup names (including a "*") may be specified + in this command, separated by a comma. No comma shall appear after + the last newsgroup in the list. [Implementors are cautioned to keep + the 512 character command length limit in mind.] + + The exclamation point ("!") may be used to negate a match. This can + be used to selectively omit certain newsgroups from an otherwise + larger list. For example, a newsgroups specification of + "net.*,mod.*,!mod.map.*" would specify that all net. and + all mod. EXCEPT mod.map. newsgroup names would be + matched. If used, the exclamation point must appear as the first + character of the given newsgroup name or pattern. + + The optional parameter "distributions" is a list of distribution + groups, enclosed in angle brackets. If specified, the distribution + portion of an article's newsgroup (e.g, 'net' in 'net.wombat') will + be examined for a match with the distribution categories listed, and + only those articles which have at least one newsgroup belonging to + + +Kantor & Lapsley [Page 16] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + + the list of distributions will be listed. If more than one + distribution group is to be supplied, they must be separated by + commas within the angle brackets. + + The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to distribute + news is discussed in an earlier part of this document. + + Please note that an empty list (i.e., the text body returned by this + command consists only of the terminating period) is a possible valid + response, and indicates that there is currently no new news. + +3.8.2. Responses + + 230 list of new articles by message-id follows + +3.9. The NEXT command + +3.9.1. NEXT + + NEXT + + The internally maintained "current article pointer" is advanced to + the next article in the current newsgroup. If no more articles + remain in the current group, an error message is returned and the + current article remains selected. + + The internally-maintained "current article pointer" is set by this + command. + + A response indicating the current article number, and the message-id + string will be returned. No text is sent in response to this + command. + +3.9.2. Responses + + 223 n a article retrieved - request text separately + (n = article number, a = unique article id) + 412 no newsgroup selected + 420 no current article has been selected + 421 no next article in this group + + + + + + + + + +Kantor & Lapsley [Page 17] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + +3.10. The POST command + +3.10.1. POST + + POST + + If posting is allowed, response code 340 is returned to indicate that + the article to be posted should be sent. Response code 440 indicates + that posting is prohibited for some installation-dependent reason. + + If posting is permitted, the article should be presented in the + format specified by RFC850, and should include all required header + lines. After the article's header and body have been completely sent + by the client to the server, a further response code will be returned + to indicate success or failure of the posting attempt. + + The text forming the header and body of the message to be posted + should be sent by the client using the conventions for text received + from the news server: A single period (".") on a line indicates the + end of the text, with lines starting with a period in the original + text having that period doubled during transmission. + + No attempt shall be made by the server to filter characters, fold or + limit lines, or otherwise process incoming text. It is our intent + that the server just pass the incoming message to be posted to the + server installation's news posting software, which is separate from + this specification. See RFC850 for more details. + + Since most installations will want the client news program to allow + the user to prepare his message using some sort of text editor, and + transmit it to the server for posting only after it is composed, the + client program should take note of the herald message that greeted it + when the connection was first established. This message indicates + whether postings from that client are permitted or not, and can be + used to caution the user that his access is read-only if that is the + case. This will prevent the user from wasting a good deal of time + composing a message only to find posting of the message was denied. + The method and determination of which clients and hosts may post is + installation dependent and is not covered by this specification. + +3.10.2. Responses + + 240 article posted ok + 340 send article to be posted. End with . + 440 posting not allowed + 441 posting failed + + + +Kantor & Lapsley [Page 18] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + + (for reference, one of the following codes will be sent upon initial + connection; the client program should determine whether posting is + generally permitted from these:) 200 server ready - posting allowed + 201 server ready - no posting allowed + +3.11. The QUIT command + +3.11.1. QUIT + + QUIT + + The server process acknowledges the QUIT command and then closes the + connection to the client. This is the preferred method for a client + to indicate that it has finished all its transactions with the NNTP + server. + + If a client simply disconnects (or the connection times out, or some + other fault occurs), the server should gracefully cease its attempts + to service the client. + +3.11.2. Responses + + 205 closing connection - goodbye! + +3.12. The SLAVE command + +3.12.1. SLAVE + + SLAVE + + Indicates to the server that this client connection is to a slave + server, rather than a user. + + This command is intended for use in separating connections to single + users from those to subsidiary ("slave") servers. It may be used to + indicate that priority should therefore be given to requests from + this client, as it is presumably serving more than one person. It + might also be used to determine which connections to close when + system load levels are exceeded, perhaps giving preference to slave + servers. The actual use this command is put to is entirely + implementation dependent, and may vary from one host to another. In + NNTP servers which do not give priority to slave servers, this + command must nonetheless be recognized and acknowledged. + +3.12.2. Responses + + 202 slave status noted + + +Kantor & Lapsley [Page 19] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + +4. Sample Conversations + + These are samples of the conversations that might be expected with + the news server in hypothetical sessions. The notation C: indicates + commands sent to the news server from the client program; S: indicate + responses received from the server by the client. + +4.1. Example 1 - relative access with NEXT + + S: (listens at TCP port 119) + + C: (requests connection on TCP port 119) + S: 200 wombatvax news server ready - posting ok + + (client asks for a current newsgroup list) + C: LIST + S: 215 list of newsgroups follows + S: net.wombats 00543 00501 y + S: net.unix-wizards 10125 10011 y + (more information here) + S: net.idiots 00100 00001 n + S: . + + (client selects a newsgroup) + C: GROUP net.unix-wizards + S: 211 104 10011 10125 net.unix-wizards group selected + (there are 104 articles on file, from 10011 to 10125) + + (client selects an article to read) + C: STAT 10110 + S: 223 10110 <23445@sdcsvax.ARPA> article retrieved - statistics + only (article 10110 selected, its message-id is + <23445@sdcsvax.ARPA>) + + (client examines the header) + C: HEAD + S: 221 10110 <23445@sdcsvax.ARPA> article retrieved - head + follows (text of the header appears here) + S: . + + (client wants to see the text body of the article) + C: BODY + S: 222 10110 <23445@sdcsvax.ARPA> article retrieved - body + follows (body text here) + S: . + + (client selects next article in group) + + +Kantor & Lapsley [Page 20] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + + C: NEXT + S: 223 10113 <21495@nudebch.uucp> article retrieved - statistics + only (article 10113 was next in group) + + (client finishes session) + C: QUIT + S: 205 goodbye. + +4.2. Example 2 - absolute article access with ARTICLE + + S: (listens at TCP port 119) + + C: (requests connection on TCP port 119) + S: 201 UCB-VAX netnews server ready -- no posting allowed + + C: GROUP msgs + S: 211 103 402 504 msgs Your new group is msgs + (there are 103 articles, from 402 to 504) + + C: ARTICLE 401 + S: 423 No such article in this newsgroup + + C: ARTICLE 402 + S: 220 402 <4105@ucbvax.ARPA> Article retrieved, text follows + S: (article header and body follow) + S: . + + C: HEAD 403 + S: 221 403 <3108@mcvax.UUCP> Article retrieved, header follows + S: (article header follows) + S: . + + C: QUIT + S: 205 UCB-VAX news server closing connection. Goodbye. + +4.3. Example 3 - NEWGROUPS command + + S: (listens at TCP port 119) + + C: (requests connection on TCP port 119) + S: 200 Imaginary Institute News Server ready (posting ok) + + (client asks for new newsgroups since April 3, 1985) + C: NEWGROUPS 850403 020000 + + S: 231 New newsgroups since 03/04/85 02:00:00 follow + + + +Kantor & Lapsley [Page 21] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + + S: net.music.gdead + S: net.games.sources + S: . + + C: GROUP net.music.gdead + S: 211 0 1 1 net.music.gdead Newsgroup selected + (there are no articles in that newsgroup, and + the first and last article numbers should be ignored) + + C: QUIT + S: 205 Imaginary Institute news server ceasing service. Bye! + +4.4. Example 4 - posting a news article + + S: (listens at TCP port 119) + + C: (requests connection on TCP port 119) + S: 200 BANZAIVAX news server ready, posting allowed. + + C: POST + S: 340 Continue posting; Period on a line by itself to end + C: (transmits news article in RFC850 format) + C: . + S: 240 Article posted successfully. + + C: QUIT + S: 205 BANZAIVAX closing connection. Goodbye. + +4.5. Example 5 - interruption due to operator request + + S: (listens at TCP port 119) + + C: (requests connection on TCP port 119) + S: 201 genericvax news server ready, no posting allowed. + + (assume normal conversation for some time, and + that a newsgroup has been selected) + + C: NEXT + S: 223 1013 <5734@mcvax.UUCP> Article retrieved; text separate. + + C: HEAD + C: 221 1013 <5734@mcvax.UUCP> Article retrieved; head follows. + + S: (sends head of article, but halfway through is + interrupted by an operator request. The following + then occurs, without client intervention.) + + +Kantor & Lapsley [Page 22] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + + S: (ends current line with a CR-LF pair) + S: . + S: 400 Connection closed by operator. Goodbye. + S: (closes connection) + +4.6. Example 6 - Using the news server to distribute news between + systems. + + S: (listens at TCP port 119) + + C: (requests connection on TCP port 119) + S: 201 Foobar NNTP server ready (no posting) + + (client asks for new newsgroups since 2 am, May 15, 1985) + C: NEWGROUPS 850515 020000 + S: 235 New newsgroups since 850515 follow + S: net.fluff + S: net.lint + S: . + + (client asks for new news articles since 2 am, May 15, 1985) + C: NEWNEWS * 850515 020000 + S: 230 New news since 850515 020000 follows + S: <1772@foo.UUCP> + S: <87623@baz.UUCP> + S: <17872@GOLD.CSNET> + S: . + + (client asks for article <1772@foo.UUCP>) + C: ARTICLE <1772@foo.UUCP> + S: 220 <1772@foo.UUCP> All of article follows + S: (sends entire message) + S: . + + (client asks for article <87623@baz.UUCP> + C: ARTICLE <87623@baz.UUCP> + S: 220 <87623@baz.UUCP> All of article follows + S: (sends entire message) + S: . + + (client asks for article <17872@GOLD.CSNET> + C: ARTICLE <17872@GOLD.CSNET> + S: 220 <17872@GOLD.CSNET> All of article follows + S: (sends entire message) + S: . + + + + +Kantor & Lapsley [Page 23] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + + (client offers an article it has received recently) + C: IHAVE <4105@ucbvax.ARPA> + S: 435 Already seen that one, where you been? + + (client offers another article) + C: IHAVE <4106@ucbvax.ARPA> + S: 335 News to me! to end. + C: (sends article) + C: . + S: 235 Article transferred successfully. Thanks. + + (or) + + S: 436 Transfer failed. + + (client is all through with the session) + C: QUIT + S: 205 Foobar NNTP server bids you farewell. + +4.7. Summary of commands and responses. + + The following are the commands recognized and responses returned by + the NNTP server. + +4.7.1. Commands + + ARTICLE + BODY + GROUP + HEAD + HELP + IHAVE + LAST + LIST + NEWGROUPS + NEWNEWS + NEXT + POST + QUIT + SLAVE + STAT + +4.7.2. Responses + + 100 help text follows + 199 debug output + + + +Kantor & Lapsley [Page 24] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + + 200 server ready - posting allowed + 201 server ready - no posting allowed + 202 slave status noted + 205 closing connection - goodbye! + 211 n f l s group selected + 215 list of newsgroups follows + 220 n article retrieved - head and body follow 221 n article + retrieved - head follows + 222 n article retrieved - body follows + 223 n article retrieved - request text separately 230 list of new + articles by message-id follows + 231 list of new newsgroups follows + 235 article transferred ok + 240 article posted ok + + 335 send article to be transferred. End with . + 340 send article to be posted. End with . + + 400 service discontinued + 411 no such news group + 412 no newsgroup has been selected + 420 no current article has been selected + 421 no next article in this group + 422 no previous article in this group + 423 no such article number in this group + 430 no such article found + 435 article not wanted - do not send it + 436 transfer failed - try again later + 437 article rejected - do not try again. + 440 posting not allowed + 441 posting failed + + 500 command not recognized + 501 command syntax error + 502 access restriction or permission denied + 503 program fault - command not performed + +4.8. A Brief Word about the USENET News System + + In the UNIX world, which traditionally has been linked by 1200 baud + dial-up telephone lines, the USENET News system has evolved to handle + central storage, indexing, retrieval, and distribution of news. With + the exception of its underlying transport mechanism (UUCP), USENET + News is an efficient means of providing news and bulletin service to + subscribers on UNIX and other hosts worldwide. The USENET News + + + + +Kantor & Lapsley [Page 25] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + + system is discussed in detail in RFC 850. It runs on most versions + of UNIX and on many other operating systems, and is customarily + distributed without charge. + + USENET uses a spooling area on the UNIX host to store news articles, + one per file. Each article consists of a series of heading text, + which contain the sender's identification and organizational + affiliation, timestamps, electronic mail reply paths, subject, + newsgroup (subject category), and the like. A complete news article + is reproduced in its entirety below. Please consult RFC 850 for more + details. + + Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site + sdcsvax.UUCP + Posting-Version: version B 2.10.1 6/24/83 SMI; site unitek.uucp + Path:sdcsvax!sdcrdcf!hplabs!qantel!ihnp4!alberta!ubc-vision!unitek + !honman + From: honman@unitek.uucp (Man Wong) + Newsgroups: net.unix-wizards + Subject: foreground -> background ? + Message-ID: <167@unitek.uucp> + Date: 25 Sep 85 23:51:52 GMT + Date-Received: 29 Sep 85 09:54:48 GMT + Reply-To: honman@unitek.UUCP (Hon-Man Wong) + Distribution: net.all + Organization: Unitek Technologies Corporation + Lines: 12 + + I have a process (C program) which generates a child and waits for + it to return. What I would like to do is to be able to run the + child process interactively for a while before kicking itself into + the background so I can return to the parent process (while the + child process is RUNNING in the background). Can it be done? And + if it can, how? + + Please reply by E-mail. Thanks in advance. + + Hon-Man Wong + + + + + + + + + + + +Kantor & Lapsley [Page 26] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + +5. References + + [1] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", RFC-822, Department of Electrical Engineering, + University of Delaware, August, 1982. + + [2] Horton, M., "Standard for Interchange of USENET Messages", + RFC-850, USENET Project, June, 1983. + + [3] Postel, J., "Transmission Control Protocol- DARPA Internet + Program Protocol Specification", RFC-793, USC/Information + Sciences Institute, September, 1981. + + [4] Postel, J., "Simple Mail Transfer Protocol", RFC-821, + USC/Information Sciences Institute, August, 1982. + +6. Acknowledgements + + The authors wish to express their heartfelt thanks to those many + people who contributed to this specification, and especially to Erik + Fair and Chuq von Rospach, without whose inspiration this whole thing + would not have been necessary. + +7. Notes + + <1> UNIX is a trademark of Bell Laboratories. + + + + + + + + + + + + + + + + + + + + + + + +Kantor & Lapsley [Page 27] + diff --git a/beos/beos_nameser.h b/beos/beos_nameser.h new file mode 100644 index 00000000..c20d35bd --- /dev/null +++ b/beos/beos_nameser.h @@ -0,0 +1,597 @@ +/* + * Copyright (c) 1983, 1989, 1993 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* + * Copyright (c) 1996-1999 by Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS + * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE + * CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL + * DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR + * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS + * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS + * SOFTWARE. + *//* Copyright (c) 1983, 1989 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* + * $Id: beos_nameser.h,v 1.1 2004/06/08 03:59:00 rfunk Exp $ + */ + +#ifndef _ARPA_NAMESER_H_ +#define _ARPA_NAMESER_H_ + +#define BIND_4_COMPAT + +#include +#include +#include + +#ifdef __cplusplus +# define __BEGIN_DECLS extern "C" { +# define __END_DECLS } +#else +# define __BEGIN_DECLS +# define __END_DECLS +#endif + +/* + * revision information. this is the release date in YYYYMMDD format. + * it can change every day so the right thing to do with it is use it + * in preprocessor commands such as "#if (__NAMESER > 19931104)". do not + * compare for equality; rather, use it to determine whether your libnameser.a + * is new enough to contain a certain feature. + */ + +/* XXXRTH I made this bigger than __BIND in 4.9.5 T6B */ +#define __NAMESER 19961001 /* New interface version stamp. */ + +/* + * Define constants based on RFC 883, RFC 1034, RFC 1035 + */ +#define NS_PACKETSZ 512 /* maximum packet size */ +#define NS_MAXDNAME 1025 /* maximum domain name */ +#define NS_MAXCDNAME 255 /* maximum compressed domain name */ +#define NS_MAXLABEL 63 /* maximum length of domain label */ +#define NS_HFIXEDSZ 12 /* #/bytes of fixed data in header */ +#define NS_QFIXEDSZ 4 /* #/bytes of fixed data in query */ +#define NS_RRFIXEDSZ 10 /* #/bytes of fixed data in r record */ +#define NS_INT32SZ 4 /* #/bytes of data in a u_int32_t */ +#define NS_INT16SZ 2 /* #/bytes of data in a u_int16_t */ +#define NS_INT8SZ 1 /* #/bytes of data in a u_int8_t */ +#define NS_INADDRSZ 4 /* IPv4 T_A */ +#define NS_IN6ADDRSZ 16 /* IPv6 T_AAAA */ +#define NS_CMPRSFLGS 0xc0 /* Flag bits indicating name compression. */ +#define NS_DEFAULTPORT 53 /* For both TCP and UDP. */ + +/* + * These can be expanded with synonyms, just keep ns_parse.c:ns_parserecord() + * in synch with it. + */ +typedef enum __ns_sect { + ns_s_qd = 0, /* Query: Question. */ + ns_s_zn = 0, /* Update: Zone. */ + ns_s_an = 1, /* Query: Answer. */ + ns_s_pr = 1, /* Update: Prerequisites. */ + ns_s_ns = 2, /* Query: Name servers. */ + ns_s_ud = 2, /* Update: Update. */ + ns_s_ar = 3, /* Query|Update: Additional records. */ + ns_s_max = 4 +} ns_sect; + +/* + * This is a message handle. It is caller allocated and has no dynamic data. + * This structure is intended to be opaque to all but ns_parse.c, thus the + * leading _'s on the member names. Use the accessor functions, not the _'s. + */ +typedef struct __ns_msg { + const u_char *_msg, *_eom; + u_int16_t _id, _flags, _counts[ns_s_max]; + const u_char *_sections[ns_s_max]; + ns_sect _sect; + int _rrnum; + const u_char *_ptr; +} ns_msg; + +/* Private data structure - do not use from outside library. */ +struct _ns_flagdata { int mask, shift; }; +extern struct _ns_flagdata _ns_flagdata[]; + +/* Accessor macros - this is part of the public interface. */ +#define ns_msg_getflag(handle, flag) ( \ + ((handle)._flags & _ns_flagdata[flag].mask) \ + >> _ns_flagdata[flag].shift \ + ) +#define ns_msg_id(handle) ((handle)._id + 0) +#define ns_msg_base(handle) ((handle)._msg + 0) +#define ns_msg_end(handle) ((handle)._eom + 0) +#define ns_msg_size(handle) ((handle)._eom - (handle)._msg) +#define ns_msg_count(handle, section) ((handle)._counts[section] + 0) + +/* + * This is a parsed record. It is caller allocated and has no dynamic data. + */ +typedef struct __ns_rr { + char name[NS_MAXDNAME]; /* XXX need to malloc */ + u_int16_t type; + u_int16_t class; + u_int32_t ttl; + u_int16_t rdlength; + const u_char *rdata; +} ns_rr; + +/* Accessor macros - this is part of the public interface. */ +#define ns_rr_name(rr) (((rr).name[0] != '\0') ? (rr).name : ".") +#define ns_rr_type(rr) ((rr).type + 0) +#define ns_rr_class(rr) ((rr).class + 0) +#define ns_rr_ttl(rr) ((rr).ttl + 0) +#define ns_rr_rdlen(rr) ((rr).rdlength + 0) +#define ns_rr_rdata(rr) ((rr).rdata + 0) + +/* + * These don't have to be in the same order as in the packet flags word, + * and they can even overlap in some cases, but they will need to be kept + * in synch with ns_parse.c:ns_flagdata[]. + */ +typedef enum __ns_flag { + ns_f_qr, /* Question/Response. */ + ns_f_opcode, /* Operation code. */ + ns_f_aa, /* Authoritative Answer. */ + ns_f_tc, /* Truncation occurred. */ + ns_f_rd, /* Recursion Desired. */ + ns_f_ra, /* Recursion Available. */ + ns_f_z, /* MBZ. */ + ns_f_ad, /* Authentic Data (DNSSEC). */ + ns_f_cd, /* Checking Disabled (DNSSEC). */ + ns_f_rcode, /* Response code. */ + ns_f_max +} ns_flag; + +/* + * Currently defined opcodes. + */ +typedef enum __ns_opcode { + ns_o_query = 0, /* Standard query. */ + ns_o_iquery = 1, /* Inverse query (deprecated/unsupported). */ + ns_o_status = 2, /* Name server status query (unsupported). */ + /* Opcode 3 is undefined/reserved. */ + ns_o_notify = 4, /* Zone change notification. */ + ns_o_update = 5, /* Zone update message. */ + ns_o_max = 6 +} ns_opcode; + +/* + * Currently defined response codes. + */ +typedef enum __ns_rcode { + ns_r_noerror = 0, /* No error occurred. */ + ns_r_formerr = 1, /* Format error. */ + ns_r_servfail = 2, /* Server failure. */ + ns_r_nxdomain = 3, /* Name error. */ + ns_r_notimpl = 4, /* Unimplemented. */ + ns_r_refused = 5, /* Operation refused. */ + /* these are for BIND_UPDATE */ + ns_r_yxdomain = 6, /* Name exists */ + ns_r_yxrrset = 7, /* RRset exists */ + ns_r_nxrrset = 8, /* RRset does not exist */ + ns_r_notauth = 9, /* Not authoritative for zone */ + ns_r_notzone = 10, /* Zone of record different from zone section */ + ns_r_max = 11, + /* The following are TSIG extended errors */ + ns_r_badsig = 16, + ns_r_badkey = 17, + ns_r_badtime = 18, + ns_r_badid = 19 +} ns_rcode; + +/* BIND_UPDATE */ +typedef enum __ns_update_operation { + ns_uop_delete = 0, + ns_uop_add = 1, + ns_uop_max = 2 +} ns_update_operation; + +/* + * This RR-like structure is particular to UPDATE. + */ +struct ns_updrec { + struct ns_updrec *r_prev; /* prev record */ + struct ns_updrec *r_next; /* next record */ + u_int8_t r_section; /* ZONE/PREREQUISITE/UPDATE */ + char * r_dname; /* owner of the RR */ + u_int16_t r_class; /* class number */ + u_int16_t r_type; /* type number */ + u_int32_t r_ttl; /* time to live */ + u_char * r_data; /* rdata fields as text string */ + u_int16_t r_size; /* size of r_data field */ + int r_opcode; /* type of operation */ + /* following fields for private use by the resolver/server routines */ + struct ns_updrec *r_grpnext; /* next record when grouped */ + struct databuf *r_dp; /* databuf to process */ + struct databuf *r_deldp; /* databuf's deleted/overwritten */ + u_int16_t r_zone; /* zone number on server */ +}; +typedef struct ns_updrec ns_updrec; + +/* + * This structure is used for TSIG authenticated messages + */ +struct ns_tsig_key { + char name[NS_MAXDNAME], alg[NS_MAXDNAME]; + unsigned char *data; + int len; +}; +typedef struct ns_tsig_key ns_tsig_key; + +/* + * This structure is used for TSIG authenticated TCP messages + */ +struct ns_tcp_tsig_state { + int counter; + struct dst_key *key; + void *ctx; + unsigned char sig[NS_PACKETSZ]; + int siglen; +}; +typedef struct ns_tcp_tsig_state ns_tcp_tsig_state; + +#define NS_TSIG_FUDGE 300 +#define NS_TSIG_TCP_COUNT 100 +#define NS_TSIG_ALG_HMAC_MD5 "HMAC-MD5.SIG-ALG.REG.INT" + +#define NS_TSIG_ERROR_NO_TSIG -10 +#define NS_TSIG_ERROR_NO_SPACE -11 +#define NS_TSIG_ERROR_FORMERR -12 + +/* + * Currently defined type values for resources and queries. + */ +typedef enum __ns_type { + ns_t_invalid = 0, /* Cookie. */ + ns_t_a = 1, /* Host address. */ + ns_t_ns = 2, /* Authoritative server. */ + ns_t_md = 3, /* Mail destination. */ + ns_t_mf = 4, /* Mail forwarder. */ + ns_t_cname = 5, /* Canonical name. */ + ns_t_soa = 6, /* Start of authority zone. */ + ns_t_mb = 7, /* Mailbox domain name. */ + ns_t_mg = 8, /* Mail group member. */ + ns_t_mr = 9, /* Mail rename name. */ + ns_t_null = 10, /* Null resource record. */ + ns_t_wks = 11, /* Well known service. */ + ns_t_ptr = 12, /* Domain name pointer. */ + ns_t_hinfo = 13, /* Host information. */ + ns_t_minfo = 14, /* Mailbox information. */ + ns_t_mx = 15, /* Mail routing information. */ + ns_t_txt = 16, /* Text strings. */ + ns_t_rp = 17, /* Responsible person. */ + ns_t_afsdb = 18, /* AFS cell database. */ + ns_t_x25 = 19, /* X_25 calling address. */ + ns_t_isdn = 20, /* ISDN calling address. */ + ns_t_rt = 21, /* Router. */ + ns_t_nsap = 22, /* NSAP address. */ + ns_t_nsap_ptr = 23, /* Reverse NSAP lookup (deprecated). */ + ns_t_sig = 24, /* Security signature. */ + ns_t_key = 25, /* Security key. */ + ns_t_px = 26, /* X.400 mail mapping. */ + ns_t_gpos = 27, /* Geographical position (withdrawn). */ + ns_t_aaaa = 28, /* Ip6 Address. */ + ns_t_loc = 29, /* Location Information. */ + ns_t_nxt = 30, /* Next domain (security). */ + ns_t_eid = 31, /* Endpoint identifier. */ + ns_t_nimloc = 32, /* Nimrod Locator. */ + ns_t_srv = 33, /* Server Selection. */ + ns_t_atma = 34, /* ATM Address */ + ns_t_naptr = 35, /* Naming Authority PoinTeR */ + ns_t_kx = 36, /* Key Exchange */ + ns_t_cert = 37, /* Certification record */ + /* Query type values which do not appear in resource records. */ + ns_t_tsig = 250, /* Transaction signature. */ + ns_t_ixfr = 251, /* Incremental zone transfer. */ + ns_t_axfr = 252, /* Transfer zone of authority. */ + ns_t_mailb = 253, /* Transfer mailbox records. */ + ns_t_maila = 254, /* Transfer mail agent records. */ + ns_t_any = 255, /* Wildcard match. */ + ns_t_zxfr = 256, /* BIND-specific, nonstandard. */ + ns_t_max = 65536 +} ns_type; + +#define ns_t_rr_p(t) ((t) < 128) /* Can this type appear in an RR? */ +#define ns_t_udp_p(t) ((t) != ns_t_axfr && (t) != ns_t_zxfr) +#define ns_t_xfr_p(t) ((t) == ns_t_axfr || (t) == ns_t_ixfr || \ + (t) == ns_t_zxfr) + +/* + * Values for class field + */ +typedef enum __ns_class { + ns_c_invalid = 0, /* Cookie. */ + ns_c_in = 1, /* Internet. */ + ns_c_2 = 2, /* unallocated/unsupported. */ + ns_c_chaos = 3, /* MIT Chaos-net. */ + ns_c_hs = 4, /* MIT Hesiod. */ + /* Query class values which do not appear in resource records */ + ns_c_none = 254, /* for prereq. sections in update requests */ + ns_c_any = 255, /* Wildcard match. */ + ns_c_max = 65536 +} ns_class; + +typedef enum __ns_key_types { + ns_kt_rsa = 1, /* key type RSA/MD5 */ + ns_kt_dh = 2, /* Diffie Hellman */ + ns_kt_dsa = 3, /* Digital Signature Standard (MANDETORY) */ + ns_kt_private = 254 /* Private key type starts with OID */ +} ns_key_types; + +typedef enum __ns_cert_types { + cert_t_pkix = 1, /* PKIX (X.509v3) */ + cert_t_spki = 2, /* SPKI */ + cert_t_pgp = 3, /* PGP */ + cert_t_url = 253, /* URL private type */ + cert_t_oid = 254 /* OID private type */ +} ns_cert_types; + +/* + * Flags field of the KEY RR rdata + */ +#define NS_KEY_TYPEMASK 0xC000 /* Mask for "type" bits */ +#define NS_KEY_TYPE_AUTH_CONF 0x0000 /* Key usable for both */ +#define NS_KEY_TYPE_CONF_ONLY 0x8000 /* Key usable for confidentiality */ +#define NS_KEY_TYPE_AUTH_ONLY 0x4000 /* Key usable for authentication */ +#define NS_KEY_TYPE_NO_KEY 0xC000 /* No key usable for either; no key */ +/* The type bits can also be interpreted independently, as single bits: */ +#define NS_KEY_NO_AUTH 0x8000 /* Key unusable for authentication */ +#define NS_KEY_NO_CONF 0x4000 /* Key unusable for confidentiality */ +#define NS_KEY_RESERVED2 0x2000 /* Security is *mandatory* if bit=0 */ +#define NS_KEY_EXTENDED_FLAGS 0x1000 /* reserved - must be zero */ +#define NS_KEY_RESERVED4 0x0800 /* reserved - must be zero */ +#define NS_KEY_RESERVED5 0x0400 /* reserved - must be zero */ +#define NS_KEY_NAME_TYPE 0x0300 /* these bits determine the type */ +#define NS_KEY_NAME_USER 0x0000 /* key is assoc. with user */ +#define NS_KEY_NAME_ENTITY 0x0200 /* key is assoc. with entity eg host */ +#define NS_KEY_NAME_ZONE 0x0100 /* key is zone key */ +#define NS_KEY_NAME_RESERVED 0x0300 /* reserved meaning */ +#define NS_KEY_RESERVED8 0x0080 /* reserved - must be zero */ +#define NS_KEY_RESERVED9 0x0040 /* reserved - must be zero */ +#define NS_KEY_RESERVED10 0x0020 /* reserved - must be zero */ +#define NS_KEY_RESERVED11 0x0010 /* reserved - must be zero */ +#define NS_KEY_SIGNATORYMASK 0x000F /* key can sign RR's of same name */ + +#define NS_KEY_RESERVED_BITMASK ( NS_KEY_RESERVED2 | \ + NS_KEY_RESERVED4 | \ + NS_KEY_RESERVED5 | \ + NS_KEY_RESERVED8 | \ + NS_KEY_RESERVED9 | \ + NS_KEY_RESERVED10 | \ + NS_KEY_RESERVED11 ) + +#define NS_KEY_RESERVED_BITMASK2 0xFFFF /* no bits defined here */ + +/* The Algorithm field of the KEY and SIG RR's is an integer, {1..254} */ +#define NS_ALG_MD5RSA 1 /* MD5 with RSA */ +#define NS_ALG_DH 2 /* Diffie Hellman KEY */ +#define NS_ALG_DSA 3 /* DSA KEY */ +#define NS_ALG_DSS NS_ALG_DSA +#define NS_ALG_EXPIRE_ONLY 253 /* No alg, no security */ +#define NS_ALG_PRIVATE_OID 254 /* Key begins with OID giving alg */ + +/* Protocol values */ +/* value 0 is reserved */ +#define NS_KEY_PROT_TLS 1 +#define NS_KEY_PROT_EMAIL 2 +#define NS_KEY_PROT_DNSSEC 3 +#define NS_KEY_PROT_IPSEC 4 +#define NS_KEY_PROT_ANY 255 + +/* Signatures */ +#define NS_MD5RSA_MIN_BITS 512 /* Size of a mod or exp in bits */ +#define NS_MD5RSA_MAX_BITS 2552 + /* Total of binary mod and exp */ +#define NS_MD5RSA_MAX_BYTES ((NS_MD5RSA_MAX_BITS+7/8)*2+3) + /* Max length of text sig block */ +#define NS_MD5RSA_MAX_BASE64 (((NS_MD5RSA_MAX_BYTES+2)/3)*4) +#define NS_MD5RSA_MIN_SIZE ((NS_MD5RSA_MIN_BITS+7)/8) +#define NS_MD5RSA_MAX_SIZE ((NS_MD5RSA_MAX_BITS+7)/8) + +#define NS_DSA_SIG_SIZE 41 +#define NS_DSA_MIN_SIZE 213 +#define NS_DSA_MAX_BYTES 405 + +/* Offsets into SIG record rdata to find various values */ +#define NS_SIG_TYPE 0 /* Type flags */ +#define NS_SIG_ALG 2 /* Algorithm */ +#define NS_SIG_LABELS 3 /* How many labels in name */ +#define NS_SIG_OTTL 4 /* Original TTL */ +#define NS_SIG_EXPIR 8 /* Expiration time */ +#define NS_SIG_SIGNED 12 /* Signature time */ +#define NS_SIG_FOOT 16 /* Key footprint */ +#define NS_SIG_SIGNER 18 /* Domain name of who signed it */ + +/* How RR types are represented as bit-flags in NXT records */ +#define NS_NXT_BITS 8 +#define NS_NXT_BIT_SET( n,p) (p[(n)/NS_NXT_BITS] |= (0x80>>((n)%NS_NXT_BITS))) +#define NS_NXT_BIT_CLEAR(n,p) (p[(n)/NS_NXT_BITS] &= ~(0x80>>((n)%NS_NXT_BITS))) +#define NS_NXT_BIT_ISSET(n,p) (p[(n)/NS_NXT_BITS] & (0x80>>((n)%NS_NXT_BITS))) +#define NS_NXT_MAX 127 + +/* + * Inline versions of get/put short/long. Pointer is advanced. + */ +#define NS_GET16(s, cp) { \ + register u_char *t_cp = (u_char *)(cp); \ + (s) = ((u_int16_t)t_cp[0] << 8) \ + | ((u_int16_t)t_cp[1]) \ + ; \ + (cp) += NS_INT16SZ; \ +} + +#define NS_GET32(l, cp) { \ + register u_char *t_cp = (u_char *)(cp); \ + (l) = ((u_int32_t)t_cp[0] << 24) \ + | ((u_int32_t)t_cp[1] << 16) \ + | ((u_int32_t)t_cp[2] << 8) \ + | ((u_int32_t)t_cp[3]) \ + ; \ + (cp) += NS_INT32SZ; \ +} + +#define NS_PUT16(s, cp) { \ + register u_int16_t t_s = (u_int16_t)(s); \ + register u_char *t_cp = (u_char *)(cp); \ + *t_cp++ = t_s >> 8; \ + *t_cp = t_s; \ + (cp) += NS_INT16SZ; \ +} + +#define NS_PUT32(l, cp) { \ + register u_int32_t t_l = (u_int32_t)(l); \ + register u_char *t_cp = (u_char *)(cp); \ + *t_cp++ = t_l >> 24; \ + *t_cp++ = t_l >> 16; \ + *t_cp++ = t_l >> 8; \ + *t_cp = t_l; \ + (cp) += NS_INT32SZ; \ +} + +/* + * ANSI C identifier hiding. + */ +#define ns_get16 __ns_get16 +#define ns_get32 __ns_get32 +#define ns_put16 __ns_put16 +#define ns_put32 __ns_put32 +#define ns_initparse __ns_initparse +#define ns_skiprr __ns_skiprr +#define ns_parserr __ns_parserr +#define ns_sprintrr __ns_sprintrr +#define ns_sprintrrf __ns_sprintrrf +#define ns_format_ttl __ns_format_ttl +#define ns_parse_ttl __ns_parse_ttl +#define ns_name_ntol __ns_name_ntol +#define ns_name_ntop __ns_name_ntop +#define ns_name_pton __ns_name_pton +#define ns_name_unpack __ns_name_unpack +#define ns_name_pack __ns_name_pack +#define ns_name_compress __ns_name_compress +#define ns_name_uncompress __ns_name_uncompress +#define ns_name_skip __ns_name_skip +#define ns_sign __ns_sign +#define ns_sign_tcp __ns_sign_tcp +#define ns_sign_tcp_init __ns_sign_tcp_init +#define ns_find_tsig __ns_find_tsig +#define ns_verify __ns_verify +#define ns_verify_tcp __ns_verify_tcp +#define ns_verify_tcp_init __ns_verify_tcp_init + +__BEGIN_DECLS +u_int ns_get16 __P((const u_char *)); +u_long ns_get32 __P((const u_char *)); +void ns_put16 __P((u_int, u_char *)); +void ns_put32 __P((u_long, u_char *)); +int ns_initparse __P((const u_char *, int, ns_msg *)); +int ns_skiprr __P((const u_char *, const u_char *, ns_sect, int)); +int ns_parserr __P((ns_msg *, ns_sect, int, ns_rr *)); +int ns_sprintrr __P((const ns_msg *, const ns_rr *, + const char *, const char *, char *, size_t)); +int ns_sprintrrf __P((const u_char *, size_t, const char *, + ns_class, ns_type, u_long, const u_char *, + size_t, const char *, const char *, + char *, size_t)); +int ns_format_ttl __P((u_long, char *, size_t)); +int ns_parse_ttl __P((const char *, u_long *)); +int ns_name_ntol __P((const u_char *, u_char *, size_t)); +int ns_name_ntop __P((const u_char *, char *, size_t)); +int ns_name_pton __P((const char *, u_char *, size_t)); +int ns_name_unpack __P((const u_char *, const u_char *, + const u_char *, u_char *, size_t)); +int ns_name_pack __P((const u_char *, u_char *, int, + const u_char **, const u_char **)); +int ns_name_uncompress __P((const u_char *, const u_char *, + const u_char *, char *, size_t)); +int ns_name_compress __P((const char *, u_char *, size_t, + const u_char **, const u_char **)); +int ns_name_skip __P((const u_char **, const u_char *)); +int ns_sign __P((u_char *, int *, int, int, void *, + const u_char *, int, u_char *, int *, time_t)); +int ns_sign_tcp __P((u_char *, int *, int, int, + ns_tcp_tsig_state *, int)); +int ns_sign_tcp_init __P((void *, const u_char *, int, + ns_tcp_tsig_state *)); +u_char *ns_find_tsig __P((u_char *, u_char *)); +int ns_verify __P((u_char *, int *, void *, + const u_char *, int, u_char *, int *, + time_t *, int)); +int ns_verify_tcp __P((u_char *, int *, ns_tcp_tsig_state *, int)); +int ns_verify_tcp_init __P((void *, const u_char *, int, + ns_tcp_tsig_state *)); +__END_DECLS + +#ifdef BIND_4_COMPAT +#include "beos_nameser_compat.h" +#endif + +#endif /* !_ARPA_NAMESER_H_ */ diff --git a/beos/beos_nameser_compat.h b/beos/beos_nameser_compat.h new file mode 100644 index 00000000..375b4b02 --- /dev/null +++ b/beos/beos_nameser_compat.h @@ -0,0 +1,229 @@ +/* Copyright (c) 1983, 1989 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* + * from nameser.h 8.1 (Berkeley) 6/2/93 + * $Id: beos_nameser_compat.h,v 1.1 2004/06/08 03:59:00 rfunk Exp $ + */ + +#ifndef _ARPA_NAMESER_COMPAT_ +#define _ARPA_NAMESER_COMPAT_ + +#define __BIND 19950621 /* (DEAD) interface version stamp. */ + +#ifndef BYTE_ORDER +#if (BSD >= 199103) +# include +#else +#ifdef linux +# include +#else +#define LITTLE_ENDIAN 1234 /* least-significant byte first (vax, pc) */ +#define BIG_ENDIAN 4321 /* most-significant byte first (IBM, net) */ +#define PDP_ENDIAN 3412 /* LSB first in word, MSW first in long (pdp)*/ + +#if defined(vax) || defined(ns32000) || defined(sun386) || defined(i386) || \ + defined(MIPSEL) || defined(_MIPSEL) || defined(BIT_ZERO_ON_RIGHT) || \ + defined(__alpha__) || defined(__alpha) || \ + (defined(__Lynx__) && defined(__x86__)) +#define BYTE_ORDER LITTLE_ENDIAN +#endif + +#if defined(sel) || defined(pyr) || defined(mc68000) || defined(sparc) || \ + defined(is68k) || defined(tahoe) || defined(ibm032) || defined(ibm370) || \ + defined(MIPSEB) || defined(_MIPSEB) || defined(_IBMR2) || defined(DGUX) ||\ + defined(apollo) || defined(__convex__) || defined(_CRAY) || \ + defined(__hppa) || defined(__hp9000) || \ + defined(__hp9000s300) || defined(__hp9000s700) || \ + defined (BIT_ZERO_ON_LEFT) || defined(m68k) || \ + (defined(__Lynx__) && \ + (defined(__68k__) || defined(__sparc__) || defined(__powerpc__))) +#define BYTE_ORDER BIG_ENDIAN +#endif +#endif /* linux */ +#endif /* BSD */ +#endif /* BYTE_ORDER */ + +#if !defined(BYTE_ORDER) || \ + (BYTE_ORDER != BIG_ENDIAN && BYTE_ORDER != LITTLE_ENDIAN && \ + BYTE_ORDER != PDP_ENDIAN) + /* you must determine what the correct bit order is for + * your compiler - the next line is an intentional error + * which will force your compiles to bomb until you fix + * the above macros. + */ + error "Undefined or invalid BYTE_ORDER"; +#endif + +/* + * Structure for query header. The order of the fields is machine- and + * compiler-dependent, depending on the byte/bit order and the layout + * of bit fields. We use bit fields only in int variables, as this + * is all ANSI requires. This requires a somewhat confusing rearrangement. + */ + +typedef struct { + unsigned id :16; /* query identification number */ +#if BYTE_ORDER == BIG_ENDIAN + /* fields in third byte */ + unsigned qr: 1; /* response flag */ + unsigned opcode: 4; /* purpose of message */ + unsigned aa: 1; /* authoritive answer */ + unsigned tc: 1; /* truncated message */ + unsigned rd: 1; /* recursion desired */ + /* fields in fourth byte */ + unsigned ra: 1; /* recursion available */ + unsigned unused :1; /* unused bits (MBZ as of 4.9.3a3) */ + unsigned ad: 1; /* authentic data from named */ + unsigned cd: 1; /* checking disabled by resolver */ + unsigned rcode :4; /* response code */ +#endif +#if BYTE_ORDER == LITTLE_ENDIAN || BYTE_ORDER == PDP_ENDIAN + /* fields in third byte */ + unsigned rd :1; /* recursion desired */ + unsigned tc :1; /* truncated message */ + unsigned aa :1; /* authoritive answer */ + unsigned opcode :4; /* purpose of message */ + unsigned qr :1; /* response flag */ + /* fields in fourth byte */ + unsigned rcode :4; /* response code */ + unsigned cd: 1; /* checking disabled by resolver */ + unsigned ad: 1; /* authentic data from named */ + unsigned unused :1; /* unused bits (MBZ as of 4.9.3a3) */ + unsigned ra :1; /* recursion available */ +#endif + /* remaining bytes */ + unsigned qdcount :16; /* number of question entries */ + unsigned ancount :16; /* number of answer entries */ + unsigned nscount :16; /* number of authority entries */ + unsigned arcount :16; /* number of resource entries */ +} HEADER; + +#define PACKETSZ NS_PACKETSZ +#define MAXDNAME NS_MAXDNAME +#define MAXCDNAME NS_MAXCDNAME +#define MAXLABEL NS_MAXLABEL +#define HFIXEDSZ NS_HFIXEDSZ +#define QFIXEDSZ NS_QFIXEDSZ +#define RRFIXEDSZ NS_RRFIXEDSZ +#define INT32SZ NS_INT32SZ +#define INT16SZ NS_INT16SZ +#define INADDRSZ NS_INADDRSZ +#define IN6ADDRSZ NS_IN6ADDRSZ +#define INDIR_MASK NS_CMPRSFLGS +#define NAMESERVER_PORT NS_DEFAULTPORT + +#define S_ZONE ns_s_zn +#define S_PREREQ ns_s_pr +#define S_UPDATE ns_s_ud +#define S_ADDT ns_s_ar + +#define QUERY ns_o_query +#define IQUERY ns_o_iquery +#define STATUS ns_o_status +#define NS_NOTIFY_OP ns_o_notify +#define NS_UPDATE_OP ns_o_update + +#define NOERROR ns_r_noerror +#define FORMERR ns_r_formerr +#define SERVFAIL ns_r_servfail +#define NXDOMAIN ns_r_nxdomain +#define NOTIMP ns_r_notimpl +#define REFUSED ns_r_refused +#define YXDOMAIN ns_r_yxdomain +#define YXRRSET ns_r_yxrrset +#define NXRRSET ns_r_nxrrset +#define NOTAUTH ns_r_notauth +#define NOTZONE ns_r_notzone +/*#define BADSIG ns_r_badsig*/ +/*#define BADKEY ns_r_badkey*/ +/*#define BADTIME ns_r_badtime*/ + + +#define DELETE ns_uop_delete +#define ADD ns_uop_add + +#define T_A ns_t_a +#define T_NS ns_t_ns +#define T_MD ns_t_md +#define T_MF ns_t_mf +#define T_CNAME ns_t_cname +#define T_SOA ns_t_soa +#define T_MB ns_t_mb +#define T_MG ns_t_mg +#define T_MR ns_t_mr +#define T_NULL ns_t_null +#define T_WKS ns_t_wks +#define T_PTR ns_t_ptr +#define T_HINFO ns_t_hinfo +#define T_MINFO ns_t_minfo +#define T_MX ns_t_mx +#define T_TXT ns_t_txt +#define T_RP ns_t_rp +#define T_AFSDB ns_t_afsdb +#define T_X25 ns_t_x25 +#define T_ISDN ns_t_isdn +#define T_RT ns_t_rt +#define T_NSAP ns_t_nsap +#define T_NSAP_PTR ns_t_nsap_ptr +#define T_SIG ns_t_sig +#define T_KEY ns_t_key +#define T_PX ns_t_px +#define T_GPOS ns_t_gpos +#define T_AAAA ns_t_aaaa +#define T_LOC ns_t_loc +#define T_NXT ns_t_nxt +#define T_EID ns_t_eid +#define T_NIMLOC ns_t_nimloc +#define T_SRV ns_t_srv +#define T_ATMA ns_t_atma +#define T_NAPTR ns_t_naptr +#define T_TSIG ns_t_tsig +#define T_IXFR ns_t_ixfr +#define T_AXFR ns_t_axfr +#define T_MAILB ns_t_mailb +#define T_MAILA ns_t_maila +#define T_ANY ns_t_any + +#define C_IN ns_c_in +#define C_CHAOS ns_c_chaos +#define C_HS ns_c_hs +/* BIND_UPDATE */ +#define C_NONE ns_c_none +#define C_ANY ns_c_any + +#define GETSHORT NS_GET16 +#define GETLONG NS_GET32 +#define PUTSHORT NS_PUT16 +#define PUTLONG NS_PUT32 + +#endif /* _ARPA_NAMESER_COMPAT_ */ diff --git a/bighand.png b/bighand.png new file mode 100644 index 00000000..14a6f5ca Binary files /dev/null and b/bighand.png differ diff --git a/config.sub b/config.sub new file mode 100755 index 00000000..c8e77851 --- /dev/null +++ b/config.sub @@ -0,0 +1,1268 @@ +#! /bin/sh +# Configuration validation subroutine script, version 1.1. +# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000 +# Free Software Foundation, Inc. +# +# This file is (in principle) common to ALL GNU software. +# The presence of a machine in this file suggests that SOME GNU software +# can handle that machine. It does not imply ALL GNU software can. +# +# This file is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program 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 General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, +# Boston, MA 02111-1307, USA. + +# As a special exception to the GNU General Public License, if you +# distribute this file as part of a program that contains a +# configuration script generated by Autoconf, you may include it under +# the same distribution terms that you use for the rest of that program. + +# Written by Per Bothner . +# Please send patches to . +# +# Configuration subroutine to validate and canonicalize a configuration type. +# Supply the specified configuration type as an argument. +# If it is invalid, we print an error message on stderr and exit with code 1. +# Otherwise, we print the canonical config type on stdout and succeed. + +# This file is supposed to be the same for all GNU packages +# and recognize all the CPU types, system types and aliases +# that are meaningful with *any* GNU software. +# Each package is responsible for reporting which valid configurations +# it does not support. The user should be able to distinguish +# a failure to support a valid configuration from a meaningless +# configuration. + +# The goal of this file is to map all the various variations of a given +# machine specification into a single specification in the form: +# CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM +# or in some cases, the newer four-part form: +# CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM +# It is wrong to echo any other type of specification. + +if [ x$1 = x ] +then + echo Configuration name missing. 1>&2 + echo "Usage: $0 CPU-MFR-OPSYS" 1>&2 + echo "or $0 ALIAS" 1>&2 + echo where ALIAS is a recognized configuration type. 1>&2 + exit 1 +fi + +# First pass through any local machine types. +case $1 in + *local*) + echo $1 + exit 0 + ;; + *) + ;; +esac + +# Separate what the user gave into CPU-COMPANY and OS or KERNEL-OS (if any). +# Here we must recognize all the valid KERNEL-OS combinations. +maybe_os=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\2/'` +case $maybe_os in + nto-qnx* | linux-gnu*) + os=-$maybe_os + basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'` + ;; + *) + basic_machine=`echo $1 | sed 's/-[^-]*$//'` + if [ $basic_machine != $1 ] + then os=`echo $1 | sed 's/.*-/-/'` + else os=; fi + ;; +esac + +### Let's recognize common machines as not being operating systems so +### that things like config.sub decstation-3100 work. We also +### recognize some manufacturers as not being operating systems, so we +### can provide default operating systems below. +case $os in + -sun*os*) + # Prevent following clause from handling this invalid input. + ;; + -dec* | -mips* | -sequent* | -encore* | -pc532* | -sgi* | -sony* | \ + -att* | -7300* | -3300* | -delta* | -motorola* | -sun[234]* | \ + -unicom* | -ibm* | -next | -hp | -isi* | -apollo | -altos* | \ + -convergent* | -ncr* | -news | -32* | -3600* | -3100* | -hitachi* |\ + -c[123]* | -convex* | -sun | -crds | -omron* | -dg | -ultra | -tti* | \ + -harris | -dolphin | -highlevel | -gould | -cbm | -ns | -masscomp | \ + -apple) + os= + basic_machine=$1 + ;; + -sim | -cisco | -oki | -wec | -winbond) + os= + basic_machine=$1 + ;; + -scout) + ;; + -wrs) + os=-vxworks + basic_machine=$1 + ;; + -hiux*) + os=-hiuxwe2 + ;; + -sco5) + os=-sco3.2v5 + basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` + ;; + -sco4) + os=-sco3.2v4 + basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` + ;; + -sco3.2.[4-9]*) + os=`echo $os | sed -e 's/sco3.2./sco3.2v/'` + basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` + ;; + -sco3.2v[4-9]*) + # Don't forget version if it is 3.2v4 or newer. + basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` + ;; + -sco*) + os=-sco3.2v2 + basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` + ;; + -udk*) + basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` + ;; + -isc) + os=-isc2.2 + basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` + ;; + -clix*) + basic_machine=clipper-intergraph + ;; + -isc*) + basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` + ;; + -lynx*) + os=-lynxos + ;; + -ptx*) + basic_machine=`echo $1 | sed -e 's/86-.*/86-sequent/'` + ;; + -windowsnt*) + os=`echo $os | sed -e 's/windowsnt/winnt/'` + ;; + -psos*) + os=-psos + ;; + -mint | -mint[0-9]*) + basic_machine=m68k-atari + os=-mint + ;; +esac + +# Decode aliases for certain CPU-COMPANY combinations. +case $basic_machine in + # Recognize the basic CPU types without company name. + # Some are omitted here because they have special meanings below. + tahoe | i860 | ia64 | m32r | m68k | m68000 | m88k | ns32k | arc | arm \ + | arme[lb] | pyramid | mn10200 | mn10300 | tron | a29k \ + | 580 | i960 | h8300 \ + | x86 | ppcbe | mipsbe | mipsle | shbe | shle | armbe | armle \ + | hppa | hppa1.0 | hppa1.1 | hppa2.0 | hppa2.0w | hppa2.0n \ + | hppa64 \ + | alpha | alphaev[4-8] | alphaev56 | alphapca5[67] \ + | alphaev6[78] \ + | we32k | ns16k | clipper | i370 | sh | powerpc | powerpcle \ + | 1750a | dsp16xx | pdp11 | mips16 | mips64 | mipsel | mips64el \ + | mips64orion | mips64orionel | mipstx39 | mipstx39el \ + | mips64vr4300 | mips64vr4300el | mips64vr4100 | mips64vr4100el \ + | mips64vr5000 | miprs64vr5000el | mcore \ + | sparc | sparclet | sparclite | sparc64 | sparcv9 | v850 | c4x \ + | thumb | d10v | fr30 | avr) + basic_machine=$basic_machine-unknown + ;; + m88110 | m680[12346]0 | m683?2 | m68360 | m5200 | z8k | v70 | h8500 | w65 | pj | pjl) + ;; + + # We use `pc' rather than `unknown' + # because (1) that's what they normally are, and + # (2) the word "unknown" tends to confuse beginning users. + i[34567]86) + basic_machine=$basic_machine-pc + ;; + # Object if more than one company name word. + *-*-*) + echo Invalid configuration \`$1\': machine \`$basic_machine\' not recognized 1>&2 + exit 1 + ;; + # Recognize the basic CPU types with company name. + # FIXME: clean up the formatting here. + vax-* | tahoe-* | i[34567]86-* | i860-* | ia64-* | m32r-* | m68k-* | m68000-* \ + | m88k-* | sparc-* | ns32k-* | fx80-* | arc-* | arm-* | c[123]* \ + | mips-* | pyramid-* | tron-* | a29k-* | romp-* | rs6000-* \ + | power-* | none-* | 580-* | cray2-* | h8300-* | h8500-* | i960-* \ + | xmp-* | ymp-* \ + | x86-* | ppcbe-* | mipsbe-* | mipsle-* | shbe-* | shle-* | armbe-* | armle-* \ + | hppa-* | hppa1.0-* | hppa1.1-* | hppa2.0-* | hppa2.0w-* \ + | hppa2.0n-* | hppa64-* \ + | alpha-* | alphaev[4-8]-* | alphaev56-* | alphapca5[67]-* \ + | alphaev6[78]-* \ + | we32k-* | cydra-* | ns16k-* | pn-* | np1-* | xps100-* \ + | clipper-* | orion-* \ + | sparclite-* | pdp11-* | sh-* | powerpc-* | powerpcle-* \ + | sparc64-* | sparcv9-* | sparc86x-* | mips16-* | mips64-* | mipsel-* \ + | mips64el-* | mips64orion-* | mips64orionel-* \ + | mips64vr4100-* | mips64vr4100el-* | mips64vr4300-* | mips64vr4300el-* \ + | mipstx39-* | mipstx39el-* | mcore-* \ + | f301-* | armv*-* | s390-* | sv1-* | t3e-* \ + | m88110-* | m680[01234]0-* | m683?2-* | m68360-* | z8k-* | d10v-* \ + | thumb-* | v850-* | d30v-* | tic30-* | c30-* | fr30-* \ + | bs2000-*) + ;; + # Recognize the various machine names and aliases which stand + # for a CPU type and a company and sometimes even an OS. + 386bsd) + basic_machine=i386-unknown + os=-bsd + ;; + 3b1 | 7300 | 7300-att | att-7300 | pc7300 | safari | unixpc) + basic_machine=m68000-att + ;; + 3b*) + basic_machine=we32k-att + ;; + a29khif) + basic_machine=a29k-amd + os=-udi + ;; + adobe68k) + basic_machine=m68010-adobe + os=-scout + ;; + alliant | fx80) + basic_machine=fx80-alliant + ;; + altos | altos3068) + basic_machine=m68k-altos + ;; + am29k) + basic_machine=a29k-none + os=-bsd + ;; + amdahl) + basic_machine=580-amdahl + os=-sysv + ;; + amiga | amiga-*) + basic_machine=m68k-cbm + ;; + amigaos | amigados) + basic_machine=m68k-cbm + os=-amigaos + ;; + amigaunix | amix) + basic_machine=m68k-cbm + os=-sysv4 + ;; + apollo68) + basic_machine=m68k-apollo + os=-sysv + ;; + apollo68bsd) + basic_machine=m68k-apollo + os=-bsd + ;; + aux) + basic_machine=m68k-apple + os=-aux + ;; + balance) + basic_machine=ns32k-sequent + os=-dynix + ;; + convex-c1) + basic_machine=c1-convex + os=-bsd + ;; + convex-c2) + basic_machine=c2-convex + os=-bsd + ;; + convex-c32) + basic_machine=c32-convex + os=-bsd + ;; + convex-c34) + basic_machine=c34-convex + os=-bsd + ;; + convex-c38) + basic_machine=c38-convex + os=-bsd + ;; + cray | ymp) + basic_machine=ymp-cray + os=-unicos + ;; + cray2) + basic_machine=cray2-cray + os=-unicos + ;; + [ctj]90-cray) + basic_machine=c90-cray + os=-unicos + ;; + crds | unos) + basic_machine=m68k-crds + ;; + da30 | da30-*) + basic_machine=m68k-da30 + ;; + decstation | decstation-3100 | pmax | pmax-* | pmin | dec3100 | decstatn) + basic_machine=mips-dec + ;; + delta | 3300 | motorola-3300 | motorola-delta \ + | 3300-motorola | delta-motorola) + basic_machine=m68k-motorola + ;; + delta88) + basic_machine=m88k-motorola + os=-sysv3 + ;; + dpx20 | dpx20-*) + basic_machine=rs6000-bull + os=-bosx + ;; + dpx2* | dpx2*-bull) + basic_machine=m68k-bull + os=-sysv3 + ;; + ebmon29k) + basic_machine=a29k-amd + os=-ebmon + ;; + elxsi) + basic_machine=elxsi-elxsi + os=-bsd + ;; + encore | umax | mmax) + basic_machine=ns32k-encore + ;; + es1800 | OSE68k | ose68k | ose | OSE) + basic_machine=m68k-ericsson + os=-ose + ;; + fx2800) + basic_machine=i860-alliant + ;; + genix) + basic_machine=ns32k-ns + ;; + gmicro) + basic_machine=tron-gmicro + os=-sysv + ;; + h3050r* | hiux*) + basic_machine=hppa1.1-hitachi + os=-hiuxwe2 + ;; + h8300hms) + basic_machine=h8300-hitachi + os=-hms + ;; + h8300xray) + basic_machine=h8300-hitachi + os=-xray + ;; + h8500hms) + basic_machine=h8500-hitachi + os=-hms + ;; + harris) + basic_machine=m88k-harris + os=-sysv3 + ;; + hp300-*) + basic_machine=m68k-hp + ;; + hp300bsd) + basic_machine=m68k-hp + os=-bsd + ;; + hp300hpux) + basic_machine=m68k-hp + os=-hpux + ;; + hp3k9[0-9][0-9] | hp9[0-9][0-9]) + basic_machine=hppa1.0-hp + ;; + hp9k2[0-9][0-9] | hp9k31[0-9]) + basic_machine=m68000-hp + ;; + hp9k3[2-9][0-9]) + basic_machine=m68k-hp + ;; + hp9k6[0-9][0-9] | hp6[0-9][0-9]) + basic_machine=hppa1.0-hp + ;; + hp9k7[0-79][0-9] | hp7[0-79][0-9]) + basic_machine=hppa1.1-hp + ;; + hp9k78[0-9] | hp78[0-9]) + # FIXME: really hppa2.0-hp + basic_machine=hppa1.1-hp + ;; + hp9k8[67]1 | hp8[67]1 | hp9k80[24] | hp80[24] | hp9k8[78]9 | hp8[78]9 | hp9k893 | hp893) + # FIXME: really hppa2.0-hp + basic_machine=hppa1.1-hp + ;; + hp9k8[0-9][13679] | hp8[0-9][13679]) + basic_machine=hppa1.1-hp + ;; + hp9k8[0-9][0-9] | hp8[0-9][0-9]) + basic_machine=hppa1.0-hp + ;; + hppa-next) + os=-nextstep3 + ;; + hppaosf) + basic_machine=hppa1.1-hp + os=-osf + ;; + hppro) + basic_machine=hppa1.1-hp + os=-proelf + ;; + i370-ibm* | ibm*) + basic_machine=i370-ibm + ;; +# I'm not sure what "Sysv32" means. Should this be sysv3.2? + i[34567]86v32) + basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'` + os=-sysv32 + ;; + i[34567]86v4*) + basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'` + os=-sysv4 + ;; + i[34567]86v) + basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'` + os=-sysv + ;; + i[34567]86sol2) + basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'` + os=-solaris2 + ;; + i386mach) + basic_machine=i386-mach + os=-mach + ;; + i386-vsta | vsta) + basic_machine=i386-unknown + os=-vsta + ;; + i386-go32 | go32) + basic_machine=i386-unknown + os=-go32 + ;; + i386-mingw32 | mingw32) + basic_machine=i386-unknown + os=-mingw32 + ;; + iris | iris4d) + basic_machine=mips-sgi + case $os in + -irix*) + ;; + *) + os=-irix4 + ;; + esac + ;; + isi68 | isi) + basic_machine=m68k-isi + os=-sysv + ;; + m88k-omron*) + basic_machine=m88k-omron + ;; + magnum | m3230) + basic_machine=mips-mips + os=-sysv + ;; + merlin) + basic_machine=ns32k-utek + os=-sysv + ;; + miniframe) + basic_machine=m68000-convergent + ;; + *mint | -mint[0-9]* | *MiNT | *MiNT[0-9]*) + basic_machine=m68k-atari + os=-mint + ;; + mipsel*-linux*) + basic_machine=mipsel-unknown + os=-linux-gnu + ;; + mips*-linux*) + basic_machine=mips-unknown + os=-linux-gnu + ;; + mips3*-*) + basic_machine=`echo $basic_machine | sed -e 's/mips3/mips64/'` + ;; + mips3*) + basic_machine=`echo $basic_machine | sed -e 's/mips3/mips64/'`-unknown + ;; + mmix*) + basic_machine=mmix-knuth + os=-mmixware + ;; + monitor) + basic_machine=m68k-rom68k + os=-coff + ;; + msdos) + basic_machine=i386-unknown + os=-msdos + ;; + mvs) + basic_machine=i370-ibm + os=-mvs + ;; + ncr3000) + basic_machine=i486-ncr + os=-sysv4 + ;; + netbsd386) + basic_machine=i386-unknown + os=-netbsd + ;; + netwinder) + basic_machine=armv4l-rebel + os=-linux + ;; + news | news700 | news800 | news900) + basic_machine=m68k-sony + os=-newsos + ;; + news1000) + basic_machine=m68030-sony + os=-newsos + ;; + news-3600 | risc-news) + basic_machine=mips-sony + os=-newsos + ;; + necv70) + basic_machine=v70-nec + os=-sysv + ;; + next | m*-next ) + basic_machine=m68k-next + case $os in + -nextstep* ) + ;; + -ns2*) + os=-nextstep2 + ;; + *) + os=-nextstep3 + ;; + esac + ;; + nh3000) + basic_machine=m68k-harris + os=-cxux + ;; + nh[45]000) + basic_machine=m88k-harris + os=-cxux + ;; + nindy960) + basic_machine=i960-intel + os=-nindy + ;; + mon960) + basic_machine=i960-intel + os=-mon960 + ;; + np1) + basic_machine=np1-gould + ;; + nsr-tandem) + basic_machine=nsr-tandem + ;; + op50n-* | op60c-*) + basic_machine=hppa1.1-oki + os=-proelf + ;; + OSE68000 | ose68000) + basic_machine=m68000-ericsson + os=-ose + ;; + os68k) + basic_machine=m68k-none + os=-os68k + ;; + pa-hitachi) + basic_machine=hppa1.1-hitachi + os=-hiuxwe2 + ;; + paragon) + basic_machine=i860-intel + os=-osf + ;; + pbd) + basic_machine=sparc-tti + ;; + pbb) + basic_machine=m68k-tti + ;; + pc532 | pc532-*) + basic_machine=ns32k-pc532 + ;; + pentium | p5 | k5 | k6 | nexen) + basic_machine=i586-pc + ;; + pentiumpro | p6 | 6x86) + basic_machine=i686-pc + ;; + pentiumii | pentium2) + basic_machine=i786-pc + ;; + pentium-* | p5-* | k5-* | k6-* | nexen-*) + basic_machine=i586-`echo $basic_machine | sed 's/^[^-]*-//'` + ;; + pentiumpro-* | p6-* | 6x86-*) + basic_machine=i686-`echo $basic_machine | sed 's/^[^-]*-//'` + ;; + pentiumii-* | pentium2-*) + basic_machine=i786-`echo $basic_machine | sed 's/^[^-]*-//'` + ;; + pn) + basic_machine=pn-gould + ;; + power) basic_machine=rs6000-ibm + ;; + ppc) basic_machine=powerpc-unknown + ;; + ppc-*) basic_machine=powerpc-`echo $basic_machine | sed 's/^[^-]*-//'` + ;; + ppcle | powerpclittle | ppc-le | powerpc-little) + basic_machine=powerpcle-unknown + ;; + ppcle-* | powerpclittle-*) + basic_machine=powerpcle-`echo $basic_machine | sed 's/^[^-]*-//'` + ;; + ps2) + basic_machine=i386-ibm + ;; + rom68k) + basic_machine=m68k-rom68k + os=-coff + ;; + rm[46]00) + basic_machine=mips-siemens + ;; + rtpc | rtpc-*) + basic_machine=romp-ibm + ;; + sa29200) + basic_machine=a29k-amd + os=-udi + ;; + sequent) + basic_machine=i386-sequent + ;; + sh) + basic_machine=sh-hitachi + os=-hms + ;; + sparclite-wrs) + basic_machine=sparclite-wrs + os=-vxworks + ;; + sps7) + basic_machine=m68k-bull + os=-sysv2 + ;; + spur) + basic_machine=spur-unknown + ;; + st2000) + basic_machine=m68k-tandem + ;; + stratus) + basic_machine=i860-stratus + os=-sysv4 + ;; + sun2) + basic_machine=m68000-sun + ;; + sun2os3) + basic_machine=m68000-sun + os=-sunos3 + ;; + sun2os4) + basic_machine=m68000-sun + os=-sunos4 + ;; + sun3os3) + basic_machine=m68k-sun + os=-sunos3 + ;; + sun3os4) + basic_machine=m68k-sun + os=-sunos4 + ;; + sun4os3) + basic_machine=sparc-sun + os=-sunos3 + ;; + sun4os4) + basic_machine=sparc-sun + os=-sunos4 + ;; + sun4sol2) + basic_machine=sparc-sun + os=-solaris2 + ;; + sun3 | sun3-*) + basic_machine=m68k-sun + ;; + sun4) + basic_machine=sparc-sun + ;; + sun386 | sun386i | roadrunner) + basic_machine=i386-sun + ;; + sv1) + basic_machine=sv1-cray + os=-unicos + ;; + symmetry) + basic_machine=i386-sequent + os=-dynix + ;; + t3e) + basic_machine=t3e-cray + os=-unicos + ;; + tx39) + basic_machine=mipstx39-unknown + ;; + tx39el) + basic_machine=mipstx39el-unknown + ;; + tower | tower-32) + basic_machine=m68k-ncr + ;; + udi29k) + basic_machine=a29k-amd + os=-udi + ;; + ultra3) + basic_machine=a29k-nyu + os=-sym1 + ;; + v810 | necv810) + basic_machine=v810-nec + os=-none + ;; + vaxv) + basic_machine=vax-dec + os=-sysv + ;; + vms) + basic_machine=vax-dec + os=-vms + ;; + vpp*|vx|vx-*) + basic_machine=f301-fujitsu + ;; + vxworks960) + basic_machine=i960-wrs + os=-vxworks + ;; + vxworks68) + basic_machine=m68k-wrs + os=-vxworks + ;; + vxworks29k) + basic_machine=a29k-wrs + os=-vxworks + ;; + w65*) + basic_machine=w65-wdc + os=-none + ;; + w89k-*) + basic_machine=hppa1.1-winbond + os=-proelf + ;; + xmp) + basic_machine=xmp-cray + os=-unicos + ;; + xps | xps100) + basic_machine=xps100-honeywell + ;; + z8k-*-coff) + basic_machine=z8k-unknown + os=-sim + ;; + none) + basic_machine=none-none + os=-none + ;; + +# Here we handle the default manufacturer of certain CPU types. It is in +# some cases the only manufacturer, in others, it is the most popular. + w89k) + basic_machine=hppa1.1-winbond + ;; + op50n) + basic_machine=hppa1.1-oki + ;; + op60c) + basic_machine=hppa1.1-oki + ;; + mips) + if [ x$os = x-linux-gnu ]; then + basic_machine=mips-unknown + else + basic_machine=mips-mips + fi + ;; + romp) + basic_machine=romp-ibm + ;; + rs6000) + basic_machine=rs6000-ibm + ;; + vax) + basic_machine=vax-dec + ;; + pdp11) + basic_machine=pdp11-dec + ;; + we32k) + basic_machine=we32k-att + ;; + sparc | sparcv9) + basic_machine=sparc-sun + ;; + cydra) + basic_machine=cydra-cydrome + ;; + orion) + basic_machine=orion-highlevel + ;; + orion105) + basic_machine=clipper-highlevel + ;; + mac | mpw | mac-mpw) + basic_machine=m68k-apple + ;; + pmac | pmac-mpw) + basic_machine=powerpc-apple + ;; + c4x*) + basic_machine=c4x-none + os=-coff + ;; + *) + echo Invalid configuration \`$1\': machine \`$basic_machine\' not recognized 1>&2 + exit 1 + ;; +esac + +# Here we canonicalize certain aliases for manufacturers. +case $basic_machine in + *-digital*) + basic_machine=`echo $basic_machine | sed 's/digital.*/dec/'` + ;; + *-commodore*) + basic_machine=`echo $basic_machine | sed 's/commodore.*/cbm/'` + ;; + *) + ;; +esac + +# Decode manufacturer-specific aliases for certain operating systems. + +if [ x"$os" != x"" ] +then +case $os in + # First match some system type aliases + # that might get confused with valid system types. + # -solaris* is a basic system type, with this one exception. + -solaris1 | -solaris1.*) + os=`echo $os | sed -e 's|solaris1|sunos4|'` + ;; + -solaris) + os=-solaris2 + ;; + -svr4*) + os=-sysv4 + ;; + -unixware*) + os=-sysv4.2uw + ;; + -gnu/linux*) + os=`echo $os | sed -e 's|gnu/linux|linux-gnu|'` + ;; + # First accept the basic system types. + # The portable systems comes first. + # Each alternative MUST END IN A *, to match a version number. + # -sysv* is not here because it comes later, after sysvr4. + -gnu* | -bsd* | -mach* | -minix* | -genix* | -ultrix* | -irix* \ + | -*vms* | -sco* | -esix* | -isc* | -aix* | -sunos | -sunos[34]*\ + | -hpux* | -unos* | -osf* | -luna* | -dgux* | -solaris* | -sym* \ + | -amigaos* | -amigados* | -msdos* | -newsos* | -unicos* | -aof* \ + | -aos* \ + | -nindy* | -vxsim* | -vxworks* | -ebmon* | -hms* | -mvs* \ + | -clix* | -riscos* | -uniplus* | -iris* | -rtu* | -xenix* \ + | -hiux* | -386bsd* | -netbsd* | -openbsd* | -freebsd* | -riscix* \ + | -lynxos* | -bosx* | -nextstep* | -cxux* | -aout* | -elf* | -oabi* \ + | -ptx* | -coff* | -ecoff* | -winnt* | -domain* | -vsta* \ + | -udi* | -eabi* | -lites* | -ieee* | -go32* | -aux* \ + | -cygwin* | -pe* | -psos* | -moss* | -proelf* | -rtems* \ + | -mingw32* | -linux-gnu* | -uxpv* | -beos* | -mpeix* | -udk* \ + | -interix* | -uwin* | -rhapsody* | -darwin* | -opened* \ + | -openstep* | -oskit*) + # Remember, each alternative MUST END IN *, to match a version number. + ;; + -qnx*) + case $basic_machine in + x86-* | i[34567]86-*) + ;; + *) + os=-nto$os + ;; + esac + ;; + -nto*) + os=-nto-qnx + ;; + -sim | -es1800* | -hms* | -xray | -os68k* | -none* | -v88r* \ + | -windows* | -osx | -abug | -netware* | -os9* | -beos* \ + | -macos* | -mpw* | -magic* | -mmixware* | -mon960* | -lnews*) + ;; + -mac*) + os=`echo $os | sed -e 's|mac|macos|'` + ;; + -linux*) + os=`echo $os | sed -e 's|linux|linux-gnu|'` + ;; + -sunos5*) + os=`echo $os | sed -e 's|sunos5|solaris2|'` + ;; + -sunos6*) + os=`echo $os | sed -e 's|sunos6|solaris3|'` + ;; + -opened*) + os=-openedition + ;; + -wince*) + os=-wince + ;; + -osfrose*) + os=-osfrose + ;; + -osf*) + os=-osf + ;; + -utek*) + os=-bsd + ;; + -dynix*) + os=-bsd + ;; + -acis*) + os=-aos + ;; + -386bsd) + os=-bsd + ;; + -ctix* | -uts*) + os=-sysv + ;; + -ns2 ) + os=-nextstep2 + ;; + -nsk) + os=-nsk + ;; + # Preserve the version number of sinix5. + -sinix5.*) + os=`echo $os | sed -e 's|sinix|sysv|'` + ;; + -sinix*) + os=-sysv4 + ;; + -triton*) + os=-sysv3 + ;; + -oss*) + os=-sysv3 + ;; + -svr4) + os=-sysv4 + ;; + -svr3) + os=-sysv3 + ;; + -sysvr4) + os=-sysv4 + ;; + # This must come after -sysvr4. + -sysv*) + ;; + -ose*) + os=-ose + ;; + -es1800*) + os=-ose + ;; + -xenix) + os=-xenix + ;; + -*mint | -*MiNT) + os=-mint + ;; + -none) + ;; + *) + # Get rid of the `-' at the beginning of $os. + os=`echo $os | sed 's/[^-]*-//'` + echo Invalid configuration \`$1\': system \`$os\' not recognized 1>&2 + exit 1 + ;; +esac +else + +# Here we handle the default operating systems that come with various machines. +# The value should be what the vendor currently ships out the door with their +# machine or put another way, the most popular os provided with the machine. + +# Note that if you're going to try to match "-MANUFACTURER" here (say, +# "-sun"), then you have to tell the case statement up towards the top +# that MANUFACTURER isn't an operating system. Otherwise, code above +# will signal an error saying that MANUFACTURER isn't an operating +# system, and we'll never get to this point. + +case $basic_machine in + *-acorn) + os=-riscix1.2 + ;; + arm*-rebel) + os=-linux + ;; + arm*-semi) + os=-aout + ;; + pdp11-*) + os=-none + ;; + *-dec | vax-*) + os=-ultrix4.2 + ;; + m68*-apollo) + os=-domain + ;; + i386-sun) + os=-sunos4.0.2 + ;; + m68000-sun) + os=-sunos3 + # This also exists in the configure program, but was not the + # default. + # os=-sunos4 + ;; + m68*-cisco) + os=-aout + ;; + mips*-cisco) + os=-elf + ;; + mips*-*) + os=-elf + ;; + *-tti) # must be before sparc entry or we get the wrong os. + os=-sysv3 + ;; + sparc-* | *-sun) + os=-sunos4.1.1 + ;; + *-be) + os=-beos + ;; + *-ibm) + os=-aix + ;; + *-wec) + os=-proelf + ;; + *-winbond) + os=-proelf + ;; + *-oki) + os=-proelf + ;; + *-hp) + os=-hpux + ;; + *-hitachi) + os=-hiux + ;; + i860-* | *-att | *-ncr | *-altos | *-motorola | *-convergent) + os=-sysv + ;; + *-cbm) + os=-amigaos + ;; + *-dg) + os=-dgux + ;; + *-dolphin) + os=-sysv3 + ;; + m68k-ccur) + os=-rtu + ;; + m88k-omron*) + os=-luna + ;; + *-next ) + os=-nextstep + ;; + *-sequent) + os=-ptx + ;; + *-crds) + os=-unos + ;; + *-ns) + os=-genix + ;; + i370-*) + os=-mvs + ;; + *-next) + os=-nextstep3 + ;; + *-gould) + os=-sysv + ;; + *-highlevel) + os=-bsd + ;; + *-encore) + os=-bsd + ;; + *-sgi) + os=-irix + ;; + *-siemens) + os=-sysv4 + ;; + *-masscomp) + os=-rtu + ;; + f301-fujitsu) + os=-uxpv + ;; + *-rom68k) + os=-coff + ;; + *-*bug) + os=-coff + ;; + *-apple) + os=-macos + ;; + *-atari*) + os=-mint + ;; + *) + os=-none + ;; +esac +fi + +# Here we handle the case where we know the os, and the CPU type, but not the +# manufacturer. We pick the logical manufacturer. +vendor=unknown +case $basic_machine in + *-unknown) + case $os in + -riscix*) + vendor=acorn + ;; + -sunos*) + vendor=sun + ;; + -aix*) + vendor=ibm + ;; + -beos*) + vendor=be + ;; + -hpux*) + vendor=hp + ;; + -mpeix*) + vendor=hp + ;; + -hiux*) + vendor=hitachi + ;; + -unos*) + vendor=crds + ;; + -dgux*) + vendor=dg + ;; + -luna*) + vendor=omron + ;; + -genix*) + vendor=ns + ;; + -mvs* | -opened*) + vendor=ibm + ;; + -ptx*) + vendor=sequent + ;; + -vxsim* | -vxworks*) + vendor=wrs + ;; + -aux*) + vendor=apple + ;; + -hms*) + vendor=hitachi + ;; + -mpw* | -macos*) + vendor=apple + ;; + -*mint | -*MiNT) + vendor=atari + ;; + esac + basic_machine=`echo $basic_machine | sed "s/unknown/$vendor/"` + ;; +esac + +echo $basic_machine$os diff --git a/contrib/README b/contrib/README new file mode 100644 index 00000000..d81ebbf2 --- /dev/null +++ b/contrib/README @@ -0,0 +1,179 @@ +These are scripts to help you running fetchmail in special situations. +Note: you're on your own using these -- I don't really understand them, +I'm just passing them along. + --esr + +maildaemon: + +Larry Fahnoe wrote this for driving fetchmail from cron. It may be useful if +you want to force a PPP link up and then poll for mail at specified times. +I have rearranged it slightly to make it easier to configure. + +novell: + +Some mail from Dan Newcombe describing how to write a procmail rule that +will domainify Novell server names. + +login & logout: + +These are intended to help if you typically have multiple logins active. +Here's the script composer's original README: + + Please find attached 2 files, ~/.bash_login & ~/.bash_logout + What these do is try to keep track of WHO is the process/tty + that ran fetchmail in daemon mode. I tried to use the bash + Variable PPID, but when using xterm the PPID is set to the + xterm's pid not the bash shell's pid so.... + + They have been lightly tested. + + Any comments... + + Hth, JimL + +Doug Carter suggests this instead: + +Add the following to your login script. (.ie .bash_profile, .profile, etc) + +LOGINS=`who | grep $USER | wc -l` +if [ $LOGINS = 1 ]; then + /usr/bin/fetchmail > /dev/null 2>&1 +fi + +Then add the following to your logout script. (.ie .bash_logout, etc) + +LOGINS=`who | grep $USER | wc -l` +if [ $LOGINS = 1 ]; then + /usr/bin/fetchmail -q > /dev/null 2>&1 +fi + +ip-up: + +A note from James Stevens about using fetchmail in an ip-up script without +disabling timeouts. + +runfetchmail: + +A shellscript front end for fetchmail that mails you various statistics on +the downloaded mail and the state of your folders. A good example of what +you can do with your own front end. + +fetchspool: + +If you find that the speed of forwarding to port 25 is limited by the +SMTP listener's speed, it may make sense to locally spool all the mail +first and feed it to sendmail after you hang up the network link. +This shellscript aims to do exactly that. It would be smarter to +figure out why sendmail is slow, however. + +fetchsetup: + +This is a shell script for creating a $HOME/.fetchmailrc file, it will ask +you some questions and based on your answers it will create a .fetchmailrc +file, fetchsetup is linux specific so it may not work on another operating +system. + +mailqueue.pl: + +This script will connect to your isp (if not already connected), +send any outgoing mail and retrieve any incoming mail. If this +program made the connection, it will also break the connection +when it is done. By Bill Adams, . The +latest version is carried at . + +redhat_rc: + +A fetchmail boot-time init file compatible with RedHat 5.1. It leaves +fetchmail in background to get messages when you connect to your ISP. +The invoked fetchmail expects to find its configuration in +/etc/fetchmailrc, and must include the proper "interface" directive. + +debian_rc: + +A fetchmail boot-time init file compatible with Debian. It leaves +fetchmail in background to get messages when you connect to your ISP. +The invoked fetchmail expects to find its configuration in +/root/.fetchmailrc, and must include the proper "interface" directive. + +start_dynamic_ppp: + +An admittedly scratchy ip-up script that Ryan Murray wrote to cope with +dynamic PPP addressing. Will need some customizing. + + http://www.inetarena.com/~badams/linux/programs/mailqueue.pl + +getfetchmail: + +Here's a script that gets Eric's most recent fetchmail source rpm, +downloads it and (if the rpm's not broken) rebuilds it. + +With fairly simple changes it can be used to download the latest i386 rpm +or tar.gz. + +Those who are addicted to having the latest of everything could filter mail +from fetchmail announce through it and get new versions as they're +announced. However, if we all did that, Eric's ftp server might feel a +little stressed. + +The script as written works on bash 2. By John Summerfield +. + +zsh-completion: + +These commands set up command completion for fetchmail under zsh. +Jay Kominek . + +getmail/gotmail: + +These scripts are front ends for fetchmail in daemon mode that can gather +log statistics and generate text or HTML reports. See README.getmail for +details. Scripts by Thomas Nesges . + +fetchmaildistrib: + +This script resolves the issue where the sysadmin polls for mail with fetchmail +only at set intervals, but where a user wishes to see his email right +away. The duplication in /etc/fetchmailrc and ~/.fetchmailrc files is +automated with this script; whenever /etc/fetchmailrc is changed, this +script is run to distribute the stuff into all user's ~/.fetchmailrc +files. + +multidrop: + +Martijn Lievaart's sendmail hacks to make multidrop reliable. + +domino: + +Gustavo Chaves wrote this script to deal with +the boundary-mismatch bug in Domino (see FAQ item X5). If you use +this with --mda, the broken boundaries will be fixed and the result +passed to procmail. + +toprocmail: + +John Lim Eng Hooi wrote this script, yet another +mda plugin, to be used with fetchmail in foreground mode. It displays +some header lines to stdout in color, passing them (and the rest of the +message content) to procmail. + +preauth-harness: + +Emmanuel Dreyfus's Perl test script for exercising IMAP PREAUTH +connections. You'll have to patch in your username and password. + +sm-hybrid: + +Peter 'Rattacresh' Backes sent this patch to improve the behavior of +sendmail 8.11.0 with multidrop. + +fetchmailnochda.pl + +Watchdog script to check whether fetchmail is working in daemon mode. + +mold-remover.py + +A short python script to remove old read mail from a pop3 mailserver. +Dovetails with fetchmail with keep option. +Run it as a cron job... + + diff --git a/contrib/README.getmail b/contrib/README.getmail new file mode 100644 index 00000000..237889cd --- /dev/null +++ b/contrib/README.getmail @@ -0,0 +1,64 @@ +------------------------------------------------------------------------------- + + - GetMail - GotMail - + + 1999 by Thomas Nesges + +------------------------------------------------------------------------------- + +------------------------------------------------------------------------------- +Installation: +------------------------------------------------------------------------------- +The Installation is as simple as it could be. Just create the directory +/usr/local/gotmail and copy all files to it. Ready. + +If you decide to choose an other directory to copy the files to, don't forget +to change the path in the scripts. + +------------------------------------------------------------------------------- +Usage: +------------------------------------------------------------------------------- +GetMail starts with: getmail

+

Fetchmail's Test List

+ +

Here are the server types on my regression-test list:

+ + + + + + + + + + + + + + + + + + + + + + +
Protocol & Version:Special Options:
IMAP: CommuniGate IMAP serverIMAPrev1 STARTTLS AUTH=CRAM-MD5 AUTH=DIGEST-MD5
POP3: CommuniGate POP3 serverCAPA LAST APOP CRAM-MD5
POP3: IntraStore POP3 mail server!CAPA LAST
APOP: IntraStore POP3 mail server!CAPA LAST APOP
IMAP: IntraStore IMAP mail serverIMAPrev1 IDLE AUTH=CRAM-MD5 AUTH=SKEY AUTH=ANONYMOUS
POP3: Eudora EIMSCAPA LAST APOP SASL CRAM-MD5 NTLM
POP3: gmx.de pop server!CAPA UIDL
IMAP: IMail IMAP serverIMAP4rev1 AUTH=CRAM-MD5
IMAP: Microsoft ExchangeIDLE AUTH=NTLM
POP3: qpopper 3.1.2 (Eudora) patched with mysqlCAPA UIDL
IMAP: Courier IMAPIMAP4rev1
POP3: Courier POP3CAPA UIDL
APOP: Qpopper using APOP!CAPA
IMAP: UW IMAPIMAPrev1
IMAP: Courier IMAPIMAP4rev1
POP3: Qpopper 4.0.5CAPA UIDL
+ +

If you control a post-office server that is not one of the types listed +here, please consider lending me a test account. Note that I do not +need shell access, just the permissions to send mail to a mailbox the server +looks at and to fetch mail off of it.

+ +

I'd like to have weird things like a POP2 server on here. Also more +closed-source servers because they tend to be broken in odd +ways. These are the real robustness tests.

+ +
+ +
Back to Eric's Home Page +Up to Site Map +Mon Jan 12 15:52:14 EST 2004 +
+ +
+
Eric S. Raymond <esr@thyrsus.com>
+ + diff --git a/timeplot b/timeplot new file mode 100755 index 00000000..c8240d05 --- /dev/null +++ b/timeplot @@ -0,0 +1,40 @@ +#!/bin/sh +# +# timeplot -- plot data on fetchmail release intervals +# +# + +# Get data from the NEWS file +timeseries | awk >/tmp/timeplot$$ ' +START {maxdiff = 0;} +/^[#%]/ {next;} + {days[count++] = $6;} +END { + for (i = 0; i < count-1; i++) + { + diffs[i] = days[i] - days[i + 1]; + if (maxdiff < diffs[i]) + maxdiff = diffs[i]; + } + for (i = 0; i <= maxdiff; i++) + freq[i] = 0; + for (i = 0; i < count - 1; i++) + { + freq[diffs[i]]++; + } + for (i = 0; i <= maxdiff; i++) + printf("%d %d\n", i, freq[i]); + } +' + +gnuplot >time.png - < + + + + torturetest + torturetest + diff --git a/uploadfaq b/uploadfaq new file mode 100755 index 00000000..73d29468 --- /dev/null +++ b/uploadfaq @@ -0,0 +1,24 @@ +#!/bin/sh + +version=`sed -n '/VERSION *= *\(.*\)/s//\1/p'