[SCM] GNU Mailutils branch, master, updated. rel-2_1-26-gc29efb8
"Sergey Poznyakoff" <[email protected]>
| Newsgroups | gmane.comp.gnu.mailutils.cvs |
|---|---|
| Message-ID | <[email protected]> |
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU Mailutils".
http://git.savannah.gnu.org/cgit/mailutils.git/commit/?id=c29efb856680ddb480b03c12e6f6395b45c7b386
The branch, master has been updated
via c29efb856680ddb480b03c12e6f6395b45c7b386 (commit)
via 34e0ea264af7c44463eef1c06fff8b1d428b34de (commit)
via bd8c37225f29f412139d2487d8d2772defa6a351 (commit)
via 5026f51b543c08f9361e068b2f4300df6512473b (commit)
from 67f986cb4fa48411010cb962c34600c34b6af146 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit c29efb856680ddb480b03c12e6f6395b45c7b386
Author: Sergey Poznyakoff <[email protected]>
Date: Tue Jan 5 14:56:21 2010 +0200
Bugfixes.
* mailbox/stream.c (mu_stream_readline): Account for terminating
null (fixes buffer overrun).
(mu_stream_getline): Fix reallocation condition.
commit 34e0ea264af7c44463eef1c06fff8b1d428b34de
Author: Sergey Poznyakoff <[email protected]>
Date: Tue Jan 5 14:29:15 2010 +0200
Remove uncompatibly-copyrighted material.
* configure.ac: Remove doc/rfc/Makefile.am
* doc/Makefile.am (SUBDIRS): Remove rfc.
(EXTRA_DIST): Add rfc/README.
* doc/rfc/README: New file.
* doc/rfc/CMC_V1.PS.gz: Remove.
* doc/rfc/Makefile.am: Remove.
* doc/rfc/rfc1413.txt: Remove.
* doc/rfc/rfc1521.txt: Remove.
* doc/rfc/rfc1731.txt: Remove.
* doc/rfc/rfc1734.txt: Remove.
* doc/rfc/rfc1738.txt: Remove.
* doc/rfc/rfc1870.txt: Remove.
* doc/rfc/rfc1891.txt: Remove.
* doc/rfc/rfc1892.txt: Remove.
* doc/rfc/rfc1893.txt: Remove.
* doc/rfc/rfc1894.txt: Remove.
* doc/rfc/rfc1939.txt: Remove.
* doc/rfc/rfc1957.txt: Remove.
* doc/rfc/rfc2045.txt: Remove.
* doc/rfc/rfc2046.txt: Remove.
* doc/rfc/rfc2047.txt: Remove.
* doc/rfc/rfc2049.txt: Remove.
* doc/rfc/rfc2060-errata
* doc/rfc/rfc2060.txt: Remove.
* doc/rfc/rfc2087.txt: Remove.
* doc/rfc/rfc2088.txt: Remove.
* doc/rfc/rfc2111.txt: Remove.
* doc/rfc/rfc2177.txt: Remove.
* doc/rfc/rfc2180.txt: Remove.
* doc/rfc/rfc2192.txt: Remove.
* doc/rfc/rfc2193.txt: Remove.
* doc/rfc/rfc2195.txt: Remove.
* doc/rfc/rfc2221.txt: Remove.
* doc/rfc/rfc2222.txt: Remove.
* doc/rfc/rfc2231.txt: Remove.
* doc/rfc/rfc2245.txt: Remove.
* doc/rfc/rfc2298.txt: Remove.
* doc/rfc/rfc2342.txt: Remove.
* doc/rfc/rfc2368.txt: Remove.
* doc/rfc/rfc2384.txt: Remove.
* doc/rfc/rfc2444.txt: Remove.
* doc/rfc/rfc2449.txt: Remove.
* doc/rfc/rfc2595.txt: Remove.
* doc/rfc/rfc2683.txt: Remove.
* doc/rfc/rfc2808.txt: Remove.
* doc/rfc/rfc2821.txt: Remove.
* doc/rfc/rfc2822.txt: Remove.
* doc/rfc/rfc2831.txt: Remove.
* doc/rfc/rfc3028.txt: Remove.
* doc/rfc/rfc3206.txt: Remove.
* doc/rfc/rfc3348.txt: Remove.
* doc/rfc/rfc3431.txt: Remove.
* doc/rfc/rfc3501.txt: Remove.
* doc/rfc/rfc3691.txt: Remove.
* doc/rfc/rfc4314.txt: Remove.
* doc/rfc/rfc821.txt: Remove.
* doc/rfc/rfc822.txt: Remove.
* doc/rfc/rfc934.txt: Remove.
* doc/rfc/sasl-mechanisms: Remove.
commit bd8c37225f29f412139d2487d8d2772defa6a351
Author: Sergey Poznyakoff <[email protected]>
Date: Tue Jan 5 13:43:21 2010 +0200
Fix indentation in Sieve scripts.
* sieve/examples/ex-1.10.2.sv: Use GNU indentation style
* sieve/examples/ex-2.3a.sv: Likewise.
* sieve/examples/ex-2.5.1.sv: Likewise.
* sieve/examples/ex-2.7.3.sv: Likewise.
* sieve/examples/ex-3.1a.sv: Likewise.
* sieve/examples/ex-3.1b.sv: Likewise.
* sieve/examples/ex-3.2.sv: Likewise.
* sieve/examples/ex-4.1.sv: Likewise.
* sieve/examples/ex-4.2.sv: Likewise.
* sieve/examples/ex-4.4a.sv: Likewise.
* sieve/examples/ex-4.4b.sv: Likewise.
* sieve/examples/ex-4.5.sv: Likewise.
* sieve/examples/ex-5.1.sv: Likewise.
* sieve/examples/ex-5.7.sv: Likewise.
* sieve/examples/ex-9.sv: Likewise.
* sieve/examples/ex-save-all.sv: Likewise.
* sieve/examples/example.sv: Likewise.
* sieve/examples/exn-5.4.sv: Likewise.
* sieve/examples/t-complex.sv: Likewise.
* sieve/examples/t-exists.sv: Likewise.
* sieve/examples/t-fileinto.sv: Likewise.
* sieve/examples/t-mailutils.sv: Likewise.
commit 5026f51b543c08f9361e068b2f4300df6512473b
Author: Sergey Poznyakoff <[email protected]>
Date: Tue Jan 5 13:35:22 2010 +0200
Update copyright years.
Happy GNU year!
-----------------------------------------------------------------------
Summary of changes:
Makefile.am | 4 +-
NEWS | 4 +-
README | 3 +-
README-alpha | 3 +-
README-hacking | 2 +-
TODO | 4 +-
am/config_paths.m4 | 4 +-
am/db2.m4 | 2 +-
am/debug.m4 | 2 +-
am/enable.m4 | 3 +-
am/gsasl.m4 | 2 +-
am/guile.m4 | 2 +-
am/md5.m4 | 3 +-
am/nls.m4 | 3 +-
am/sha1.m4 | 3 +-
am/tls.m4 | 2 +-
bootstrap | 3 +-
bootstrap.conf | 3 +-
cmc/cmc_act_on.c | 3 +-
cmc/cmc_free.c | 3 +-
cmc/cmc_list.c | 3 +-
cmc/cmc_logoff.c | 3 +-
cmc/cmc_logon.c | 3 +-
cmc/cmc_look_up.c | 3 +-
cmc/cmc_query_config.c | 3 +-
cmc/cmc_read.c | 3 +-
cmc/cmc_send.c | 3 +-
cmc/cmc_send_documents.c | 3 +-
cmc/xcmc.h | 3 +-
comsat/Makefile.am | 3 +-
comsat/action.c | 4 +-
comsat/comsat.c | 4 +-
comsat/comsat.h | 4 +-
comsat/oldcfg.c | 4 +-
config/Makefile.am | 3 +-
config/mailutils-config.c | 4 +-
config/mailutils.m4 | 2 +-
config/maint.mk | 2 +-
configure.ac | 5 +-
doc/Makefile.am | 7 +-
doc/man/Makefile.am | 3 +-
doc/rfc/CMC_V1.PS.gz | Bin 91592 -> 0 bytes
doc/rfc/Makefile.am | 63 -
doc/rfc/README | 55 +
doc/rfc/rfc1413.txt | 451 --
doc/rfc/rfc1521.txt | 4539 ------------------
doc/rfc/rfc1731.txt | 339 --
doc/rfc/rfc1734.txt | 283 --
doc/rfc/rfc1738.txt | 1403 ------
doc/rfc/rfc1870.txt | 507 ---
doc/rfc/rfc1891.txt | 1739 -------
doc/rfc/rfc1892.txt | 227 -
doc/rfc/rfc1893.txt | 843 ----
doc/rfc/rfc1894.txt | 2187 ---------
doc/rfc/rfc1939.txt | 1291 ------
doc/rfc/rfc1957.txt | 115 -
doc/rfc/rfc2045.txt | 1739 -------
doc/rfc/rfc2046.txt | 2467 ----------
doc/rfc/rfc2047.txt | 843 ----
doc/rfc/rfc2049.txt | 1347 ------
doc/rfc/rfc2060-errata | 45 -
doc/rfc/rfc2060.txt | 4595 -------------------
doc/rfc/rfc2087.txt | 284 --
doc/rfc/rfc2088.txt | 115 -
doc/rfc/rfc2111.txt | 283 --
doc/rfc/rfc2177.txt | 164 -
doc/rfc/rfc2180.txt | 787 ----
doc/rfc/rfc2192.txt | 899 ----
doc/rfc/rfc2193.txt | 507 ---
doc/rfc/rfc2195.txt | 283 --
doc/rfc/rfc2221.txt | 283 --
doc/rfc/rfc2222.txt | 899 ----
doc/rfc/rfc2231.txt | 564 ---
doc/rfc/rfc2245.txt | 283 --
doc/rfc/rfc2298.txt | 1571 -------
doc/rfc/rfc2342.txt | 563 ---
doc/rfc/rfc2368.txt | 563 ---
doc/rfc/rfc2384.txt | 451 --
doc/rfc/rfc2444.txt | 395 --
doc/rfc/rfc2449.txt | 1067 -----
doc/rfc/rfc2595.txt | 843 ----
doc/rfc/rfc2683.txt | 1291 ------
doc/rfc/rfc2808.txt | 619 ---
doc/rfc/rfc2821.txt | 4427 ------------------
doc/rfc/rfc2822.txt | 2859 ------------
doc/rfc/rfc2831.txt | 1515 -------
doc/rfc/rfc3028.txt | 2019 ---------
doc/rfc/rfc3206.txt | 339 --
doc/rfc/rfc3348.txt | 339 --
doc/rfc/rfc3431.txt | 452 --
doc/rfc/rfc3501.txt | 6052 -------------------------
doc/rfc/rfc3691.txt | 283 --
doc/rfc/rfc4314.txt | 1515 -------
doc/rfc/rfc821.txt | 4050 -----------------
doc/rfc/rfc822.txt | 2901 ------------
doc/rfc/rfc934.txt | 571 ---
doc/rfc/sasl-mechanisms | 114 -
doc/texinfo/COPYING.DOC | 2 +-
doc/texinfo/Makefile.am | 4 +-
doc/texinfo/address.texi | 2 +-
doc/texinfo/attribute.texi | 2 +-
doc/texinfo/auth.texi | 2 +-
doc/texinfo/body.texi | 4 +-
doc/texinfo/c-api.texi | 4 +-
doc/texinfo/encoding.texi | 4 +-
doc/texinfo/envelope.texi | 4 +-
doc/texinfo/fdl.texi | 3 +-
doc/texinfo/folder.texi | 4 +-
doc/texinfo/framework.texi | 4 +-
doc/texinfo/gendocs_template | 2 +-
doc/texinfo/getdate.texi | 2 +-
doc/texinfo/headers.texi | 4 +-
doc/texinfo/imap4.texi | 4 +-
doc/texinfo/iterator.texi | 2 +-
doc/texinfo/libmu_auth.texi | 4 +-
doc/texinfo/libmu_scm.texi | 4 +-
doc/texinfo/libmu_sieve.texi | 4 +-
doc/texinfo/locker.texi | 4 +-
doc/texinfo/mailbox.texi | 4 +-
doc/texinfo/mailcap.texi | 4 +-
doc/texinfo/maildir.texi | 4 +-
doc/texinfo/mailer.texi | 4 +-
doc/texinfo/mailutils.texi | 4 +-
doc/texinfo/mastermenu.el | 2 +-
doc/texinfo/mbox.texi | 4 +-
doc/texinfo/message.texi | 4 +-
doc/texinfo/mh.texi | 4 +-
doc/texinfo/mime.texi | 4 +-
doc/texinfo/mom.texi | 4 +-
doc/texinfo/mu-mh.texi | 2 +-
doc/texinfo/muint.texi | 2 +-
doc/texinfo/nntp.texi | 4 +-
doc/texinfo/parse822.texi | 4 +-
doc/texinfo/programs.texi | 4 +-
doc/texinfo/sendmail.texi | 4 +-
doc/texinfo/sieve.texi | 4 +-
doc/texinfo/smtp.texi | 2 +-
doc/texinfo/stream.texi | 2 +-
doc/texinfo/url.texi | 2 +-
doc/texinfo/usage.texi | 4 +-
dotlock/Makefile.am | 2 +-
dotlock/dotlock.c | 4 +-
examples/Makefile.am | 4 +-
examples/aclck.c | 4 +-
examples/addr.c | 4 +-
examples/argcv.c | 2 +-
examples/base64.c | 4 +-
examples/config/Makefile.am | 3 +-
examples/config/mailutils.dict | 2 +-
examples/config/mailutils.schema | 2 +-
examples/cpp/Makefile.am | 3 +-
examples/cpp/addr.cc | 3 +-
examples/cpp/http.cc | 3 +-
examples/cpp/iconv.cc | 3 +-
examples/cpp/listop.cc | 3 +-
examples/cpp/lsf.cc | 2 +-
examples/cpp/mailcap.cc | 3 +-
examples/cpp/mimetest.cc | 2 +-
examples/cpp/msg-send.cc | 2 +-
examples/cpp/murun.cc | 3 +-
examples/cpp/sfrom.cc | 3 +-
examples/cpp/url-parse.cc | 3 +-
examples/decode2047.c | 2 +-
examples/echosrv.c | 2 +-
examples/encode2047.c | 2 +-
examples/header.c | 2 +-
examples/http.c | 3 +-
examples/iconv.c | 2 +-
examples/listop.c | 3 +-
examples/lsf.c | 2 +-
examples/mailcap.c | 4 +-
examples/mimetest.c | 4 +-
examples/msg-send.c | 3 +-
examples/mta.c | 4 +-
examples/muauth.c | 2 +-
examples/muemail.c | 3 +-
examples/murun.c | 2 +-
examples/nntpclient.c | 3 +-
examples/numaddr.c | 4 +-
examples/pop3client.c | 3 +-
examples/python/Makefile.am | 2 +-
examples/python/addr.py | 2 +-
examples/python/auth.py | 2 +-
examples/python/iconv.py | 2 +-
examples/python/lsf.py | 2 +-
examples/python/mailcap.py | 2 +-
examples/python/mimetest.py | 2 +-
examples/python/msg-send.py | 2 +-
examples/python/sfrom.py | 2 +-
examples/python/url-parse.py | 2 +-
examples/scheme/Makefile.am | 2 +-
examples/scheme/reply.scm | 3 +-
examples/sfrom.c | 4 +-
examples/url-parse.c | 3 +-
frm/Makefile.am | 4 +-
frm/common.c | 4 +-
frm/frm.c | 4 +-
frm/frm.h | 2 +-
frm/from.c | 3 +-
frm/testsuite/Makefile.am | 2 +-
frm/testsuite/frm/test.exp | 2 +-
guimb/Makefile.am | 3 +-
guimb/collect.c | 4 +-
guimb/guimb.h | 4 +-
guimb/main.c | 4 +-
guimb/scm/Makefile.am | 3 +-
guimb/scm/mimeheader.scm | 3 +-
guimb/scm/numaddr.scm | 3 +-
guimb/scm/redirect.scm | 3 +-
guimb/scm/reject.scm | 3 +-
guimb/scm/sieve-core.scm | 3 +-
guimb/scm/sieve.scm.in | 4 +-
guimb/scm/vacation.scm | 3 +-
guimb/util.c | 4 +-
imap4d/Makefile.am | 4 +-
imap4d/append.c | 4 +-
imap4d/auth_gsasl.c | 4 +-
imap4d/auth_gss.c | 4 +-
imap4d/authenticate.c | 4 +-
imap4d/bye.c | 4 +-
imap4d/capability.c | 4 +-
imap4d/check.c | 3 +-
imap4d/close.c | 4 +-
imap4d/commands.c | 3 +-
imap4d/copy.c | 4 +-
imap4d/create.c | 3 +-
imap4d/delete.c | 3 +-
imap4d/examine.c | 3 +-
imap4d/expunge.c | 3 +-
imap4d/fetch.c | 4 +-
imap4d/id.c | 2 +-
imap4d/idle.c | 3 +-
imap4d/imap4d.c | 4 +-
imap4d/imap4d.h | 4 +-
imap4d/list.c | 4 +-
imap4d/login.c | 4 +-
imap4d/logout.c | 3 +-
imap4d/lsub.c | 3 +-
imap4d/namespace.c | 4 +-
imap4d/noop.c | 3 +-
imap4d/parsebuf.c | 2 +-
imap4d/preauth.c | 4 +-
imap4d/rename.c | 4 +-
imap4d/search.c | 4 +-
imap4d/select.c | 4 +-
imap4d/signal.c | 4 +-
imap4d/starttls.c | 3 +-
imap4d/status.c | 4 +-
imap4d/store.c | 4 +-
imap4d/subscribe.c | 3 +-
imap4d/sync.c | 3 +-
imap4d/testsuite/Makefile.am | 2 +-
imap4d/testsuite/imap4d.rcin | 2 +-
imap4d/testsuite/imap4d/IDEF0955.exp | 2 +-
imap4d/testsuite/imap4d/IDEF0956.exp | 2 +-
imap4d/testsuite/imap4d/anystate.exp | 2 +-
imap4d/testsuite/imap4d/append.exp | 2 +-
imap4d/testsuite/imap4d/create.exp | 2 +-
imap4d/testsuite/imap4d/examine.exp | 2 +-
imap4d/testsuite/imap4d/expunge.exp | 2 +-
imap4d/testsuite/imap4d/fetch.exp | 2 +-
imap4d/testsuite/imap4d/list.exp | 2 +-
imap4d/testsuite/imap4d/search.exp | 2 +-
imap4d/testsuite/imap4d/x.exp | 2 +-
imap4d/testsuite/lib/imap4d.exp | 2 +-
imap4d/uid.c | 3 +-
imap4d/unsubscribe.c | 3 +-
imap4d/util.c | 4 +-
include/Makefile.am | 2 +-
include/mailutils/Makefile.am | 4 +-
include/mailutils/acl.h | 2 +-
include/mailutils/address.h | 4 +-
include/mailutils/alloc.h | 2 +-
include/mailutils/argcv.h | 3 +-
include/mailutils/assoc.h | 2 +-
include/mailutils/attribute.h | 4 +-
include/mailutils/auth.h | 4 +-
include/mailutils/body.h | 3 +-
include/mailutils/cctype.h | 2 +-
include/mailutils/cfg.h | 2 +-
include/mailutils/cpp/Makefile.am | 2 +-
include/mailutils/cpp/address.h | 3 +-
include/mailutils/cpp/attribute.h | 3 +-
include/mailutils/cpp/body.h | 2 +-
include/mailutils/cpp/debug.h | 2 +-
include/mailutils/cpp/envelope.h | 2 +-
include/mailutils/cpp/error.h | 3 +-
include/mailutils/cpp/filter.h | 3 +-
include/mailutils/cpp/folder.h | 2 +-
include/mailutils/cpp/header.h | 3 +-
include/mailutils/cpp/iterator.h | 3 +-
include/mailutils/cpp/list.h | 3 +-
include/mailutils/cpp/mailbox.h | 3 +-
include/mailutils/cpp/mailcap.h | 3 +-
include/mailutils/cpp/mailer.h | 3 +-
include/mailutils/cpp/mailutils.h | 3 +-
include/mailutils/cpp/message.h | 3 +-
include/mailutils/cpp/mime.h | 2 +-
include/mailutils/cpp/mutil.h | 2 +-
include/mailutils/cpp/pop3.h | 3 +-
include/mailutils/cpp/registrar.h | 2 +-
include/mailutils/cpp/secret.h | 2 +-
include/mailutils/cpp/sieve.h | 2 +-
include/mailutils/cpp/stream.h | 3 +-
include/mailutils/cpp/url.h | 3 +-
include/mailutils/cstr.h | 2 +-
include/mailutils/daemon.h | 2 +-
include/mailutils/debug.hm4 | 3 +-
include/mailutils/diag.h | 3 +-
include/mailutils/envelope.h | 3 +-
include/mailutils/errno.hin | 4 +-
include/mailutils/error.h | 3 +-
include/mailutils/filter.h | 3 +-
include/mailutils/folder.h | 4 +-
include/mailutils/gocs.h | 2 +-
include/mailutils/gsasl.h | 4 +-
include/mailutils/guile.h | 4 +-
include/mailutils/header.h | 3 +-
include/mailutils/io.h | 2 +-
include/mailutils/iterator.h | 3 +-
include/mailutils/kwd.h | 2 +-
include/mailutils/ldap.h | 2 +-
include/mailutils/libargp.h | 4 +-
include/mailutils/libcfg.h | 2 +-
include/mailutils/list.h | 3 +-
include/mailutils/locker.h | 4 +-
include/mailutils/mailbox.h | 4 +-
include/mailutils/mailcap.h | 4 +-
include/mailutils/mailer.h | 4 +-
include/mailutils/mailutils.h | 4 +-
include/mailutils/md5.h | 4 +-
include/mailutils/message.h | 4 +-
include/mailutils/mime.h | 4 +-
include/mailutils/monitor.h | 3 +-
include/mailutils/mu_auth.h | 3 +-
include/mailutils/mutil.h | 4 +-
include/mailutils/nls.h | 3 +-
include/mailutils/nntp.h | 2 +-
include/mailutils/observer.h | 3 +-
include/mailutils/opool.h | 2 +-
include/mailutils/pam.h | 4 +-
include/mailutils/parse822.h | 4 +-
include/mailutils/pop3.h | 4 +-
include/mailutils/progmailer.h | 2 +-
include/mailutils/property.h | 4 +-
include/mailutils/python.h | 2 +-
include/mailutils/radius.h | 4 +-
include/mailutils/refcount.h | 4 +-
include/mailutils/registrar.h | 4 +-
include/mailutils/secret.h | 2 +-
include/mailutils/server.h | 2 +-
include/mailutils/sha1.h | 3 +-
include/mailutils/sieve.h | 4 +-
include/mailutils/sql.h | 3 +-
include/mailutils/stream.h | 3 +-
include/mailutils/sys/Makefile.am | 2 +-
include/mailutils/sys/nntp.h | 2 +-
include/mailutils/sys/pop3.h | 4 +-
include/mailutils/syslog.h | 2 +-
include/mailutils/tls.h | 3 +-
include/mailutils/types.hin | 4 +-
include/mailutils/url.h | 4 +-
include/mailutils/vartab.h | 2 +-
include/mailutils/version.h | 2 +-
lib/Makefile.am | 4 +-
lib/mailcap.c | 2 +-
lib/mu_asprintf.h | 2 +-
lib/mu_dbm.c | 4 +-
lib/mu_dbm.h | 4 +-
lib/mu_umaxtostr.c | 2 +-
lib/muaux.h | 2 +-
lib/signal.c | 2 +-
lib/strexit.c | 2 +-
lib/tcpwrap.c | 4 +-
lib/tcpwrap.h | 4 +-
lib/userprivs.c | 2 +-
lib/utmp.c | 2 +-
libmu_argp/Makefile.am | 2 +-
libmu_argp/auth.c | 2 +-
libmu_argp/cmdline.c | 2 +-
libmu_argp/cmdline.h | 2 +-
libmu_argp/common.c | 2 +-
libmu_argp/compat.c | 2 +-
libmu_argp/mu_argp.c | 4 +-
libmu_argp/mu_argp.h | 4 +-
libmu_argp/muinit.c | 2 +-
libmu_argp/sieve.c | 4 +-
libmu_argp/tls.c | 2 +-
libmu_auth/Makefile.am | 3 +-
libmu_auth/gsasl.c | 3 +-
libmu_auth/lbuf.c | 2 +-
libmu_auth/lbuf.h | 2 +-
libmu_auth/ldap.c | 3 +-
libmu_auth/pam.c | 3 +-
libmu_auth/radius.c | 3 +-
libmu_auth/sql.c | 4 +-
libmu_auth/sql.h | 2 +-
libmu_auth/tls.c | 3 +-
libmu_auth/virtual.c | 3 +-
libmu_cfg/Makefile.am | 2 +-
libmu_cfg/acl.c | 2 +-
libmu_cfg/auth.c | 2 +-
libmu_cfg/common.c | 2 +-
libmu_cfg/gsasl.c | 2 +-
libmu_cfg/init.c | 2 +-
libmu_cfg/ldap.c | 2 +-
libmu_cfg/pam.c | 2 +-
libmu_cfg/radius.c | 2 +-
libmu_cfg/sieve.c | 2 +-
libmu_cfg/sql.c | 2 +-
libmu_cfg/tls.c | 2 +-
libmu_cfg/virtdomain.c | 2 +-
libmu_cpp/Makefile.am | 3 +-
libmu_cpp/address.cc | 3 +-
libmu_cpp/attribute.cc | 2 +-
libmu_cpp/body.cc | 2 +-
libmu_cpp/debug.cc | 2 +-
libmu_cpp/envelope.cc | 2 +-
libmu_cpp/filter.cc | 3 +-
libmu_cpp/folder.cc | 2 +-
libmu_cpp/header.cc | 3 +-
libmu_cpp/iterator.cc | 3 +-
libmu_cpp/list.cc | 3 +-
libmu_cpp/mailbox.cc | 3 +-
libmu_cpp/mailcap.cc | 3 +-
libmu_cpp/mailer.cc | 3 +-
libmu_cpp/message.cc | 3 +-
libmu_cpp/mime.cc | 2 +-
libmu_cpp/mutil.cc | 2 +-
libmu_cpp/pop3.cc | 3 +-
libmu_cpp/registrar.cc | 2 +-
libmu_cpp/secret.cc | 2 +-
libmu_cpp/sieve.cc | 2 +-
libmu_cpp/stream.cc | 3 +-
libmu_cpp/url.cc | 3 +-
libmu_scm/Makefile.am | 4 +-
libmu_scm/mailutils.scm.in | 3 +-
libmu_scm/mu_address.c | 4 +-
libmu_scm/mu_body.c | 4 +-
libmu_scm/mu_dbgport.c | 2 +-
libmu_scm/mu_guile.c | 2 +-
libmu_scm/mu_logger.c | 3 +-
libmu_scm/mu_mailbox.c | 3 +-
libmu_scm/mu_message.c | 4 +-
libmu_scm/mu_mime.c | 3 +-
libmu_scm/mu_port.c | 4 +-
libmu_scm/mu_scm.c | 4 +-
libmu_scm/mu_scm.h | 4 +-
libmu_scm/mu_util.c | 3 +-
libmu_sieve/Makefile.am | 4 +-
libmu_sieve/actions.c | 4 +-
libmu_sieve/comparator.c | 4 +-
libmu_sieve/conf.c | 4 +-
libmu_sieve/extensions/Makefile.am | 4 +-
libmu_sieve/extensions/list.c | 3 +-
libmu_sieve/extensions/moderator.c | 2 +-
libmu_sieve/extensions/pipe.c | 2 +-
libmu_sieve/extensions/spamd.c | 4 +-
libmu_sieve/extensions/timestamp.c | 2 +-
libmu_sieve/extensions/vacation.c | 2 +-
libmu_sieve/load.c | 4 +-
libmu_sieve/prog.c | 4 +-
libmu_sieve/register.c | 4 +-
libmu_sieve/relational.c | 3 +-
libmu_sieve/require.c | 4 +-
libmu_sieve/runtime.c | 4 +-
libmu_sieve/sieve-priv.h | 4 +-
libmu_sieve/sieve.l | 4 +-
libmu_sieve/sieve.y | 4 +-
libmu_sieve/tests.c | 4 +-
libmu_sieve/util.c | 4 +-
libproto/Makefile.am | 2 +-
libproto/imap/Makefile.am | 3 +-
libproto/imap/folder.c | 4 +-
libproto/imap/mbox.c | 4 +-
libproto/imap/url.c | 3 +-
libproto/include/Makefile.am | 4 +-
libproto/include/amd.h | 4 +-
libproto/include/attribute0.h | 3 +-
libproto/include/auth0.h | 4 +-
libproto/include/body0.h | 3 +-
libproto/include/debug0.h | 3 +-
libproto/include/envelope0.h | 3 +-
libproto/include/filter0.h | 3 +-
libproto/include/folder0.h | 3 +-
libproto/include/header0.h | 3 +-
libproto/include/imap0.h | 4 +-
libproto/include/iterator0.h | 3 +-
libproto/include/list0.h | 3 +-
libproto/include/mailbox0.h | 3 +-
libproto/include/mailer0.h | 4 +-
libproto/include/message0.h | 3 +-
libproto/include/mime0.h | 3 +-
libproto/include/monitor0.h | 2 +-
libproto/include/observer0.h | 3 +-
libproto/include/property0.h | 3 +-
libproto/include/registrar0.h | 4 +-
libproto/include/stream0.h | 3 +-
libproto/include/url0.h | 3 +-
libproto/maildir/Makefile.am | 3 +-
libproto/maildir/folder.c | 2 +-
libproto/maildir/maildir.h | 2 +-
libproto/maildir/mbox.c | 4 +-
libproto/mailer/Makefile.am | 2 +-
libproto/mailer/mbox.c | 2 +-
libproto/mailer/prog.c | 2 +-
libproto/mailer/remote.c | 2 +-
libproto/mailer/sendmail.c | 4 +-
libproto/mailer/smtp.c | 4 +-
libproto/mbox/Makefile.am | 3 +-
libproto/mbox/folder.c | 4 +-
libproto/mbox/mbox.c | 4 +-
libproto/mbox/mbox0.h | 2 +-
libproto/mbox/mboxscan.c | 4 +-
libproto/mh/Makefile.am | 3 +-
libproto/mh/folder.c | 4 +-
libproto/mh/mbox.c | 4 +-
libproto/nntp/Makefile.am | 3 +-
libproto/nntp/folder.c | 2 +-
libproto/nntp/mbox.c | 2 +-
libproto/nntp/nntp0.h | 2 +-
libproto/nntp/nntp_article.c | 3 +-
libproto/nntp/nntp_body.c | 3 +-
libproto/nntp/nntp_carrier.c | 2 +-
libproto/nntp/nntp_connect.c | 2 +-
libproto/nntp/nntp_create.c | 2 +-
libproto/nntp/nntp_date.c | 3 +-
libproto/nntp/nntp_debug.c | 2 +-
libproto/nntp/nntp_destroy.c | 2 +-
libproto/nntp/nntp_disconnect.c | 2 +-
libproto/nntp/nntp_group.c | 2 +-
libproto/nntp/nntp_head.c | 3 +-
libproto/nntp/nntp_help.c | 3 +-
libproto/nntp/nntp_ihave.c | 3 +-
libproto/nntp/nntp_iterator.c | 2 +-
libproto/nntp/nntp_last.c | 2 +-
libproto/nntp/nntp_list_active.c | 2 +-
libproto/nntp/nntp_list_distribpats.c | 2 +-
libproto/nntp/nntp_list_distributions.c | 2 +-
libproto/nntp/nntp_list_extensions.c | 2 +-
libproto/nntp/nntp_list_newsgroups.c | 2 +-
libproto/nntp/nntp_list_times.c | 2 +-
libproto/nntp/nntp_mode_reader.c | 3 +-
libproto/nntp/nntp_newgroups.c | 3 +-
libproto/nntp/nntp_newnews.c | 3 +-
libproto/nntp/nntp_next.c | 2 +-
libproto/nntp/nntp_post.c | 3 +-
libproto/nntp/nntp_quit.c | 2 +-
libproto/nntp/nntp_readline.c | 2 +-
libproto/nntp/nntp_response.c | 2 +-
libproto/nntp/nntp_sendline.c | 2 +-
libproto/nntp/nntp_stat.c | 3 +-
libproto/nntp/nntp_stream.c | 2 +-
libproto/nntp/nntp_timeout.c | 2 +-
libproto/nntp/url.c | 2 +-
libproto/pop/Makefile.am | 3 +-
libproto/pop/folder.c | 4 +-
libproto/pop/mbox.c | 4 +-
libproto/pop/pop3_apop.c | 4 +-
libproto/pop/pop3_capa.c | 3 +-
libproto/pop/pop3_carrier.c | 2 +-
libproto/pop/pop3_connect.c | 2 +-
libproto/pop/pop3_create.c | 2 +-
libproto/pop/pop3_debug.c | 2 +-
libproto/pop/pop3_dele.c | 3 +-
libproto/pop/pop3_destroy.c | 2 +-
libproto/pop/pop3_disconnect.c | 3 +-
libproto/pop/pop3_iterator.c | 2 +-
libproto/pop/pop3_list.c | 3 +-
libproto/pop/pop3_lista.c | 3 +-
libproto/pop/pop3_noop.c | 3 +-
libproto/pop/pop3_pass.c | 2 +-
libproto/pop/pop3_quit.c | 3 +-
libproto/pop/pop3_readline.c | 2 +-
libproto/pop/pop3_response.c | 2 +-
libproto/pop/pop3_retr.c | 3 +-
libproto/pop/pop3_rset.c | 3 +-
libproto/pop/pop3_sendline.c | 2 +-
libproto/pop/pop3_stat.c | 3 +-
libproto/pop/pop3_stls.c | 3 +-
libproto/pop/pop3_stream.c | 2 +-
libproto/pop/pop3_timeout.c | 2 +-
libproto/pop/pop3_top.c | 3 +-
libproto/pop/pop3_uidl.c | 3 +-
libproto/pop/pop3_uidla.c | 2 +-
libproto/pop/pop3_user.c | 2 +-
libproto/pop/url.c | 4 +-
maidag/Makefile.am | 2 +-
maidag/deliver.c | 4 +-
maidag/forward.c | 4 +-
maidag/guile.c | 4 +-
maidag/lmtp.c | 2 +-
maidag/maidag.c | 2 +-
maidag/maidag.h | 2 +-
maidag/mailquota.c | 4 +-
maidag/mailtmp.c | 4 +-
maidag/python.c | 2 +-
maidag/script.c | 4 +-
maidag/sieve.c | 4 +-
maidag/util.c | 2 +-
mail/Makefile.am | 3 +-
mail/alias.c | 3 +-
mail/alt.c | 4 +-
mail/cd.c | 2 +-
mail/copy.c | 4 +-
mail/decode.c | 4 +-
mail/delete.c | 4 +-
mail/dp.c | 2 +-
mail/echo.c | 3 +-
mail/edit.c | 3 +-
mail/envelope.c | 2 +-
mail/eq.c | 4 +-
mail/escape.c | 4 +-
mail/exit.c | 3 +-
mail/file.c | 3 +-
mail/folders.c | 3 +-
mail/followup.c | 4 +-
mail/from.c | 4 +-
mail/headers.c | 4 +-
mail/help.c | 3 +-
mail/hold.c | 3 +-
mail/if.c | 3 +-
mail/inc.c | 3 +-
mail/list.c | 3 +-
mail/mail.c | 4 +-
mail/mail.h | 4 +-
mail/mailline.c | 4 +-
mail/mailvar.c | 2 +-
mail/mbox.c | 3 +-
mail/msgset.y | 4 +-
mail/next.c | 4 +-
mail/page.c | 2 +-
mail/pipe.c | 3 +-
mail/previous.c | 4 +-
mail/print.c | 4 +-
mail/quit.c | 4 +-
mail/reply.c | 4 +-
mail/retain.c | 4 +-
mail/save.c | 2 +-
mail/send.c | 4 +-
mail/set.c | 2 +-
mail/setenv.c | 3 +-
mail/shell.c | 3 +-
mail/size.c | 3 +-
mail/source.c | 3 +-
mail/struct.c | 2 +-
mail/summary.c | 3 +-
mail/table.c | 3 +-
mail/tag.c | 4 +-
mail/testsuite/Makefile.am | 2 +-
mail/testsuite/if.mail | 2 +-
mail/testsuite/lib/mail.exp | 2 +-
mail/testsuite/mail/alias.exp | 2 +-
mail/testsuite/mail/folder.exp | 2 +-
mail/testsuite/mail/if.exp | 2 +-
mail/testsuite/mail/read.exp | 2 +-
mail/testsuite/mail/send.exp | 2 +-
mail/testsuite/mail/tag.exp | 2 +-
mail/testsuite/mail/write.exp | 2 +-
mail/testsuite/mail/z.exp | 2 +-
mail/testsuite/makespool | 2 +-
mail/top.c | 4 +-
mail/touch.c | 3 +-
mail/unalias.c | 3 +-
mail/undelete.c | 3 +-
mail/unset.c | 2 +-
mail/util.c | 4 +-
mail/version.c | 3 +-
mail/visual.c | 3 +-
mail/write.c | 4 +-
mail/z.c | 3 +-
mailbox/Makefile.am | 4 +-
mailbox/acl.c | 2 +-
mailbox/address.c | 4 +-
mailbox/alloc.c | 2 +-
mailbox/amd.c | 4 +-
mailbox/argcv.c | 4 +-
mailbox/asnprintf.c | 2 +-
mailbox/asprintf.c | 2 +-
mailbox/assoc.c | 2 +-
mailbox/attachment.c | 4 +-
mailbox/attribute.c | 4 +-
mailbox/auth.c | 4 +-
mailbox/base64.c | 2 +-
mailbox/body.c | 4 +-
mailbox/cfg_driver.c | 2 +-
mailbox/cfg_format.c | 2 +-
mailbox/cfg_lexer.l | 4 +-
mailbox/cfg_parser.y | 2 +-
mailbox/cstrcasecmp.c | 2 +-
mailbox/cstrlower.c | 2 +-
mailbox/cstrupper.c | 2 +-
mailbox/daemon.c | 3 +-
mailbox/date.c | 4 +-
mailbox/dbgstderr.c | 3 +-
mailbox/dbgsyslog.c | 3 +-
mailbox/debug.c | 4 +-
mailbox/diag.c | 4 +-
mailbox/envelope.c | 3 +-
mailbox/errors | 2 +-
mailbox/fgetpwent.c | 3 +-
mailbox/file_stream.c | 4 +-
mailbox/filter.c | 4 +-
mailbox/filter_iconv.c | 2 +-
mailbox/filter_rfc822.c | 3 +-
mailbox/filter_trans.c | 4 +-
mailbox/folder.c | 4 +-
mailbox/gdebug.c | 4 +-
mailbox/gocs.c | 2 +-
mailbox/hdritr.c | 2 +-
mailbox/header.c | 4 +-
mailbox/ipsrv.c | 2 +-
mailbox/iterator.c | 3 +-
mailbox/kwd.c | 2 +-
mailbox/list.c | 4 +-
mailbox/locale.c | 2 +-
mailbox/locker.c | 4 +-
mailbox/mailbox.c | 4 +-
mailbox/mailcap.c | 4 +-
mailbox/mailer.c | 4 +-
mailbox/mapfile_stream.c | 3 +-
mailbox/mbx_default.c | 4 +-
mailbox/md5.c | 2 +-
mailbox/memory_stream.c | 3 +-
mailbox/message.c | 4 +-
mailbox/message_stream.c | 4 +-
mailbox/mime.c | 4 +-
mailbox/mkfilename.c | 2 +-
mailbox/monitor.c | 3 +-
mailbox/msrv.c | 2 +-
mailbox/mu_auth.c | 3 +-
mailbox/muctype.c | 2 +-
mailbox/muerrno.cin | 4 +-
mailbox/muerror.c | 3 +-
mailbox/munre.c | 4 +-
mailbox/mutil.c | 4 +-
mailbox/nls.c | 3 +-
mailbox/observer.c | 3 +-
mailbox/opool.c | 2 +-
mailbox/parse822.c | 4 +-
mailbox/parsedate.y | 2 +-
mailbox/permstr.c | 2 +-
mailbox/progmailer.c | 4 +-
mailbox/property.c | 4 +-
mailbox/refcount.c | 4 +-
mailbox/registrar.c | 4 +-
mailbox/rfc2047.c | 4 +-
mailbox/secret.c | 2 +-
mailbox/server.c | 2 +-
mailbox/sha1.c | 2 +-
mailbox/size_max.h | 2 +-
mailbox/socket_stream.c | 4 +-
mailbox/stream.c | 7 +-
mailbox/stripws.c | 2 +-
mailbox/strltrim.c | 2 +-
mailbox/strrtrim.c | 2 +-
mailbox/strskip.c | 2 +-
mailbox/syslog.c | 2 +-
mailbox/system.c | 2 +-
mailbox/tcp.c | 3 +-
mailbox/testsuite/Addrs | 2 +-
mailbox/testsuite/Argcv | 2 +-
mailbox/testsuite/Decode2047 | 2 +-
mailbox/testsuite/Encode2047 | 2 +-
mailbox/testsuite/Mailcap | 2 +-
mailbox/testsuite/Makefile.am | 2 +-
mailbox/testsuite/Mime | 2 +-
mailbox/testsuite/lib/mailbox.exp | 2 +-
mailbox/testsuite/mailbox/address.exp | 2 +-
mailbox/testsuite/mailbox/argcv.exp | 2 +-
mailbox/testsuite/mailbox/base64.exp | 2 +-
mailbox/testsuite/mailbox/decode2047.exp | 2 +-
mailbox/testsuite/mailbox/encode2047.exp | 2 +-
mailbox/testsuite/mailbox/list.exp | 2 +-
mailbox/testsuite/mailbox/mailcap.exp | 2 +-
mailbox/testsuite/mailbox/mime.exp | 2 +-
mailbox/testsuite/mailbox/url.exp | 2 +-
mailbox/ticket.c | 4 +-
mailbox/url.c | 4 +-
mailbox/vartab.c | 2 +-
mailbox/vasnprintf.c | 2 +-
mailbox/version.c | 2 +-
mailbox/wicket.c | 4 +-
maint.mk | 2 +-
mapi/MAPIAddress.c | 3 +-
mapi/MAPIDeleteMail.c | 3 +-
mapi/MAPIDetails.c | 3 +-
mapi/MAPIFindNext.c | 3 +-
mapi/MAPIFreeBuffer.c | 3 +-
mapi/MAPILogoff.c | 3 +-
mapi/MAPILogon.c | 3 +-
mapi/MAPIReadMail.c | 3 +-
mapi/MAPISaveMail.c | 3 +-
mapi/MAPISendDocuments.c | 3 +-
mapi/MAPISendMail.c | 3 +-
mapi/Makefile.am | 2 +-
mapi/mapi.h | 3 +-
messages/Makefile.am | 3 +-
messages/messages.c | 4 +-
messages/testsuite/Makefile.am | 2 +-
messages/testsuite/messages/test.exp | 2 +-
mh/Makefile.am | 3 +-
mh/ali.c | 4 +-
mh/anno.c | 3 +-
mh/burst.c | 3 +-
mh/comp.c | 4 +-
mh/compcommon.c | 2 +-
mh/fmtcheck.c | 4 +-
mh/folder.c | 4 +-
mh/forw.c | 4 +-
mh/inc.c | 4 +-
mh/install-mh.c | 3 +-
mh/mailutils-mh.eli | 2 +-
mh/mark.c | 4 +-
mh/mh.h | 4 +-
mh/mh_alias.l | 3 +-
mh/mh_alias.y | 3 +-
mh/mh_argp.c | 4 +-
mh/mh_ctx.c | 4 +-
mh/mh_fmtgram.y | 4 +-
mh/mh_format.c | 4 +-
mh/mh_format.h | 2 +-
mh/mh_getopt.c | 4 +-
mh/mh_getopt.h | 3 +-
mh/mh_global.c | 3 +-
mh/mh_init.c | 4 +-
mh/mh_list.c | 3 +-
mh/mh_msgset.c | 4 +-
mh/mh_sequence.c | 3 +-
mh/mh_stream.c | 4 +-
mh/mh_whatnow.c | 3 +-
mh/mh_whom.c | 3 +-
mh/mhl.c | 3 +-
mh/mhl.format | 2 +-
mh/mhn.c | 4 +-
mh/mhparam.c | 3 +-
mh/mhpath.c | 3 +-
mh/pick.c | 4 +-
mh/pick.h | 2 +-
mh/pick.y | 4 +-
mh/refile.c | 4 +-
mh/repl.c | 4 +-
mh/replcomps | 2 +-
mh/replgroupcomps | 2 +-
mh/rmf.c | 4 +-
mh/rmm.c | 3 +-
mh/scan.c | 4 +-
mh/send.c | 4 +-
mh/sortm.c | 4 +-
mh/whatnow.c | 2 +-
mh/whom.c | 3 +-
mimeview/Makefile.am | 2 +-
mimeview/mimetypes.l | 2 +-
mimeview/mimetypes.y | 2 +-
mimeview/mimeview.c | 3 +-
mimeview/mimeview.h | 2 +-
movemail/Makefile.am | 4 +-
movemail/movemail.c | 4 +-
mu-aux/Makefile.am | 3 +-
mu-aux/debugdef.m4 | 2 +-
mu-aux/generr.awk | 2 +-
mu-aux/gylwrap | 3 +-
mu-aux/sqlmod.sh | 2 +-
mu-aux/texify.sed | 2 +-
paths | 2 +-
po/POTFILES.in | 3 +-
pop3d/Makefile.am | 4 +-
pop3d/apop.c | 4 +-
pop3d/auth.c | 2 +-
pop3d/bulletin.c | 2 +-
pop3d/capa.c | 3 +-
pop3d/cmd.c | 2 +-
pop3d/dele.c | 4 +-
pop3d/expire.c | 3 +-
pop3d/extra.c | 4 +-
pop3d/list.c | 4 +-
pop3d/lock.c | 4 +-
pop3d/logindelay.c | 2 +-
pop3d/noop.c | 3 +-
pop3d/pop3d.c | 4 +-
pop3d/pop3d.h | 4 +-
pop3d/popauth.c | 4 +-
pop3d/quit.c | 4 +-
pop3d/retr.c | 4 +-
pop3d/rset.c | 3 +-
pop3d/signal.c | 4 +-
pop3d/stat.c | 4 +-
pop3d/stls.c | 2 +-
pop3d/testsuite/Makefile.am | 2 +-
pop3d/testsuite/lib/pop3d.exp | 2 +-
pop3d/testsuite/pop3d.rcin | 2 +-
pop3d/testsuite/pop3d/read.exp | 2 +-
pop3d/top.c | 3 +-
pop3d/uidl.c | 4 +-
pop3d/user.c | 4 +-
python/Makefile.am | 2 +-
python/libmu_py/Makefile.am | 2 +-
python/libmu_py/address.c | 2 +-
python/libmu_py/attribute.c | 2 +-
python/libmu_py/auth.c | 2 +-
python/libmu_py/body.c | 2 +-
python/libmu_py/c_api.c | 2 +-
python/libmu_py/debug.c | 2 +-
python/libmu_py/envelope.c | 2 +-
python/libmu_py/error.c | 2 +-
python/libmu_py/filter.c | 2 +-
python/libmu_py/folder.c | 2 +-
python/libmu_py/header.c | 2 +-
python/libmu_py/libmu_py.c | 2 +-
python/libmu_py/libmu_py.h | 2 +-
python/libmu_py/list.c | 2 +-
python/libmu_py/mailbox.c | 2 +-
python/libmu_py/mailcap.c | 2 +-
python/libmu_py/mailer.c | 2 +-
python/libmu_py/message.c | 2 +-
python/libmu_py/mime.c | 2 +-
python/libmu_py/nls.c | 2 +-
python/libmu_py/registrar.c | 2 +-
python/libmu_py/script.c | 2 +-
python/libmu_py/secret.c | 2 +-
python/libmu_py/sieve.c | 2 +-
python/libmu_py/stream.c | 2 +-
python/libmu_py/url.c | 2 +-
python/libmu_py/util.c | 2 +-
python/mailutils/Makefile.am | 2 +-
python/mailutils/__init__.py | 2 +-
python/mailutils/address.py | 2 +-
python/mailutils/attribute.py | 2 +-
python/mailutils/auth.py | 2 +-
python/mailutils/body.py | 2 +-
python/mailutils/debug.py | 2 +-
python/mailutils/envelope.py | 2 +-
python/mailutils/error.py | 2 +-
python/mailutils/filter.py | 2 +-
python/mailutils/folder.py | 2 +-
python/mailutils/header.py | 2 +-
python/mailutils/mailbox.py | 2 +-
python/mailutils/mailcap.py | 2 +-
python/mailutils/mailer.py | 2 +-
python/mailutils/message.py | 2 +-
python/mailutils/mime.py | 2 +-
python/mailutils/nls.py | 2 +-
python/mailutils/registrar.py | 2 +-
python/mailutils/secret.py | 2 +-
python/mailutils/sieve.py | 2 +-
python/mailutils/stream.py | 2 +-
python/mailutils/url.py | 2 +-
python/mailutils/util.py | 2 +-
readmsg/Makefile.am | 3 +-
readmsg/msglist.c | 4 +-
readmsg/readmsg.c | 4 +-
readmsg/readmsg.h | 4 +-
readmsg/testsuite/Makefile.am | 2 +-
readmsg/testsuite/readmsg/test.exp | 2 +-
sieve/Makefile.am | 2 +-
sieve/examples/Makefile | 31 -
sieve/examples/ex-1.10.2.sv | 5 +-
sieve/examples/ex-2.3a.sv | 6 +-
sieve/examples/ex-2.5.1.sv | 18 +-
sieve/examples/ex-2.7.3.sv | 9 +-
sieve/examples/ex-3.1a.sv | 22 +-
sieve/examples/ex-3.1b.sv | 19 +-
sieve/examples/ex-3.2.sv | 4 +-
sieve/examples/ex-4.1.sv | 11 +-
sieve/examples/ex-4.2.sv | 9 +-
sieve/examples/ex-4.4a.sv | 2 +-
sieve/examples/ex-4.4b.sv | 3 +-
sieve/examples/ex-4.5.sv | 7 +-
sieve/examples/ex-5.1.sv | 7 +-
sieve/examples/ex-5.7.sv | 10 +-
sieve/examples/ex-9.sv | 32 +-
sieve/examples/ex-save-all.sv | 1 -
sieve/examples/example.sv | 19 +-
sieve/examples/exn-5.4.sv | 7 +-
sieve/examples/t-complex.sv | 80 +-
sieve/examples/t-exists.sv | 4 +-
sieve/examples/t-fileinto.sv | 12 +-
sieve/examples/t-mailutils.sv | 6 +-
sieve/sieve.c | 4 +-
sieve/testsuite/Makefile.am | 2 +-
sieve/testsuite/Redirect | 2 +-
sieve/testsuite/Reject | 2 +-
sieve/testsuite/lib/sieve.exp | 2 +-
sieve/testsuite/scripts/addr_is_all.sv | 2 +-
sieve/testsuite/scripts/addr_is_domain.sv | 2 +-
sieve/testsuite/scripts/addr_is_local.sv | 2 +-
sieve/testsuite/scripts/addr_matches.sv | 2 +-
sieve/testsuite/scripts/address.sv | 2 +-
sieve/testsuite/scripts/allof00.sv | 2 +-
sieve/testsuite/scripts/allof01.sv | 2 +-
sieve/testsuite/scripts/allof11.sv | 2 +-
sieve/testsuite/scripts/anyof00.sv | 2 +-
sieve/testsuite/scripts/anyof01.sv | 2 +-
sieve/testsuite/scripts/anyof11.sv | 2 +-
sieve/testsuite/scripts/discard.sv | 2 +-
sieve/testsuite/scripts/envelope1.sv | 2 +-
sieve/testsuite/scripts/exists1.sv | 2 +-
sieve/testsuite/scripts/exists2.sv | 2 +-
sieve/testsuite/scripts/exists3.sv | 2 +-
sieve/testsuite/scripts/false.sv | 2 +-
sieve/testsuite/scripts/fileinto.sv | 2 +-
sieve/testsuite/scripts/header-mime.sv | 2 +-
sieve/testsuite/scripts/header1.sv | 2 +-
sieve/testsuite/scripts/header2.sv | 2 +-
sieve/testsuite/scripts/header3.sv | 2 +-
sieve/testsuite/scripts/i-casemap-contains.sv | 2 +-
sieve/testsuite/scripts/i-casemap-is.sv | 2 +-
sieve/testsuite/scripts/i-casemap-matches.sv | 2 +-
sieve/testsuite/scripts/i-casemap-regex.sv | 2 +-
sieve/testsuite/scripts/i-numeric-contains.sv | 2 +-
sieve/testsuite/scripts/i-numeric-is.sv | 2 +-
sieve/testsuite/scripts/i-octet-contains.sv | 2 +-
sieve/testsuite/scripts/i-octet-is.sv | 2 +-
sieve/testsuite/scripts/i-octet-matches.sv | 2 +-
sieve/testsuite/scripts/i-octet-regex.sv | 2 +-
sieve/testsuite/scripts/keep.sv | 2 +-
sieve/testsuite/scripts/mul-addr.sv | 2 +-
sieve/testsuite/scripts/not.sv | 2 +-
sieve/testsuite/scripts/null.sv | 2 +-
sieve/testsuite/scripts/numaddr.sv | 2 +-
sieve/testsuite/scripts/redirect.sv | 2 +-
sieve/testsuite/scripts/reject.sv | 2 +-
sieve/testsuite/scripts/rel-address.sv | 2 +-
sieve/testsuite/scripts/rel-hairy.sv | 2 +-
sieve/testsuite/scripts/rel-header.sv | 2 +-
sieve/testsuite/scripts/size1.sv | 2 +-
sieve/testsuite/scripts/size2.sv | 2 +-
sieve/testsuite/scripts/stop.sv | 2 +-
sieve/testsuite/scripts/true.sv | 2 +-
sieve/testsuite/sieve/action.exp | 2 +-
sieve/testsuite/sieve/address.exp | 2 +-
sieve/testsuite/sieve/allof.exp | 2 +-
sieve/testsuite/sieve/anyof.exp | 2 +-
sieve/testsuite/sieve/compile.exp | 2 +-
sieve/testsuite/sieve/envelope.exp | 2 +-
sieve/testsuite/sieve/exists.exp | 2 +-
sieve/testsuite/sieve/ext.exp | 2 +-
sieve/testsuite/sieve/false.exp | 2 +-
sieve/testsuite/sieve/header.exp | 2 +-
sieve/testsuite/sieve/i-casemap.exp | 2 +-
sieve/testsuite/sieve/i-numeric.exp | 2 +-
sieve/testsuite/sieve/i-octet.exp | 2 +-
sieve/testsuite/sieve/mul-addr.exp | 2 +-
sieve/testsuite/sieve/not.exp | 2 +-
sieve/testsuite/sieve/redirect.exp | 2 +-
sieve/testsuite/sieve/reject.exp | 2 +-
sieve/testsuite/sieve/relational.exp | 2 +-
sieve/testsuite/sieve/size.exp | 2 +-
sieve/testsuite/sieve/true.exp | 2 +-
sql/Makefile.am | 2 +-
sql/mysql.c | 3 +-
sql/odbc.c | 2 +-
sql/postgres.c | 3 +-
sql/sql.c | 3 +-
testsuite/Makefile.am | 2 +-
testsuite/etc/mail.rc | 3 +
testsuite/etc/mailutils.rc.in | 4 +
testsuite/lib/mailutils.exp | 3 +-
1058 files changed, 1738 insertions(+), 66601 deletions(-)
delete mode 100644 doc/rfc/CMC_V1.PS.gz
delete mode 100644 doc/rfc/Makefile.am
create mode 100644 doc/rfc/README
delete mode 100644 doc/rfc/rfc1413.txt
delete mode 100644 doc/rfc/rfc1521.txt
delete mode 100644 doc/rfc/rfc1731.txt
delete mode 100644 doc/rfc/rfc1734.txt
delete mode 100644 doc/rfc/rfc1738.txt
delete mode 100644 doc/rfc/rfc1870.txt
delete mode 100644 doc/rfc/rfc1891.txt
delete mode 100644 doc/rfc/rfc1892.txt
delete mode 100644 doc/rfc/rfc1893.txt
delete mode 100644 doc/rfc/rfc1894.txt
delete mode 100644 doc/rfc/rfc1939.txt
delete mode 100644 doc/rfc/rfc1957.txt
delete mode 100644 doc/rfc/rfc2045.txt
delete mode 100644 doc/rfc/rfc2046.txt
delete mode 100644 doc/rfc/rfc2047.txt
delete mode 100644 doc/rfc/rfc2049.txt
delete mode 100644 doc/rfc/rfc2060-errata
delete mode 100644 doc/rfc/rfc2060.txt
delete mode 100644 doc/rfc/rfc2087.txt
delete mode 100644 doc/rfc/rfc2088.txt
delete mode 100644 doc/rfc/rfc2111.txt
delete mode 100644 doc/rfc/rfc2177.txt
delete mode 100644 doc/rfc/rfc2180.txt
delete mode 100644 doc/rfc/rfc2192.txt
delete mode 100644 doc/rfc/rfc2193.txt
delete mode 100644 doc/rfc/rfc2195.txt
delete mode 100644 doc/rfc/rfc2221.txt
delete mode 100644 doc/rfc/rfc2222.txt
delete mode 100644 doc/rfc/rfc2231.txt
delete mode 100644 doc/rfc/rfc2245.txt
delete mode 100644 doc/rfc/rfc2298.txt
delete mode 100644 doc/rfc/rfc2342.txt
delete mode 100644 doc/rfc/rfc2368.txt
delete mode 100644 doc/rfc/rfc2384.txt
delete mode 100644 doc/rfc/rfc2444.txt
delete mode 100644 doc/rfc/rfc2449.txt
delete mode 100644 doc/rfc/rfc2595.txt
delete mode 100644 doc/rfc/rfc2683.txt
delete mode 100644 doc/rfc/rfc2808.txt
delete mode 100644 doc/rfc/rfc2821.txt
delete mode 100644 doc/rfc/rfc2822.txt
delete mode 100644 doc/rfc/rfc2831.txt
delete mode 100644 doc/rfc/rfc3028.txt
delete mode 100644 doc/rfc/rfc3206.txt
delete mode 100644 doc/rfc/rfc3348.txt
delete mode 100644 doc/rfc/rfc3431.txt
delete mode 100644 doc/rfc/rfc3501.txt
delete mode 100644 doc/rfc/rfc3691.txt
delete mode 100644 doc/rfc/rfc4314.txt
delete mode 100644 doc/rfc/rfc821.txt
delete mode 100644 doc/rfc/rfc822.txt
delete mode 100644 doc/rfc/rfc934.txt
delete mode 100644 doc/rfc/sasl-mechanisms
delete mode 100644 sieve/examples/Makefile
diff --git a/Makefile.am b/Makefile.am
index 5cabed2..0fc2e3c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,7 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
-## Free Software Foundation, Inc.
+## Copyright (C) 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008,
+## 2009, 2010 Free Software Foundation, Inc.
##
## GNU Mailutils is free software; you can redistribute it and/or
## modify it under the terms of the GNU General Public License as
diff --git a/NEWS b/NEWS
index a4d939c..e167f1f 100644
--- a/NEWS
+++ b/NEWS
@@ -1,6 +1,6 @@
GNU mailutils NEWS -- history of user-visible changes. 2009-12-29
-Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007,
-2008, 2009 Free Software Foundation, Inc.
+Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free
+Software Foundation, Inc.
See the end of file for copying conditions.
Please send mailutils bug reports to <[email protected]>.
diff --git a/README b/README
index 8c6a4a7..3409916 100644
--- a/README
+++ b/README
@@ -342,7 +342,8 @@ by visiting http://mail.gnu.org/mailman/listinfo/bug-mailutils.
* Copyright information:
-Copyright (C) 2002, 2003, 2004, 2005, 2006, 2009 Free Software Foundation, Inc.
+Copyright (C) 2002, 2003, 2004, 2005, 2006, 2009, 2010 Free Software
+Foundation, Inc.
Permission is granted to anyone to make or distribute verbatim
copies of this document as received, in any medium, provided that
diff --git a/README-alpha b/README-alpha
index 49dfd10..39f3cfb 100644
--- a/README-alpha
+++ b/README-alpha
@@ -69,7 +69,8 @@ Now set your breakpoints and proceed as usual.
* Copyright information:
-Copyright (C) 2002, 2003, 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
+Copyright (C) 2002, 2003, 2004, 2005, 2007, 2008, 2010 Free Software
+Foundation, Inc.
Permission is granted to anyone to make or distribute verbatim copies
of this document as received, in any medium, provided that the
diff --git a/README-hacking b/README-hacking
index f18395d..91b9d64 100644
--- a/README-hacking
+++ b/README-hacking
@@ -80,7 +80,7 @@ To clean all flowgraphs, run (from the source tree root directory):
* Copyright information
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
Permission is granted to anyone to make or distribute verbatim copies
of this document as received, in any medium, provided that the
diff --git a/TODO b/TODO
index 2f2a9dc..e80dd28 100644
--- a/TODO
+++ b/TODO
@@ -1,6 +1,6 @@
GNU mailutils TODO list. 2008-08-20
-Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006,
-2007, 2008 Free Software Foundation, Inc.
+Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2010 Free
+Software Foundation, Inc.
* Configuration callback functions should not modify node->tag and node->label.
diff --git a/am/config_paths.m4 b/am/config_paths.m4
index 3960d84..1d3ea9e 100644
--- a/am/config_paths.m4
+++ b/am/config_paths.m4
@@ -1,6 +1,6 @@
#serial 1
-dnl Copyright (C) 1996, 1997, 1998, 2002, 2004, 2005, 2007,
-dnl 2009 Free Software Foundation, Inc.
+dnl Copyright (C) 1996, 1997, 1998, 2002, 2004, 2005, 2007, 2009, 2010
+dnl Free Software Foundation, Inc.
dnl
dnl Written by Miles Bader <[email protected]> and
dnl Sergey Poznyakoff <[email protected]>
diff --git a/am/db2.m4 b/am/db2.m4
index 64a8ba0..fa305ce 100644
--- a/am/db2.m4
+++ b/am/db2.m4
@@ -1,5 +1,5 @@
dnl This file is part of GNU mailutils.
-dnl Copyright (C) 2003, 2007 Free Software Foundation, Inc.
+dnl Copyright (C) 2003, 2007, 2010 Free Software Foundation, Inc.
dnl
dnl GNU Mailutils is free software; you can redistribute it and/or modify
dnl it under the terms of the GNU General Public License as published by
diff --git a/am/debug.m4 b/am/debug.m4
index 5e7de1b..8e13b52 100644
--- a/am/debug.m4
+++ b/am/debug.m4
@@ -1,5 +1,5 @@
dnl This file is part of GNU mailutils.
-dnl Copyright (C) 2001 Free Software Foundation, Inc.
+dnl Copyright (C) 2001, 2010 Free Software Foundation, Inc.
dnl
dnl This file is free software; as a special exception the author gives
dnl unlimited permission to copy and/or distribute it, with or without
diff --git a/am/enable.m4 b/am/enable.m4
index fc956a3..faf3a31 100644
--- a/am/enable.m4
+++ b/am/enable.m4
@@ -1,5 +1,6 @@
dnl This file is part of GNU mailutils.
-dnl Copyright (C) 2002, 2005, 2007, 2009 Free Software Foundation, Inc.
+dnl Copyright (C) 2002, 2005, 2007, 2009, 2010 Free Software Foundation,
+dnl Inc.
dnl
dnl This program is free software; you can redistribute it and/or modify
dnl it under the terms of the GNU General Public License as published by
diff --git a/am/gsasl.m4 b/am/gsasl.m4
index 427bd99..3ce16f0 100644
--- a/am/gsasl.m4
+++ b/am/gsasl.m4
@@ -1,5 +1,5 @@
dnl This file is part of GNU mailutils.
-dnl Copyright (C) 2003, 2007 Free Software Foundation, Inc.
+dnl Copyright (C) 2003, 2007, 2010 Free Software Foundation, Inc.
dnl
dnl GNU Mailutils is free software; you can redistribute it and/or modify
dnl it under the terms of the GNU General Public License as published by
diff --git a/am/guile.m4 b/am/guile.m4
index cf283fd..ff0a544 100644
--- a/am/guile.m4
+++ b/am/guile.m4
@@ -1,5 +1,5 @@
dnl This file is part of GNU mailutils.
-dnl Copyright (C) 2001, 2006, 2007 Free Software Foundation, Inc.
+dnl Copyright (C) 2001, 2006, 2007, 2010 Free Software Foundation, Inc.
dnl
dnl This program is free software; you can redistribute it and/or modify
dnl it under the terms of the GNU General Public License as published by
diff --git a/am/md5.m4 b/am/md5.m4
index 62e9959..ecc9c07 100644
--- a/am/md5.m4
+++ b/am/md5.m4
@@ -1,5 +1,6 @@
# md5.m4 serial 9
-dnl Copyright (C) 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
+dnl Copyright (C) 2002, 2003, 2004, 2005, 2006, 2010 Free Software
+dnl Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
dnl with or without modifications, as long as this notice is preserved.
diff --git a/am/nls.m4 b/am/nls.m4
index 7967cc2..0a4cc87 100644
--- a/am/nls.m4
+++ b/am/nls.m4
@@ -1,5 +1,6 @@
# nls.m4 serial 3 (gettext-0.15)
-dnl Copyright (C) 1995-2003, 2005-2006 Free Software Foundation, Inc.
+dnl Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
+dnl 2005, 2006, 2010 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
dnl with or without modifications, as long as this notice is preserved.
diff --git a/am/sha1.m4 b/am/sha1.m4
index 0c79150..2ee4340 100644
--- a/am/sha1.m4
+++ b/am/sha1.m4
@@ -1,5 +1,6 @@
# sha1.m4 serial 7
-dnl Copyright (C) 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
+dnl Copyright (C) 2002, 2003, 2004, 2005, 2006, 2010 Free Software
+dnl Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
dnl with or without modifications, as long as this notice is preserved.
diff --git a/am/tls.m4 b/am/tls.m4
index a95d908..8bcf191 100644
--- a/am/tls.m4
+++ b/am/tls.m4
@@ -1,5 +1,5 @@
dnl This file is part of GNU mailutils.
-dnl Copyright (C) 2003, 2007, 2009 Free Software Foundation, Inc.
+dnl Copyright (C) 2003, 2007, 2009, 2010 Free Software Foundation, Inc.
dnl
dnl GNU Mailutils is free software; you can redistribute it and/or modify
dnl it under the terms of the GNU General Public License as published by
diff --git a/bootstrap b/bootstrap
index 46a0964..f9ea1e6 100755
--- a/bootstrap
+++ b/bootstrap
@@ -2,7 +2,8 @@
# Bootstrap this package from checked-out sources.
-# Copyright (C) 2003-2008 Free Software Foundation, Inc.
+# Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008, 2010 Free Software
+# Foundation, Inc.
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
diff --git a/bootstrap.conf b/bootstrap.conf
index 3774bf2..d9e2c48 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -1,6 +1,7 @@
# Bootstrap configuration.
-# Copyright (C) 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+# Copyright (C) 2006, 2007, 2008, 2009, 2010 Free Software Foundation,
+# Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
diff --git a/cmc/cmc_act_on.c b/cmc/cmc_act_on.c
index 3dfeac6..3abd286 100644
--- a/cmc/cmc_act_on.c
+++ b/cmc/cmc_act_on.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2007, 2010 Free Software Foundation,
+ Inc.
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
diff --git a/cmc/cmc_free.c b/cmc/cmc_free.c
index 34b7c30..31a7bdb 100644
--- a/cmc/cmc_free.c
+++ b/cmc/cmc_free.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2007, 2010 Free Software Foundation,
+ Inc.
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
diff --git a/cmc/cmc_list.c b/cmc/cmc_list.c
index 7e91d7b..f831e7d 100644
--- a/cmc/cmc_list.c
+++ b/cmc/cmc_list.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2007, 2010 Free Software Foundation,
+ Inc.
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
diff --git a/cmc/cmc_logoff.c b/cmc/cmc_logoff.c
index c662854..4b56f1b 100644
--- a/cmc/cmc_logoff.c
+++ b/cmc/cmc_logoff.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2007, 2010 Free Software Foundation,
+ Inc.
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
diff --git a/cmc/cmc_logon.c b/cmc/cmc_logon.c
index 9d34f31..9dc33d7 100644
--- a/cmc/cmc_logon.c
+++ b/cmc/cmc_logon.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2007, 2010 Free Software Foundation,
+ Inc.
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
diff --git a/cmc/cmc_look_up.c b/cmc/cmc_look_up.c
index 3492f5f..2aecbd4 100644
--- a/cmc/cmc_look_up.c
+++ b/cmc/cmc_look_up.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2007, 2010 Free Software Foundation,
+ Inc.
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
diff --git a/cmc/cmc_query_config.c b/cmc/cmc_query_config.c
index 6a4f01e..5d10ae3 100644
--- a/cmc/cmc_query_config.c
+++ b/cmc/cmc_query_config.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2007, 2010 Free Software Foundation,
+ Inc.
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
diff --git a/cmc/cmc_read.c b/cmc/cmc_read.c
index e345b9b..7add8ea 100644
--- a/cmc/cmc_read.c
+++ b/cmc/cmc_read.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2007, 2010 Free Software Foundation,
+ Inc.
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
diff --git a/cmc/cmc_send.c b/cmc/cmc_send.c
index e342863..80ced54 100644
--- a/cmc/cmc_send.c
+++ b/cmc/cmc_send.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2007, 2010 Free Software Foundation,
+ Inc.
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
diff --git a/cmc/cmc_send_documents.c b/cmc/cmc_send_documents.c
index 664e21c..c4da56b 100644
--- a/cmc/cmc_send_documents.c
+++ b/cmc/cmc_send_documents.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2007, 2010 Free Software Foundation,
+ Inc.
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
diff --git a/cmc/xcmc.h b/cmc/xcmc.h
index 70cd70d..c960873 100644
--- a/cmc/xcmc.h
+++ b/cmc/xcmc.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2007, 2010 Free Software Foundation,
+ Inc.
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
diff --git a/comsat/Makefile.am b/comsat/Makefile.am
index d65bf0d..bd00831 100644
--- a/comsat/Makefile.am
+++ b/comsat/Makefile.am
@@ -1,6 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2001, 2002, 2007, 2009 Free Software Foundation, Inc.
+## Copyright (C) 2001, 2002, 2007, 2009, 2010 Free Software
+## Foundation, Inc.
##
## GNU Mailutils is free software; you can redistribute it and/or
## modify it under the terms of the GNU General Public License as
diff --git a/comsat/action.c b/comsat/action.c
index cea5473..738079b 100644
--- a/comsat/action.c
+++ b/comsat/action.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2005,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2005, 2007, 2009, 2010 Free
+ Software Foundation, Inc.
GNU Mailutils is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
diff --git a/comsat/comsat.c b/comsat/comsat.c
index a3abdae..3722f47 100644
--- a/comsat/comsat.c
+++ b/comsat/comsat.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2005,
- 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2005, 2007, 2008, 2009, 2010
+ Free Software Foundation, Inc.
GNU Mailutils is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
diff --git a/comsat/comsat.h b/comsat/comsat.h
index 59937a9..d2a932c 100644
--- a/comsat/comsat.h
+++ b/comsat/comsat.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2007,
- 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2007, 2008, 2009, 2010 Free
+ Software Foundation, Inc.
GNU Mailutils is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
diff --git a/comsat/oldcfg.c b/comsat/oldcfg.c
index b59ae72..c46cf3a 100644
--- a/comsat/oldcfg.c
+++ b/comsat/oldcfg.c
@@ -1,6 +1,6 @@
/* This file is part of GNU Mailutils.
- Copyright (C) 1998, 2001, 2002, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1998, 2001, 2002, 2005, 2007, 2009, 2010 Free Software
+ Foundation, Inc.
GNU Mailutils is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
diff --git a/config/Makefile.am b/config/Makefile.am
index 9de1363..986a234 100644
--- a/config/Makefile.am
+++ b/config/Makefile.am
@@ -1,6 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2005, 2006, 2007, 2009 Free Software Foundation, Inc.
+## Copyright (C) 2005, 2006, 2007, 2009, 2010 Free Software
+## Foundation, Inc.
##
## GNU Mailutils is free software; you can redistribute it and/or
## modify it under the terms of the GNU General Public License as
diff --git a/config/mailutils-config.c b/config/mailutils-config.c
index 1a91a0e..af4f911 100644
--- a/config/mailutils-config.c
+++ b/config/mailutils-config.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2007, 2009
- Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2007, 2009, 2010 Free Software
+ Foundation, Inc.
GNU Mailutils is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
diff --git a/config/mailutils.m4 b/config/mailutils.m4
index 3aea8c0..055d56c 100644
--- a/config/mailutils.m4
+++ b/config/mailutils.m4
@@ -1,4 +1,4 @@
-dnl Copyright (C) 2006, 2007 Free Software Foundation, Inc.
+dnl Copyright (C) 2006, 2007, 2010 Free Software Foundation, Inc.
dnl
dnl GNU Mailutils is free software; you can redistribute it and/or
dnl modify it under the terms of the GNU General Public License as
diff --git a/config/maint.mk b/config/maint.mk
index 4d51d8c..69049bf 100644
--- a/config/maint.mk
+++ b/config/maint.mk
@@ -1,5 +1,5 @@
# This file is part of GNU Mailutils.
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 2010 Free Software Foundation, Inc.
#
# Written by Sergey Poznyakoff
#
diff --git a/configure.ac b/configure.ac
index fe84ac5..84fb2af 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,7 +1,7 @@
dnl Configuration for GNU Mailutils -- a suite of utilities for electronic mail
dnl
-dnl Copyright (C) 1999,2000,2001,2002,2003,2004,2005,
-dnl 2006,2007,2008,2009 Free Software Foundation, Inc.
+dnl Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
+dnl 2008, 2009, 2010 Free Software Foundation, Inc.
dnl
dnl GNU Mailutils is free software; you can redistribute it and/or modify
dnl it under the terms of the GNU General Public License as published by
@@ -1327,7 +1327,6 @@ AC_CONFIG_FILES([
config/Makefile
doc/Makefile
doc/man/Makefile
- doc/rfc/Makefile
doc/texinfo/Makefile
dotlock/Makefile
examples/Makefile
diff --git a/doc/Makefile.am b/doc/Makefile.am
index 646169b..878bb83 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -1,6 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2000,2001,2002,2007,2009 Free Software Foundation, Inc.
+## Copyright (C) 2000, 2001, 2002, 2007, 2009, 2010 Free Software
+## Foundation, Inc.
##
## GNU Mailutils is free software; you can redistribute it and/or
## modify it under the terms of the GNU General Public License as
@@ -17,5 +18,5 @@
## Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA
## 02110-1301 USA
-SUBDIRS = texinfo rfc man
-EXTRA_DIST = ChangeLog.CVS
+SUBDIRS = texinfo man
+EXTRA_DIST = ChangeLog.CVS rfc/README
diff --git a/doc/man/Makefile.am b/doc/man/Makefile.am
index 49c0d7a..e2689a2 100644
--- a/doc/man/Makefile.am
+++ b/doc/man/Makefile.am
@@ -1,6 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2001, 2002, 2003, 2004, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2001, 2002, 2003, 2004, 2007, 2010 Free Software
+## Foundation, Inc.
##
## GNU Mailutils is free software; you can redistribute it and/or
## modify it under the terms of the GNU General Public License as
diff --git a/doc/rfc/CMC_V1.PS.gz b/doc/rfc/CMC_V1.PS.gz
deleted file mode 100644
index fbe6a1d..0000000
Binary files a/doc/rfc/CMC_V1.PS.gz and /dev/null differ
diff --git a/doc/rfc/Makefile.am b/doc/rfc/Makefile.am
deleted file mode 100644
index 419f051..0000000
--- a/doc/rfc/Makefile.am
+++ /dev/null
@@ -1,63 +0,0 @@
-## Process this file with GNU Automake to create Makefile.in
-
-## Copyright (C) 2001, 2002, 2003, 2007, 2008 Free Software Foundation, Inc.
-##
-## GNU Mailutils 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 3, or (at
-## your option) any later version.
-##
-## GNU Mailutils 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 GNU Mailutils; if not, write to the Free Software
-## Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA
-## 02110-1301 USA
-
-EXTRA_DIST = \
- rfc821.txt\
- rfc822.txt\
- rfc934.txt\
- rfc1413.txt\
- rfc1521.txt\
- rfc1731.txt\
- rfc1734.txt\
- rfc1738.txt\
- rfc1870.txt\
- rfc1939.txt\
- rfc1957.txt\
- rfc2045.txt\
- rfc2046.txt\
- rfc2047.txt\
- rfc2049.txt\
- rfc2060.txt\
- rfc2060-errata\
- rfc2087.txt\
- rfc2088.txt\
- rfc2111.txt\
- rfc2177.txt\
- rfc2180.txt\
- rfc2192.txt\
- rfc2193.txt\
- rfc2221.txt\
- rfc2245.txt\
- rfc2298.txt\
- rfc2231.txt\
- rfc2342.txt\
- rfc2368.txt\
- rfc2384.txt\
- rfc2449.txt\
- rfc2595.txt\
- rfc2683.txt\
- rfc2821.txt\
- rfc2822.txt\
- rfc3028.txt\
- rfc3206.txt\
- rfc3431.txt\
- rfc3501.txt\
- rfc3691.txt\
- rfc3348.txt\
- rfc4314.txt
diff --git a/doc/rfc/README b/doc/rfc/README
new file mode 100644
index 0000000..38d0abb
--- /dev/null
+++ b/doc/rfc/README
@@ -0,0 +1,55 @@
+This is a list of RFCs used when designing GNU Mailutils. To read any
+of them, visit http://tools.ietf.org/html/rfcNNNN, replacing NNNN with
+the actual RFC number.
+
+821 SIMPLE MAIL TRANSFER PROTOCOL
+822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES
+934 Proposed Standard for Message Encapsulation
+1413 Identification Protocol
+1521 MIME Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
+1731 IMAP4 Authentication Mechanisms
+1734 POP3 AUTHentication command
+1738 Uniform Resource Locators (URL)
+1870 SMTP Service Extension for Message Size Declaration
+1891 SMTP Service Extension for Delivery Status Notifications
+1892 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages
+1893 Enhanced Mail System Status Codes
+1894 An Extensible Message Format for Delivery Status Notifications
+1939 Post Office Protocol - Version 3
+1957 Some Observations on Implementations of the Post Office Protocol (POP3)
+2045 MIME Part One: Format of Internet Message Bodies
+2046 MIME Part Two: Media Types
+2047 MIME Part Three: Message Header Extensions for Non-ASCII Text
+2049 MIME Part Five: Conformance Criteria and Examples
+2060 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 (+ rfc2060-errata)
+2087 IMAP4 QUOTA extension
+2088 IMAP4 non-synchronizing literals
+2111 Content-ID and Message-ID Uniform Resource Locators
+2177 IMAP4 IDLE command
+2180 IMAP4 Multi-Accessed Mailbox Practice
+2192 IMAP URL Scheme
+2193 IMAP4 Mailbox Referrals
+2195 IMAP/POP AUTHorize Extension for Simple Challenge/Response
+2221 IMAP4 Login Referrals
+2222 Simple Authentication and Security Layer (SASL)
+2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
+2245 Anonymous SASL Mechanism
+2298 An Extensible Message Format for Message Disposition Notifications
+2342 IMAP4 Namespace
+2368 The mailto URL scheme
+2384 POP URL Scheme
+2444 The One-Time-Password SASL Mechanism
+2449 POP3 Extension Mechanism
+2595 Using TLS with IMAP, POP3 and ACAP
+2683 IMAP4 Implementation Recommendations
+2808 The SecurID(r) SASL Mechanism
+2821 Simple Mail Transfer Protocol
+2822 Internet Message Format
+2831 Using Digest Authentication as a SASL Mechanism
+3028 Sieve: A Mail Filtering Language
+3206 The SYS and AUTH POP Response Codes
+3348 The Internet Message Action Protocol (IMAP4) Child Mailbox Extension
+3431 Sieve Extension: Relational Tests
+3501 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
+3691 Internet Message Access Protocol (IMAP) UNSELECT command
+4314 IMAP4 Access Control List (ACL) Extension
diff --git a/doc/rfc/rfc1413.txt b/doc/rfc/rfc1413.txt
deleted file mode 100644
index 17ede58..0000000
--- a/doc/rfc/rfc1413.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. St. Johns
-Request for Comments: 1413 US Department of Defense
-Obsoletes: 931 February 1993
-
-
- Identification Protocol
-
-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.
-
-1. INTRODUCTION
-
- The Identification Protocol (a.k.a., "ident", a.k.a., "the Ident
- Protocol") provides a means to determine the identity of a user of a
- particular TCP connection. Given a TCP port number pair, it returns
- a character string which identifies the owner of that connection on
- the server's system.
-
- The Identification Protocol was formerly called the Authentication
- Server Protocol. It has been renamed to better reflect its function.
- This document is a product of the TCP Client Identity Protocol
- Working Group of the Internet Engineering Task Force (IETF).
-
-2. OVERVIEW
-
- This is a connection based application on TCP. A server listens for
- TCP connections on TCP port 113 (decimal). Once a connection is
- established, the server reads a line of data which specifies the
- connection of interest. If it exists, the system dependent user
- identifier of the connection of interest is sent as the reply. The
- server may then either shut the connection down or it may continue to
- read/respond to multiple queries.
-
- The server should close the connection down after a configurable
- amount of time with no queries - a 60-180 second idle timeout is
- recommended. The client may close the connection down at any time;
- however to allow for network delays the client should wait at least
- 30 seconds (or longer) after a query before abandoning the query and
- closing the connection.
-
-
-
-
-
-
-
-St. Johns [Page 1]
-
-RFC 1413 Identification Protocol February 1993
-
-
-3. RESTRICTIONS
-
- Queries are permitted only for fully specified connections. The
- query contains the local/foreign port pair -- the local/foreign
- address pair used to fully specify the connection is taken from the
- local and foreign address of query connection. This means a user on
- address A may only query the server on address B about connections
- between A and B.
-
-4. QUERY/RESPONSE FORMAT
-
- The server accepts simple text query requests of the form:
-
- <port-on-server> , <port-on-client>
-
- where <port-on-server> is the TCP port (decimal) on the target (where
- the "ident" server is running) system, and <port-on-client> is the
- TCP port (decimal) on the source (client) system.
-
- N.B - If a client on host A wants to ask a server on host B about a
- connection specified locally (on the client's machine) as 23, 6191
- (an inbound TELNET connection), the client must actually ask about
- 6191, 23 - which is how the connection would be specified on host B.
-
- For example:
-
- 6191, 23
-
- The response is of the form
-
- <port-on-server> , <port-on-client> : <resp-type> : <add-info>
-
- where <port-on-server>,<port-on-client> are the same pair as the
- query, <resp-type> is a keyword identifying the type of response, and
- <add-info> is context dependent.
-
- The information returned is that associated with the fully specified
- TCP connection identified by <server-address>, <client-address>,
- <port-on-server>, <port-on-client>, where <server-address> and
- <client-address> are the local and foreign IP addresses of the
- querying connection -- i.e., the TCP connection to the Identification
- Protocol Server. (<port-on-server> and <port-on-client> are taken
- from the query.)
-
- For example:
-
- 6193, 23 : USERID : UNIX : stjohns
- 6195, 23 : ERROR : NO-USER
-
-
-
-St. Johns [Page 2]
-
-RFC 1413 Identification Protocol February 1993
-
-
-5. RESPONSE TYPES
-
-A response can be one of two types:
-
-USERID
-
- In this case, <add-info> is a string consisting of an
- operating system name (with an optional character set
- identifier), followed by ":", followed by an
- identification string.
-
- The character set (if present) is separated from the
- operating system name by ",". The character set
- identifier is used to indicate the character set of the
- identification string. The character set identifier,
- if omitted, defaults to "US-ASCII" (see below).
-
- Permitted operating system names and character set
- names are specified in RFC 1340, "Assigned Numbers" or
- its successors.
-
- In addition to those operating system and character set
- names specified in "Assigned Numbers" there is one
- special case operating system identifier - "OTHER".
-
- Unless "OTHER" is specified as the operating system
- type, the server is expected to return the "normal"
- user identification of the owner of this connection.
- "Normal" in this context may be taken to mean a string
- of characters which uniquely identifies the connection
- owner such as a user identifier assigned by the system
- administrator and used by such user as a mail
- identifier, or as the "user" part of a user/password
- pair used to gain access to system resources. When an
- operating system is specified (e.g., anything but
- "OTHER"), the user identifier is expected to be in a
- more or less immediately useful form - e.g., something
- that could be used as an argument to "finger" or as a
- mail address.
-
- "OTHER" indicates the identifier is an unformatted
- character string consisting of printable characters in
- the specified character set. "OTHER" should be
- specified if the user identifier does not meet the
- constraints of the previous paragraph. Sending an
- encrypted audit token, or returning other non-userid
- information about a user (such as the real name and
- phone number of a user from a UNIX passwd file) are
-
-
-
-St. Johns [Page 3]
-
-RFC 1413 Identification Protocol February 1993
-
-
- both examples of when "OTHER" should be used.
-
- Returned user identifiers are expected to be printable
- in the character set indicated.
-
- The identifier is an unformatted octet string - - all
- octets are permissible EXCEPT octal 000 (NUL), 012 (LF)
- and 015 (CR). N.B. - space characters (040) following the
- colon separator ARE part of the identifier string and
- may not be ignored. A response string is still
- terminated normally by a CR/LF. N.B. A string may be
- printable, but is not *necessarily* printable.
-
-ERROR
-
- For some reason the port owner could not be determined, <add-info>
- tells why. The following are the permitted values of <add-info> and
- their meanings:
-
- INVALID-PORT
-
- Either the local or foreign port was improperly
- specified. This should be returned if either or
- both of the port ids were out of range (TCP port
- numbers are from 1-65535), negative integers, reals or
- in any fashion not recognized as a non-negative
- integer.
-
- NO-USER
-
- The connection specified by the port pair is not
- currently in use or currently not owned by an
- identifiable entity.
-
- HIDDEN-USER
-
- The server was able to identify the user of this
- port, but the information was not returned at the
- request of the user.
-
- UNKNOWN-ERROR
-
- Can't determine connection owner; reason unknown.
- Any error not covered above should return this
- error code value. Optionally, this code MAY be
- returned in lieu of any other specific error code
- if, for example, the server desires to hide
- information implied by the return of that error
-
-
-
-St. Johns [Page 4]
-
-RFC 1413 Identification Protocol February 1993
-
-
- code, or for any other reason. If a server
- implements such a feature, it MUST be configurable
- and it MUST default to returning the proper error
- message.
-
- Other values may eventually be specified and defined in future
- revisions to this document. If an implementer has a need to specify
- a non-standard error code, that code must begin with "X".
-
- In addition, the server is allowed to drop the query connection
- without responding. Any premature close (i.e., one where the client
- does not receive the EOL, whether graceful or an abort should be
- considered to have the same meaning as "ERROR : UNKNOWN-ERROR".
-
-FORMAL SYNTAX
-
- <request> ::= <port-pair> <EOL>
-
- <port-pair> ::= <integer> "," <integer>
-
- <reply> ::= <reply-text> <EOL>
-
- <EOL> ::= "015 012" ; CR-LF End of Line Indicator
-
- <reply-text> ::= <error-reply> | <ident-reply>
-
- <error-reply> ::= <port-pair> ":" "ERROR" ":" <error-type>
-
- <ident-reply> ::= <port-pair> ":" "USERID" ":" <opsys-field>
- ":" <user-id>
-
- <error-type> ::= "INVALID-PORT" | "NO-USER" | "UNKNOWN-ERROR"
- | "HIDDEN-USER" | <error-token>
-
- <opsys-field> ::= <opsys> [ "," <charset>]
-
- <opsys> ::= "OTHER" | "UNIX" | <token> ...etc.
- ; (See "Assigned Numbers")
-
- <charset> ::= "US-ASCII" | ...etc.
- ; (See "Assigned Numbers")
-
- <user-id> ::= <octet-string>
-
- <token> ::= 1*64<token-characters> ; 1-64 characters
-
- <error-token> ::= "X"1*63<token-characters>
- ; 2-64 chars beginning w/X
-
-
-
-St. Johns [Page 5]
-
-RFC 1413 Identification Protocol February 1993
-
-
- <integer> ::= 1*5<digit> ; 1-5 digits.
-
- <digit> ::= "0" | "1" ... "8" | "9" ; 0-9
-
- <token-characters> ::=
- <Any of these ASCII characters: a-z, A-Z,
- - (dash), .!@#$%^&*()_=+.,<>/?"'~`{}[]; >
- ; upper and lowercase a-z plus
- ; printables minus the colon ":"
- ; character.
-
- <octet-string> ::= 1*512<octet-characters>
-
- <octet-characters> ::=
- <any octet from 00 to 377 (octal) except for
- ASCII NUL (000), CR (015) and LF (012)>
-
-Notes on Syntax:
-
- 1) To promote interoperability among variant
- implementations, with respect to white space the above
- syntax is understood to embody the "be conservative in
- what you send and be liberal in what you accept"
- philosophy. Clients and servers should not generate
- unnecessary white space (space and tab characters) but
- should accept white space anywhere except within a
- token. In parsing responses, white space may occur
- anywhere, except within a token. Specifically, any
- amount of white space is permitted at the beginning or
- end of a line both for queries and responses. This
- does not apply for responses that contain a user ID
- because everything after the colon after the operating
- system type until the terminating CR/LF is taken as
- part of the user ID. The terminating CR/LF is NOT
- considered part of the user ID.
-
- 2) The above notwithstanding, servers should restrict the
- amount of inter-token white space they send to the
- smallest amount reasonable or useful. Clients should
- feel free to abort a connection if they receive 1000
- characters without receiving an <EOL>.
-
- 3) The 512 character limit on user IDs and the 64
- character limit on tokens should be understood to mean
- as follows: a) No new token (i.e., OPSYS or ERROR-TYPE)
- token will be defined that has a length greater than 64
- and b) a server SHOULD NOT send more than 512 octets of
- user ID and a client MUST accept at least 512 octets of
-
-
-
-St. Johns [Page 6]
-
-RFC 1413 Identification Protocol February 1993
-
-
- user ID. Because of this limitation, a server MUST
- return the most significant portion of the user ID in
- the first 512 octets.
-
- 4) The character sets and character set identifiers should
- map directly to those defined in or referenced by RFC 1340,
- "Assigned Numbers" or its successors. Character set
- identifiers only apply to the user identification field
- - all other fields will be defined in and must be sent
- as US-ASCII.
-
- 5) Although <user-id> is defined as an <octet-string>
- above, it must follow the format and character set
- constraints implied by the <opsys-field>; see the
- discussion above.
-
- 6) The character set provides context for the client to
- print or store the returned user identification string.
- If the client does not recognize or implement the
- returned character set, it should handle the returned
- identification string as OCTET, but should in addition
- store or report the character set. An OCTET string
- should be printed, stored or handled in hex notation
- (0-9a-f) in addition to any other representation the
- client implements - this provides a standard
- representation among differing implementations.
-
-6. Security Considerations
-
- The information returned by this protocol is at most as trustworthy
- as the host providing it OR the organization operating the host. For
- example, a PC in an open lab has few if any controls on it to prevent
- a user from having this protocol return any identifier the user
- wants. Likewise, if the host has been compromised the information
- returned may be completely erroneous and misleading.
-
- The Identification Protocol is not intended as an authorization or
- access control protocol. At best, it provides some additional
- auditing information with respect to TCP connections. At worst, it
- can provide misleading, incorrect, or maliciously incorrect
- information.
-
- The use of the information returned by this protocol for other than
- auditing is strongly discouraged. Specifically, using Identification
- Protocol information to make access control decisions - either as the
- primary method (i.e., no other checks) or as an adjunct to other
- methods may result in a weakening of normal host security.
-
-
-
-
-St. Johns [Page 7]
-
-RFC 1413 Identification Protocol February 1993
-
-
- An Identification server may reveal information about users,
- entities, objects or processes which might normally be considered
- private. An Identification server provides service which is a rough
- analog of the CallerID services provided by some phone companies and
- many of the same privacy considerations and arguments that apply to
- the CallerID service apply to Identification. If you wouldn't run a
- "finger" server due to privacy considerations you may not want to run
- this protocol.
-
-7. ACKNOWLEDGEMENTS
-
- Acknowledgement is given to Dan Bernstein who is primarily
- responsible for renewing interest in this protocol and for pointing
- out some annoying errors in RFC 931.
-
-References
-
- [1] St. Johns, M., "Authentication Server", RFC 931, TPSC, January
- 1985.
-
- [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
- USC/Information Sciences Institute, July 1992.
-
-Author's Address
-
- Michael C. St. Johns
- DARPA/CSTO
- 3701 N. Fairfax Dr
- Arlington, VA 22203
-
- Phone: (703) 696-2271
- EMail: [email protected]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-St. Johns [Page 8]
-
\ No newline at end of file
diff --git a/doc/rfc/rfc1521.txt b/doc/rfc/rfc1521.txt
deleted file mode 100644
index eae6dc7..0000000
--- a/doc/rfc/rfc1521.txt
+++ /dev/null
@@ -1,4539 +0,0 @@
-
-
-
-
-
-
-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 := <a publicly-defined extension token,
- registered with IANA, as specified in
- appendix E>
-
- x-token := <The two characters "X-" or "x-" followed, with
- no intervening white space, by any token>
-
- subtype := token ; case-insensitive
-
- parameter := attribute "=" value
-
- attribute := token ; case-insensitive
-
- value := token / quoted-string
-
- token := 1*<any (ASCII) CHAR except SPACE, CTLs,
- or tspecials>
-
- 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 /<any ASCII character except "=", SPACE, or TAB>
- ; characters not listed as "mail-safe" in Appendix B
- ; are also not recommended.
-
- 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".
-
-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 <[email protected]>
- To: Ned Freed <[email protected]>
- 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<bchars> 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 <[email protected]>
- To: Ned Freed <[email protected]>
- 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="[email protected]"
-
- Content-Type: Message/Partial;
- id="[email protected]";
- number=2
-
- But part 3 MUST specify the total number of parts:
-
- Content-Type: Message/Partial;
- number=3; total=3;
- id="[email protected]"
-
- 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: [email protected]
- To: [email protected]
- Subject: Audio mail
- Message-ID: <[email protected]>
- MIME-Version: 1.0
- Content-type: message/partial;
- id="[email protected]";
- 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: <[email protected]>
- 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: [email protected]
- To: [email protected]
- Subject: Audio mail
- MIME-Version: 1.0
- Message-ID: <[email protected]>
- Content-type: message/partial;
- id="[email protected]"; 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: [email protected]
- To: [email protected]
- Subject: Audio mail
- Message-ID: <[email protected]>
- 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: <[email protected]>
- 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: <[email protected]>
- Content-Type: multipart/alternative; boundary=42
- Content-ID: <[email protected]>
-
- --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: <[email protected]>
-
- --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: <[email protected]>
-
- --42
- Content-Type: message/external-body;
- access-type=mail-server
-
-
-
-Borenstein & Freed [Page 47]
-
-RFC 1521 MIME September 1993
-
-
- server="[email protected]";
- expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
-
- Content-type: application/postscript
- Content-ID: <[email protected]>
-
- 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: [email protected]
-
-
- 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: [email protected]
-
- 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: [email protected]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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 <[email protected]>
- To: Ned Freed <[email protected]>
- 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 <bold><italic>richtext.</italic></bold>
- <smaller>as defined in RFC 1341</smaller>
- <nl><nl>Isn't it
- <bigger><bigger>cool?</bigger></bigger>
-
- --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<bchars> 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 := <a publicly-defined extension token,
- registered with IANA, as specified in
- appendix E>
-
- 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 / <any ASCII character except "=", SPACE, or TAB>
-
-
-
-Borenstein & Freed [Page 70]
-
-RFC 1521 MIME September 1993
-
-
- ; characters not listed as "mail-safe" in Appendix B
- ; are also not recommended.
-
- quoted-printable := ([*(ptext / SPACE / TAB) ptext] ["="] CRLF)
- ; Maximum line length of 76 characters excluding CRLF
-
- stream-param := (";" "type" "=" value)
- / (";" "padding" "=" padding)
-
- subtype := token ; case-insensitive
-
- text-subtype := "plain" / extension-token
-
- text-type := "text" "/" text-subtype [";" "charset" "=" charset]
-
- token := 1*<any (ASCII) CHAR except SPACE, CTLs, or tspecials>
-
- tspecials := "(" / ")" / "<" / ">" / "@"
- / "," / ";" / ":" / "\" / <">
- / "/" / "[" / "]" / "?" / "="
- ; 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 := <The two characters "X-" or "x-" followed, with no
- intervening white space, by any 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: [email protected]
- 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: [email protected]
- 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]
-
diff --git a/doc/rfc/rfc1731.txt b/doc/rfc/rfc1731.txt
deleted file mode 100644
index 9cced5d..0000000
--- a/doc/rfc/rfc1731.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-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: [email protected]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Myers [Page 6]
-
diff --git a/doc/rfc/rfc1734.txt b/doc/rfc/rfc1734.txt
deleted file mode 100644
index f37f29e..0000000
--- a/doc/rfc/rfc1734.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-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 ::= <any CHAR except atom_specials>
-
- 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 ::= <any 7-bit US-ASCII character except NUL,
- 0x01 - 0x7f>
-
- continue_req ::= "+" SPACE base64 CRLF
-
- CR ::= <ASCII CR, carriage return, 0x0C>
-
- CRLF ::= CR LF
-
- CTL ::= <any ASCII control character and DEL,
- 0x00 - 0x1f, 0x7f>
-
-
-
-
-Myers [Page 4]
-
-RFC 1734 POP3 AUTH December 1994
-
-
- LF ::= <ASCII LF, line feed, 0x0A>
-
- SPACE ::= <ASCII SP, space, 0x20>
-
- TAB ::= <ASCII HT, tab, 0x09>
-
-
-
-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: [email protected]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Myers [Page 5]
-
diff --git a/doc/rfc/rfc1738.txt b/doc/rfc/rfc1738.txt
deleted file mode 100644
index 3728866..0000000
--- a/doc/rfc/rfc1738.txt
+++ /dev/null
@@ -1,1403 +0,0 @@
-
-
-
-
-
-
-Network Working Group T. Berners-Lee
-Request for Comments: 1738 CERN
-Category: Standards Track L. Masinter
- Xerox Corporation
- M. McCahill
- University of Minnesota
- Editors
- December 1994
-
-
- Uniform Resource Locators (URL)
-
-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 document specifies a Uniform Resource Locator (URL), the syntax
- and semantics of formalized information for location and access of
- resources via the Internet.
-
-1. Introduction
-
- This document describes the syntax and semantics for a compact string
- representation for a resource available via the Internet. These
- strings are called "Uniform Resource Locators" (URLs).
-
- The specification is derived from concepts introduced by the World-
- Wide Web global information initiative, whose use of such objects
- dates from 1990 and is described in "Universal Resource Identifiers
- in WWW", RFC 1630. The specification of URLs is designed to meet the
- requirements laid out in "Functional Requirements for Internet
- Resource Locators" [12].
-
- This document was written by the URI working group of the Internet
- Engineering Task Force. Comments may be addressed to the editors, or
- to the URI-WG <[email protected]>. Discussions of the group are archived
- at <URL:http://www.acl.lanl.gov/URI/archive/uri-archive.index.html>
-
-
-
-
-
-
-
-
-Berners-Lee, Masinter & McCahill [Page 1]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
-2. General URL Syntax
-
- Just as there are many different methods of access to resources,
- there are several schemes for describing the location of such
- resources.
-
- The generic syntax for URLs provides a framework for new schemes to
- be established using protocols other than those defined in this
- document.
-
- URLs are used to `locate' resources, by providing an abstract
- identification of the resource location. Having located a resource,
- a system may perform a variety of operations on the resource, as
- might be characterized by such words as `access', `update',
- `replace', `find attributes'. In general, only the `access' method
- needs to be specified for any URL scheme.
-
-2.1. The main parts of URLs
-
- A full BNF description of the URL syntax is given in Section 5.
-
- In general, URLs are written as follows:
-
- <scheme>:<scheme-specific-part>
-
- A URL contains the name of the scheme being used (<scheme>) followed
- by a colon and then a string (the <scheme-specific-part>) whose
- interpretation depends on the scheme.
-
- Scheme names consist of a sequence of characters. The lower case
- letters "a"--"z", digits, and the characters plus ("+"), period
- ("."), and hyphen ("-") are allowed. For resiliency, programs
- interpreting URLs should treat upper case letters as equivalent to
- lower case in scheme names (e.g., allow "HTTP" as well as "http").
-
-2.2. URL Character Encoding Issues
-
- URLs are sequences of characters, i.e., letters, digits, and special
- characters. A URLs may be represented in a variety of ways: e.g., ink
- on paper, or a sequence of octets in a coded character set. The
- interpretation of a URL depends only on the identity of the
- characters used.
-
- In most URL schemes, the sequences of characters in different parts
- of a URL are used to represent sequences of octets used in Internet
- protocols. For example, in the ftp scheme, the host name, directory
- name and file names are such sequences of octets, represented by
- parts of the URL. Within those parts, an octet may be represented by
-
-
-
-Berners-Lee, Masinter & McCahill [Page 2]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
- the chararacter which has that octet as its code within the US-ASCII
- [20] coded character set.
-
- In addition, octets may be encoded by a character triplet consisting
- of the character "%" followed by the two hexadecimal digits (from
- "0123456789ABCDEF") which forming the hexadecimal value of the octet.
- (The characters "abcdef" may also be used in hexadecimal encodings.)
-
- Octets must be encoded if they have no corresponding graphic
- character within the US-ASCII coded character set, if the use of the
- corresponding character is unsafe, or if the corresponding character
- is reserved for some other interpretation within the particular URL
- scheme.
-
- No corresponding graphic US-ASCII:
-
- URLs are written only with the graphic printable characters of the
- US-ASCII coded character set. The octets 80-FF hexadecimal are not
- used in US-ASCII, and the octets 00-1F and 7F hexadecimal represent
- control characters; these must be encoded.
-
- Unsafe:
-
- Characters can be unsafe for a number of reasons. The space
- character is unsafe because significant spaces may disappear and
- insignificant spaces may be introduced when URLs are transcribed or
- typeset or subjected to the treatment of word-processing programs.
- The characters "<" and ">" are unsafe because they are used as the
- delimiters around URLs in free text; the quote mark (""") is used to
- delimit URLs in some systems. The character "#" is unsafe and should
- always be encoded because it is used in World Wide Web and in other
- systems to delimit a URL from a fragment/anchor identifier that might
- follow it. The character "%" is unsafe because it is used for
- encodings of other characters. Other characters are unsafe because
- gateways and other transport agents are known to sometimes modify
- such characters. These characters are "{", "}", "|", "\", "^", "~",
- "[", "]", and "`".
-
- All unsafe characters must always be encoded within a URL. For
- example, the character "#" must be encoded within URLs even in
- systems that do not normally deal with fragment or anchor
- identifiers, so that if the URL is copied into another system that
- does use them, it will not be necessary to change the URL encoding.
-
-
-
-
-
-
-
-
-Berners-Lee, Masinter & McCahill [Page 3]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
- Reserved:
-
- Many URL schemes reserve certain characters for a special meaning:
- their appearance in the scheme-specific part of the URL has a
- designated semantics. If the character corresponding to an octet is
- reserved in a scheme, the octet must be encoded. The characters ";",
- "/", "?", ":", "@", "=" and "&" are the characters which may be
- reserved for special meaning within a scheme. No other characters may
- be reserved within a scheme.
-
- Usually a URL has the same interpretation when an octet is
- represented by a character and when it encoded. However, this is not
- true for reserved characters: encoding a character reserved for a
- particular scheme may change the semantics of a URL.
-
- Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
- reserved characters used for their reserved purposes may be used
- unencoded within a URL.
-
- On the other hand, characters that are not required to be encoded
- (including alphanumerics) may be encoded within the scheme-specific
- part of a URL, as long as they are not being used for a reserved
- purpose.
-
-2.3 Hierarchical schemes and relative links
-
- In some cases, URLs are used to locate resources that contain
- pointers to other resources. In some cases, those pointers are
- represented as relative links where the expression of the location of
- the second resource is in terms of "in the same place as this one
- except with the following relative path". Relative links are not
- described in this document. However, the use of relative links
- depends on the original URL containing a hierarchical structure
- against which the relative link is based.
-
- Some URL schemes (such as the ftp, http, and file schemes) contain
- names that can be considered hierarchical; the components of the
- hierarchy are separated by "/".
-
-
-
-
-
-
-
-
-
-
-
-
-
-Berners-Lee, Masinter & McCahill [Page 4]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
-3. Specific Schemes
-
- The mapping for some existing standard and experimental protocols is
- outlined in the BNF syntax definition. Notes on particular protocols
- follow. The schemes covered are:
-
- ftp File Transfer protocol
- http Hypertext Transfer Protocol
- gopher The Gopher protocol
- mailto Electronic mail address
- news USENET news
- nntp USENET news using NNTP access
- telnet Reference to interactive sessions
- wais Wide Area Information Servers
- file Host-specific file names
- prospero Prospero Directory Service
-
- Other schemes may be specified by future specifications. Section 4 of
- this document describes how new schemes may be registered, and lists
- some scheme names that are under development.
-
-3.1. Common Internet Scheme Syntax
-
- While the syntax for the rest of the URL may vary depending on the
- particular scheme selected, URL schemes that involve the direct use
- of an IP-based protocol to a specified host on the Internet use a
- common syntax for the scheme-specific data:
-
- //<user>:<password>@<host>:<port>/<url-path>
-
- Some or all of the parts "<user>:<password>@", ":<password>",
- ":<port>", and "/<url-path>" may be excluded. The scheme specific
- data start with a double slash "//" to indicate that it complies with
- the common Internet scheme syntax. The different components obey the
- following rules:
-
- user
- An optional user name. Some schemes (e.g., ftp) allow the
- specification of a user name.
-
- password
- An optional password. If present, it follows the user
- name separated from it by a colon.
-
- The user name (and password), if present, are followed by a
- commercial at-sign "@". Within the user and password field, any ":",
- "@", or "/" must be encoded.
-
-
-
-
-Berners-Lee, Masinter & McCahill [Page 5]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
- Note that an empty user name or password is different than no user
- name or password; there is no way to specify a password without
- specifying a user name. E.g., <URL:ftp://@host.com/> has an empty
- user name and no password, <URL:ftp://host.com/> has no user name,
- while <URL:ftp://foo:@host.com/> has a user name of "foo" and an
- empty password.
-
- host
- The fully qualified domain name of a network host, or its IP
- address as a set of four decimal digit groups separated by
- ".". Fully qualified domain names take the form as described
- in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123
- [5]: a sequence of domain labels separated by ".", each domain
- label starting and ending with an alphanumerical character and
- possibly also containing "-" characters. The rightmost domain
- label will never start with a digit, though, which
- syntactically distinguishes all domain names from the IP
- addresses.
-
- port
- The port number to connect to. Most schemes designate
- protocols that have a default port number. Another port number
- may optionally be supplied, in decimal, separated from the
- host by a colon. If the port is omitted, the colon is as well.
-
- url-path
- The rest of the locator consists of data specific to the
- scheme, and is known as the "url-path". It supplies the
- details of how the specified resource can be accessed. Note
- that the "/" between the host (or port) and the url-path is
- NOT part of the url-path.
-
- The url-path syntax depends on the scheme being used, as does the
- manner in which it is interpreted.
-
-3.2. FTP
-
- The FTP URL scheme is used to designate files and directories on
- Internet hosts accessible using the FTP protocol (RFC959).
-
- A FTP URL follow the syntax described in Section 3.1. If :<port> is
- omitted, the port defaults to 21.
-
-
-
-
-
-
-
-
-
-Berners-Lee, Masinter & McCahill [Page 6]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
-3.2.1. FTP Name and Password
-
- A user name and password may be supplied; they are used in the ftp
- "USER" and "PASS" commands after first making the connection to the
- FTP server. If no user name or password is supplied and one is
- requested by the FTP server, the conventions for "anonymous" FTP are
- to be used, as follows:
-
- The user name "anonymous" is supplied.
-
- The password is supplied as the Internet e-mail address
- of the end user accessing the resource.
-
- If the URL supplies a user name but no password, and the remote
- server requests a password, the program interpreting the FTP URL
- should request one from the user.
-
-3.2.2. FTP url-path
-
- The url-path of a FTP URL has the following syntax:
-
- <cwd1>/<cwd2>/.../<cwdN>/<name>;type=<typecode>
-
- Where <cwd1> through <cwdN> and <name> are (possibly encoded) strings
- and <typecode> is one of the characters "a", "i", or "d". The part
- ";type=<typecode>" may be omitted. The <cwdx> and <name> parts may be
- empty. The whole url-path may be omitted, including the "/"
- delimiting it from the prefix containing user, password, host, and
- port.
-
- The url-path is interpreted as a series of FTP commands as follows:
-
- Each of the <cwd> elements is to be supplied, sequentially, as the
- argument to a CWD (change working directory) command.
-
- If the typecode is "d", perform a NLST (name list) command with
- <name> as the argument, and interpret the results as a file
- directory listing.
-
- Otherwise, perform a TYPE command with <typecode> as the argument,
- and then access the file whose name is <name> (for example, using
- the RETR command.)
-
- Within a name or CWD component, the characters "/" and ";" are
- reserved and must be encoded. The components are decoded prior to
- their use in the FTP protocol. In particular, if the appropriate FTP
- sequence to access a particular file requires supplying a string
- containing a "/" as an argument to a CWD or RETR command, it is
-
-
-
-Berners-Lee, Masinter & McCahill [Page 7]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
- necessary to encode each "/".
-
- For example, the URL <URL:ftp://[email protected]/%2Fetc/motd> is
- interpreted by FTP-ing to "host.dom", logging in as "myname"
- (prompting for a password if it is asked for), and then executing
- "CWD /etc" and then "RETR motd". This has a different meaning from
- <URL:ftp://[email protected]/etc/motd> which would "CWD etc" and then
- "RETR motd"; the initial "CWD" might be executed relative to the
- default directory for "myname". On the other hand,
- <URL:ftp://[email protected]//etc/motd>, would "CWD " with a null
- argument, then "CWD etc", and then "RETR motd".
-
- FTP URLs may also be used for other operations; for example, it is
- possible to update a file on a remote file server, or infer
- information about it from the directory listings. The mechanism for
- doing so is not spelled out here.
-
-3.2.3. FTP Typecode is Optional
-
- The entire ;type=<typecode> part of a FTP URL is optional. If it is
- omitted, the client program interpreting the URL must guess the
- appropriate mode to use. In general, the data content type of a file
- can only be guessed from the name, e.g., from the suffix of the name;
- the appropriate type code to be used for transfer of the file can
- then be deduced from the data content of the file.
-
-3.2.4 Hierarchy
-
- For some file systems, the "/" used to denote the hierarchical
- structure of the URL corresponds to the delimiter used to construct a
- file name hierarchy, and thus, the filename will look similar to the
- URL path. This does NOT mean that the URL is a Unix filename.
-
-3.2.5. Optimization
-
- Clients accessing resources via FTP may employ additional heuristics
- to optimize the interaction. For some FTP servers, for example, it
- may be reasonable to keep the control connection open while accessing
- multiple URLs from the same server. However, there is no common
- hierarchical model to the FTP protocol, so if a directory change
- command has been given, it is impossible in general to deduce what
- sequence should be given to navigate to another directory for a
- second retrieval, if the paths are different. The only reliable
- algorithm is to disconnect and reestablish the control connection.
-
-
-
-
-
-
-
-Berners-Lee, Masinter & McCahill [Page 8]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
-3.3. HTTP
-
- The HTTP URL scheme is used to designate Internet resources
- accessible using HTTP (HyperText Transfer Protocol).
-
- The HTTP protocol is specified elsewhere. This specification only
- describes the syntax of HTTP URLs.
-
- An HTTP URL takes the form:
-
- http://<host>:<port>/<path>?<searchpart>
-
- where <host> and <port> are as described in Section 3.1. If :<port>
- is omitted, the port defaults to 80. No user name or password is
- allowed. <path> is an HTTP selector, and <searchpart> is a query
- string. The <path> is optional, as is the <searchpart> and its
- preceding "?". If neither <path> nor <searchpart> is present, the "/"
- may also be omitted.
-
- Within the <path> and <searchpart> components, "/", ";", "?" are
- reserved. The "/" character may be used within HTTP to designate a
- hierarchical structure.
-
-3.4. GOPHER
-
- The Gopher URL scheme is used to designate Internet resources
- accessible using the Gopher protocol.
-
- The base Gopher protocol is described in RFC 1436 and supports items
- and collections of items (directories). The Gopher+ protocol is a set
- of upward compatible extensions to the base Gopher protocol and is
- described in [2]. Gopher+ supports associating arbitrary sets of
- attributes and alternate data representations with Gopher items.
- Gopher URLs accommodate both Gopher and Gopher+ items and item
- attributes.
-
-3.4.1. Gopher URL syntax
-
- A Gopher URL takes the form:
-
- gopher://<host>:<port>/<gopher-path>
-
- where <gopher-path> is one of
-
- <gophertype><selector>
- <gophertype><selector>%09<search>
- <gophertype><selector>%09<search>%09<gopher+_string>
-
-
-
-
-Berners-Lee, Masinter & McCahill [Page 9]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
- If :<port> is omitted, the port defaults to 70. <gophertype> is a
- single-character field to denote the Gopher type of the resource to
- which the URL refers. The entire <gopher-path> may also be empty, in
- which case the delimiting "/" is also optional and the <gophertype>
- defaults to "1".
-
- <selector> is the Gopher selector string. In the Gopher protocol,
- Gopher selector strings are a sequence of octets which may contain
- any octets except 09 hexadecimal (US-ASCII HT or tab) 0A hexadecimal
- (US-ASCII character LF), and 0D (US-ASCII character CR).
-
- Gopher clients specify which item to retrieve by sending the Gopher
- selector string to a Gopher server.
-
- Within the <gopher-path>, no characters are reserved.
-
- Note that some Gopher <selector> strings begin with a copy of the
- <gophertype> character, in which case that character will occur twice
- consecutively. The Gopher selector string may be an empty string;
- this is how Gopher clients refer to the top-level directory on a
- Gopher server.
-
-3.4.2 Specifying URLs for Gopher Search Engines
-
- If the URL refers to a search to be submitted to a Gopher search
- engine, the selector is followed by an encoded tab (%09) and the
- search string. To submit a search to a Gopher search engine, the
- Gopher client sends the <selector> string (after decoding), a tab,
- and the search string to the Gopher server.
-
-3.4.3 URL syntax for Gopher+ items
-
- URLs for Gopher+ items have a second encoded tab (%09) and a Gopher+
- string. Note that in this case, the %09<search> string must be
- supplied, although the <search> element may be the empty string.
-
- The <gopher+_string> is used to represent information required for
- retrieval of the Gopher+ item. Gopher+ items may have alternate
- views, arbitrary sets of attributes, and may have electronic forms
- associated with them.
-
- To retrieve the data associated with a Gopher+ URL, a client will
- connect to the server and send the Gopher selector, followed by a tab
- and the search string (which may be empty), followed by a tab and the
- Gopher+ commands.
-
-
-
-
-
-
-Berners-Lee, Masinter & McCahill [Page 10]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
-3.4.4 Default Gopher+ data representation
-
- When a Gopher server returns a directory listing to a client, the
- Gopher+ items are tagged with either a "+" (denoting Gopher+ items)
- or a "?" (denoting Gopher+ items which have a +ASK form associated
- with them). A Gopher URL with a Gopher+ string consisting of only a
- "+" refers to the default view (data representation) of the item
- while a Gopher+ string containing only a "?" refer to an item with a
- Gopher electronic form associated with it.
-
-3.4.5 Gopher+ items with electronic forms
-
- Gopher+ items which have a +ASK associated with them (i.e. Gopher+
- items tagged with a "?") require the client to fetch the item's +ASK
- attribute to get the form definition, and then ask the user to fill
- out the form and return the user's responses along with the selector
- string to retrieve the item. Gopher+ clients know how to do this but
- depend on the "?" tag in the Gopher+ item description to know when to
- handle this case. The "?" is used in the Gopher+ string to be
- consistent with Gopher+ protocol's use of this symbol.
-
-3.4.6 Gopher+ item attribute collections
-
- To refer to the Gopher+ attributes of an item, the Gopher URL's
- Gopher+ string consists of "!" or "$". "!" refers to the all of a
- Gopher+ item's attributes. "$" refers to all the item attributes for
- all items in a Gopher directory.
-
-3.4.7 Referring to specific Gopher+ attributes
-
- To refer to specific attributes, the URL's gopher+_string is
- "!<attribute_name>" or "$<attribute_name>". For example, to refer to
- the attribute containing the abstract of an item, the gopher+_string
- would be "!+ABSTRACT".
-
- To refer to several attributes, the gopher+_string consists of the
- attribute names separated by coded spaces. For example,
- "!+ABSTRACT%20+SMELL" refers to the +ABSTRACT and +SMELL attributes
- of an item.
-
-3.4.8 URL syntax for Gopher+ alternate views
-
- Gopher+ allows for optional alternate data representations (alternate
- views) of items. To retrieve a Gopher+ alternate view, a Gopher+
- client sends the appropriate view and language identifier (found in
- the item's +VIEW attribute). To refer to a specific Gopher+ alternate
- view, the URL's Gopher+ string would be in the form:
-
-
-
-
-Berners-Lee, Masinter & McCahill [Page 11]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
- +<view_name>%20<language_name>
-
- For example, a Gopher+ string of "+application/postscript%20Es_ES"
- refers to the Spanish language postscript alternate view of a Gopher+
- item.
-
-3.4.9 URL syntax for Gopher+ electronic forms
-
- The gopher+_string for a URL that refers to an item referenced by a
- Gopher+ electronic form (an ASK block) filled out with specific
- values is a coded version of what the client sends to the server.
- The gopher+_string is of the form:
-
-+%091%0D%0A+-1%0D%0A<ask_item1_value>%0D%0A<ask_item2_value>%0D%0A.%0D%0A
-
- To retrieve this item, the Gopher client sends:
-
- <a_gopher_selector><tab>+<tab>1<cr><lf>
- +-1<cr><lf>
- <ask_item1_value><cr><lf>
- <ask_item2_value><cr><lf>
- .<cr><lf>
-
- to the Gopher server.
-
-3.5. MAILTO
-
- The mailto URL scheme is used to designate the Internet mailing
- address of an individual or service. No additional information other
- than an Internet mailing address is present or implied.
-
- A mailto URL takes the form:
-
- mailto:<rfc822-addr-spec>
-
- where <rfc822-addr-spec> is (the encoding of an) addr-spec, as
- specified in RFC 822 [6]. Within mailto URLs, there are no reserved
- characters.
-
- Note that the percent sign ("%") is commonly used within RFC 822
- addresses and must be encoded.
-
- Unlike many URLs, the mailto scheme does not represent a data object
- to be accessed directly; there is no sense in which it designates an
- object. It has a different use than the message/external-body type in
- MIME.
-
-
-
-
-
-Berners-Lee, Masinter & McCahill [Page 12]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
-3.6. NEWS
-
- The news URL scheme is used to refer to either news groups or
- individual articles of USENET news, as specified in RFC 1036.
-
- A news URL takes one of two forms:
-
- news:<newsgroup-name>
- news:<message-id>
-
- A <newsgroup-name> is a period-delimited hierarchical name, such as
- "comp.infosystems.www.misc". A <message-id> corresponds to the
- Message-ID of section 2.1.5 of RFC 1036, without the enclosing "<"
- and ">"; it takes the form <unique>@<full_domain_name>. A message
- identifier may be distinguished from a news group name by the
- presence of the commercial at "@" character. No additional characters
- are reserved within the components of a news URL.
-
- If <newsgroup-name> is "*" (as in <URL:news:*>), it is used to refer
- to "all available news groups".
-
- The news URLs are unusual in that by themselves, they do not contain
- sufficient information to locate a single resource, but, rather, are
- location-independent.
-
-3.7. NNTP
-
- The nntp URL scheme is an alternative method of referencing news
- articles, useful for specifying news articles from NNTP servers (RFC
- 977).
-
- A nntp URL take the form:
-
- nntp://<host>:<port>/<newsgroup-name>/<article-number>
-
- where <host> and <port> are as described in Section 3.1. If :<port>
- is omitted, the port defaults to 119.
-
- The <newsgroup-name> is the name of the group, while the <article-
- number> is the numeric id of the article within that newsgroup.
-
- Note that while nntp: URLs specify a unique location for the article
- resource, most NNTP servers currently on the Internet today are
- configured only to allow access from local clients, and thus nntp
- URLs do not designate globally accessible resources. Thus, the news:
- form of URL is preferred as a way of identifying news articles.
-
-
-
-
-
-Berners-Lee, Masinter & McCahill [Page 13]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
-3.8. TELNET
-
- The Telnet URL scheme is used to designate interactive services that
- may be accessed by the Telnet protocol.
-
- A telnet URL takes the form:
-
- telnet://<user>:<password>@<host>:<port>/
-
- as specified in Section 3.1. The final "/" character may be omitted.
- If :<port> is omitted, the port defaults to 23. The :<password> can
- be omitted, as well as the whole <user>:<password> part.
-
- This URL does not designate a data object, but rather an interactive
- service. Remote interactive services vary widely in the means by
- which they allow remote logins; in practice, the <user> and
- <password> supplied are advisory only: clients accessing a telnet URL
- merely advise the user of the suggested username and password.
-
-3.9. WAIS
-
- The WAIS URL scheme is used to designate WAIS databases, searches, or
- individual documents available from a WAIS database. WAIS is
- described in [7]. The WAIS protocol is described in RFC 1625 [17];
- Although the WAIS protocol is based on Z39.50-1988, the WAIS URL
- scheme is not intended for use with arbitrary Z39.50 services.
-
- A WAIS URL takes one of the following forms:
-
- wais://<host>:<port>/<database>
- wais://<host>:<port>/<database>?<search>
- wais://<host>:<port>/<database>/<wtype>/<wpath>
-
- where <host> and <port> are as described in Section 3.1. If :<port>
- is omitted, the port defaults to 210. The first form designates a
- WAIS database that is available for searching. The second form
- designates a particular search. <database> is the name of the WAIS
- database being queried.
-
- The third form designates a particular document within a WAIS
- database to be retrieved. In this form <wtype> is the WAIS
- designation of the type of the object. Many WAIS implementations
- require that a client know the "type" of an object prior to
- retrieval, the type being returned along with the internal object
- identifier in the search response. The <wtype> is included in the
- URL in order to allow the client interpreting the URL adequate
- information to actually retrieve the document.
-
-
-
-
-Berners-Lee, Masinter & McCahill [Page 14]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
- The <wpath> of a WAIS URL consists of the WAIS document-id, encoded
- as necessary using the method described in Section 2.2. The WAIS
- document-id should be treated opaquely; it may only be decomposed by
- the server that issued it.
-
-3.10 FILES
-
- The file URL scheme is used to designate files accessible on a
- particular host computer. This scheme, unlike most other URL schemes,
- does not designate a resource that is universally accessible over the
- Internet.
-
- A file URL takes the form:
-
- file://<host>/<path>
-
- where <host> is the fully qualified domain name of the system on
- which the <path> is accessible, and <path> is a hierarchical
- directory path of the form <directory>/<directory>/.../<name>.
-
- For example, a VMS file
-
- DISK$USER:[MY.NOTES]NOTE123456.TXT
-
- might become
-
- <URL:file://vms.host.edu/disk$user/my/notes/note12345.txt>
-
- As a special case, <host> can be the string "localhost" or the empty
- string; this is interpreted as `the machine from which the URL is
- being interpreted'.
-
- The file URL scheme is unusual in that it does not specify an
- Internet protocol or access method for such files; as such, its
- utility in network protocols between hosts is limited.
-
-3.11 PROSPERO
-
- The Prospero URL scheme is used to designate resources that are
- accessed via the Prospero Directory Service. The Prospero protocol is
- described elsewhere [14].
-
- A prospero URLs takes the form:
-
- prospero://<host>:<port>/<hsoname>;<field>=<value>
-
- where <host> and <port> are as described in Section 3.1. If :<port>
- is omitted, the port defaults to 1525. No username or password is
-
-
-
-Berners-Lee, Masinter & McCahill [Page 15]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
- allowed.
-
- The <hsoname> is the host-specific object name in the Prospero
- protocol, suitably encoded. This name is opaque and interpreted by
- the Prospero server. The semicolon ";" is reserved and may not
- appear without quoting in the <hsoname>.
-
- Prospero URLs are interpreted by contacting a Prospero directory
- server on the specified host and port to determine appropriate access
- methods for a resource, which might themselves be represented as
- different URLs. External Prospero links are represented as URLs of
- the underlying access method and are not represented as Prospero
- URLs.
-
- Note that a slash "/" may appear in the <hsoname> without quoting and
- no significance may be assumed by the application. Though slashes
- may indicate hierarchical structure on the server, such structure is
- not guaranteed. Note that many <hsoname>s begin with a slash, in
- which case the host or port will be followed by a double slash: the
- slash from the URL syntax, followed by the initial slash from the
- <hsoname>. (E.g., <URL:prospero://host.dom//pros/name> designates a
- <hsoname> of "/pros/name".)
-
- In addition, after the <hsoname>, optional fields and values
- associated with a Prospero link may be specified as part of the URL.
- When present, each field/value pair is separated from each other and
- from the rest of the URL by a ";" (semicolon). The name of the field
- and its value are separated by a "=" (equal sign). If present, these
- fields serve to identify the target of the URL. For example, the
- OBJECT-VERSION field can be specified to identify a specific version
- of an object.
-
-4. REGISTRATION OF NEW SCHEMES
-
- A new scheme may be introduced by defining a mapping onto a
- conforming URL syntax, using a new prefix. URLs for experimental
- schemes may be used by mutual agreement between parties. Scheme names
- starting with the characters "x-" are reserved for experimental
- purposes.
-
- The Internet Assigned Numbers Authority (IANA) will maintain a
- registry of URL schemes. Any submission of a new URL scheme must
- include a definition of an algorithm for accessing of resources
- within that scheme and the syntax for representing such a scheme.
-
- URL schemes must have demonstrable utility and operability. One way
- to provide such a demonstration is via a gateway which provides
- objects in the new scheme for clients using an existing protocol. If
-
-
-
-Berners-Lee, Masinter & McCahill [Page 16]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
- the new scheme does not locate resources that are data objects, the
- properties of names in the new space must be clearly defined.
-
- New schemes should try to follow the same syntactic conventions of
- existing schemes, where appropriate. It is likewise recommended
- that, where a protocol allows for retrieval by URL, that the client
- software have provision for being configured to use specific gateway
- locators for indirect access through new naming schemes.
-
- The following scheme have been proposed at various times, but this
- document does not define their syntax or use at this time. It is
- suggested that IANA reserve their scheme names for future definition:
-
- afs Andrew File System global file names.
- mid Message identifiers for electronic mail.
- cid Content identifiers for MIME body parts.
- nfs Network File System (NFS) file names.
- tn3270 Interactive 3270 emulation sessions.
- mailserver Access to data available from mail servers.
- z39.50 Access to ANSI Z39.50 services.
-
-5. BNF for specific URL schemes
-
- This is a BNF-like description of the Uniform Resource Locator
- syntax, using the conventions of RFC822, except that "|" is used to
- designate alternatives, and brackets [] are used around optional or
- repeated elements. Briefly, literals are quoted with "", optional
- elements are enclosed in [brackets], and elements may be preceded
- with <n>* to designate n or more repetitions of the following
- element; n defaults to 0.
-
-; The generic form of a URL is:
-
-genericurl = scheme ":" schemepart
-
-; Specific predefined schemes are defined here; new schemes
-; may be registered with IANA
-
-url = httpurl | ftpurl | newsurl |
- nntpurl | telneturl | gopherurl |
- waisurl | mailtourl | fileurl |
- prosperourl | otherurl
-
-; new schemes follow the general syntax
-otherurl = genericurl
-
-; the scheme is in lower case; interpreters should use case-ignore
-scheme = 1*[ lowalpha | digit | "+" | "-" | "." ]
-
-
-
-Berners-Lee, Masinter & McCahill [Page 17]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
-schemepart = *xchar | ip-schemepart
-
-
-; URL schemeparts for ip based protocols:
-
-ip-schemepart = "//" login [ "/" urlpath ]
-
-login = [ user [ ":" password ] "@" ] hostport
-hostport = host [ ":" port ]
-host = hostname | hostnumber
-hostname = *[ domainlabel "." ] toplabel
-domainlabel = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit
-toplabel = alpha | alpha *[ alphadigit | "-" ] alphadigit
-alphadigit = alpha | digit
-hostnumber = digits "." digits "." digits "." digits
-port = digits
-user = *[ uchar | ";" | "?" | "&" | "=" ]
-password = *[ uchar | ";" | "?" | "&" | "=" ]
-urlpath = *xchar ; depends on protocol see section 3.1
-
-; The predefined schemes:
-
-; FTP (see also RFC959)
-
-ftpurl = "ftp://" login [ "/" fpath [ ";type=" ftptype ]]
-fpath = fsegment *[ "/" fsegment ]
-fsegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ]
-ftptype = "A" | "I" | "D" | "a" | "i" | "d"
-
-; FILE
-
-fileurl = "file://" [ host | "localhost" ] "/" fpath
-
-; HTTP
-
-httpurl = "http://" hostport [ "/" hpath [ "?" search ]]
-hpath = hsegment *[ "/" hsegment ]
-hsegment = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
-search = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
-
-; GOPHER (see also RFC1436)
-
-gopherurl = "gopher://" hostport [ / [ gtype [ selector
- [ "%09" search [ "%09" gopher+_string ] ] ] ] ]
-gtype = xchar
-selector = *xchar
-gopher+_string = *xchar
-
-
-
-
-Berners-Lee, Masinter & McCahill [Page 18]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
-; MAILTO (see also RFC822)
-
-mailtourl = "mailto:" encoded822addr
-encoded822addr = 1*xchar ; further defined in RFC822
-
-; NEWS (see also RFC1036)
-
-newsurl = "news:" grouppart
-grouppart = "*" | group | article
-group = alpha *[ alpha | digit | "-" | "." | "+" | "_" ]
-article = 1*[ uchar | ";" | "/" | "?" | ":" | "&" | "=" ] "@" host
-
-; NNTP (see also RFC977)
-
-nntpurl = "nntp://" hostport "/" group [ "/" digits ]
-
-; TELNET
-
-telneturl = "telnet://" login [ "/" ]
-
-; WAIS (see also RFC1625)
-
-waisurl = waisdatabase | waisindex | waisdoc
-waisdatabase = "wais://" hostport "/" database
-waisindex = "wais://" hostport "/" database "?" search
-waisdoc = "wais://" hostport "/" database "/" wtype "/" wpath
-database = *uchar
-wtype = *uchar
-wpath = *uchar
-
-; PROSPERO
-
-prosperourl = "prospero://" hostport "/" ppath *[ fieldspec ]
-ppath = psegment *[ "/" psegment ]
-psegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ]
-fieldspec = ";" fieldname "=" fieldvalue
-fieldname = *[ uchar | "?" | ":" | "@" | "&" ]
-fieldvalue = *[ uchar | "?" | ":" | "@" | "&" ]
-
-; Miscellaneous definitions
-
-lowalpha = "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"
-hialpha = "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"
-
-
-
-Berners-Lee, Masinter & McCahill [Page 19]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
-alpha = lowalpha | hialpha
-digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
- "8" | "9"
-safe = "$" | "-" | "_" | "." | "+"
-extra = "!" | "*" | "'" | "(" | ")" | ","
-national = "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]" | "`"
-punctuation = "<" | ">" | "#" | "%" | <">
-
-
-reserved = ";" | "/" | "?" | ":" | "@" | "&" | "="
-hex = digit | "A" | "B" | "C" | "D" | "E" | "F" |
- "a" | "b" | "c" | "d" | "e" | "f"
-escape = "%" hex hex
-
-unreserved = alpha | digit | safe | extra
-uchar = unreserved | escape
-xchar = unreserved | reserved | escape
-digits = 1*digit
-
-6. Security Considerations
-
- The URL scheme does not in itself pose a security threat. Users
- should beware that there is no general guarantee that a URL which at
- one time points to a given object continues to do so, and does not
- even at some later time point to a different object due to the
- movement of objects on servers.
-
- A URL-related security threat is that it is sometimes possible to
- construct a URL such that an attempt to perform a harmless idempotent
- operation such as the retrieval of the object will in fact cause a
- possibly damaging remote operation to occur. The unsafe URL is
- typically constructed by specifying a port number other than that
- reserved for the network protocol in question. The client
- unwittingly contacts a server which is in fact running a different
- protocol. The content of the URL contains instructions which when
- interpreted according to this other protocol cause an unexpected
- operation. An example has been the use of gopher URLs to cause a rude
- message to be sent via a SMTP server. Caution should be used when
- using any URL which specifies a port number other than the default
- for the protocol, especially when it is a number within the reserved
- space.
-
- Care should be taken when URLs contain embedded encoded delimiters
- for a given protocol (for example, CR and LF characters for telnet
- protocols) that these are not unencoded before transmission. This
- would violate the protocol but could be used to simulate an extra
- operation or parameter, again causing an unexpected and possible
- harmful remote operation to be performed.
-
-
-
-Berners-Lee, Masinter & McCahill [Page 20]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
- The use of URLs containing passwords that should be secret is clearly
- unwise.
-
-7. Acknowledgements
-
- This paper builds on the basic WWW design (RFC 1630) and much
- discussion of these issues by many people on the network. The
- discussion was particularly stimulated by articles by Clifford Lynch,
- Brewster Kahle [10] and Wengyik Yeong [18]. Contributions from John
- Curran, Clifford Neuman, Ed Vielmetti and later the IETF URL BOF and
- URI working group were incorporated.
-
- Most recently, careful readings and comments by Dan Connolly, Ned
- Freed, Roy Fielding, Guido van Rossum, Michael Dolan, Bert Bos, John
- Kunze, Olle Jarnefors, Peter Svanberg and many others have helped
- refine this RFC.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Berners-Lee, Masinter & McCahill [Page 21]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
-APPENDIX: Recommendations for URLs in Context
-
- URIs, including URLs, are intended to be transmitted through
- protocols which provide a context for their interpretation.
-
- In some cases, it will be necessary to distinguish URLs from other
- possible data structures in a syntactic structure. In this case, is
- recommended that URLs be preceeded with a prefix consisting of the
- characters "URL:". For example, this prefix may be used to
- distinguish URLs from other kinds of URIs.
-
- In addition, there are many occasions when URLs are included in other
- kinds of text; examples include electronic mail, USENET news
- messages, or printed on paper. In such cases, it is convenient to
- have a separate syntactic wrapper that delimits the URL and separates
- it from the rest of the text, and in particular from punctuation
- marks that might be mistaken for part of the URL. For this purpose,
- is recommended that angle brackets ("<" and ">"), along with the
- prefix "URL:", be used to delimit the boundaries of the URL. This
- wrapper does not form part of the URL and should not be used in
- contexts in which delimiters are already specified.
-
- In the case where a fragment/anchor identifier is associated with a
- URL (following a "#"), the identifier would be placed within the
- brackets as well.
-
- In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may
- need to be added to break long URLs across lines. The whitespace
- should be ignored when extracting the URL.
-
- No whitespace should be introduced after a hyphen ("-") character.
- Because some typesetters and printers may (erroneously) introduce a
- hyphen at the end of line when breaking a line, the interpreter of a
- URL containing a line break immediately after a hyphen should ignore
- all unencoded whitespace around the line break, and should be aware
- that the hyphen may or may not actually be part of the URL.
-
- Examples:
-
- Yes, Jim, I found it under <URL:ftp://info.cern.ch/pub/www/doc;
- type=d> but you can probably pick it up from <URL:ftp://ds.in
- ternic.net/rfc>. Note the warning in <URL:http://ds.internic.
- net/instructions/overview.html#WARNING>.
-
-
-
-
-
-
-
-
-Berners-Lee, Masinter & McCahill [Page 22]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
-References
-
- [1] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
- Torrey, D., and B. Alberti, "The Internet Gopher Protocol
- (a distributed document search and retrieval protocol)",
- RFC 1436, University of Minnesota, March 1993.
- <URL:ftp://ds.internic.net/rfc/rfc1436.txt;type=a>
-
- [2] Anklesaria, F., Lindner, P., McCahill, M., Torrey, D.,
- Johnson, D., and B. Alberti, "Gopher+: Upward compatible
- enhancements to the Internet Gopher protocol",
- University of Minnesota, July 1993.
- <URL:ftp://boombox.micro.umn.edu/pub/gopher/gopher_protocol
- /Gopher+/Gopher+.txt>
-
- [3] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
- Unifying Syntax for the Expression of Names and Addresses of
- Objects on the Network as used in the World-Wide Web", RFC
- 1630, CERN, June 1994.
- <URL:ftp://ds.internic.net/rfc/rfc1630.txt>
-
- [4] Berners-Lee, T., "Hypertext Transfer Protocol (HTTP)",
- CERN, November 1993.
- <URL:ftp://info.cern.ch/pub/www/doc/http-spec.txt.Z>
-
- [5] Braden, R., Editor, "Requirements for Internet Hosts --
- Application and Support", STD 3, RFC 1123, IETF, October 1989.
- <URL:ftp://ds.internic.net/rfc/rfc1123.txt>
-
- [6] Crocker, D. "Standard for the Format of ARPA Internet Text
- Messages", STD 11, RFC 822, UDEL, April 1982.
- <URL:ftp://ds.internic.net/rfc/rfc822.txt>
-
- [7] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
- Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype
- Functional Specification", (v1.5), Thinking Machines
- Corporation, April 1990.
- <URL:ftp://quake.think.com/pub/wais/doc/protspec.txt>
-
- [8] Horton, M. and R. Adams, "Standard For Interchange of USENET
- Messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic
- Studies, December 1987.
- <URL:ftp://ds.internic.net/rfc/rfc1036.txt>
-
- [9] Huitema, C., "Naming: Strategies and Techniques", Computer
- Networks and ISDN Systems 23 (1991) 107-110.
-
-
-
-
-
-Berners-Lee, Masinter & McCahill [Page 23]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
- [10] Kahle, B., "Document Identifiers, or International Standard
- Book Numbers for the Electronic Age", 1991.
- <URL:ftp://quake.think.com/pub/wais/doc/doc-ids.txt>
-
- [11] Kantor, B. and P. Lapsley, "Network News Transfer Protocol:
- A Proposed Standard for the Stream-Based Transmission of News",
- RFC 977, UC San Diego & UC Berkeley, February 1986.
- <URL:ftp://ds.internic.net/rfc/rfc977.txt>
-
- [12] Kunze, J., "Functional Requirements for Internet Resource
- Locators", Work in Progress, December 1994.
- <URL:ftp://ds.internic.net/internet-drafts
- /draft-ietf-uri-irl-fun-req-02.txt>
-
- [13] Mockapetris, P., "Domain Names - Concepts and Facilities",
- STD 13, RFC 1034, USC/Information Sciences Institute,
- November 1987.
- <URL:ftp://ds.internic.net/rfc/rfc1034.txt>
-
- [14] Neuman, B., and S. Augart, "The Prospero Protocol",
- USC/Information Sciences Institute, June 1993.
- <URL:ftp://prospero.isi.edu/pub/prospero/doc
- /prospero-protocol.PS.Z>
-
- [15] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)",
- STD 9, RFC 959, USC/Information Sciences Institute,
- October 1985.
- <URL:ftp://ds.internic.net/rfc/rfc959.txt>
-
- [16] Sollins, K. and L. Masinter, "Functional Requirements for
- Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation,
- December 1994.
- <URL:ftp://ds.internic.net/rfc/rfc1737.txt>
-
- [17] St. Pierre, M, Fullton, J., Gamiel, K., Goldman, J., Kahle, B.,
- Kunze, J., Morris, H., and F. Schiettecatte, "WAIS over
- Z39.50-1988", RFC 1625, WAIS, Inc., CNIDR, Thinking Machines
- Corp., UC Berkeley, FS Consulting, June 1994.
- <URL:ftp://ds.internic.net/rfc/rfc1625.txt>
-
- [18] Yeong, W. "Towards Networked Information Retrieval", Technical
- report 91-06-25-01, Performance Systems International, Inc.
- <URL:ftp://uu.psi.com/wp/nir.txt>, June 1991.
-
- [19] Yeong, W., "Representing Public Archives in the Directory",
- Work in Progress, November 1991.
-
-
-
-
-
-Berners-Lee, Masinter & McCahill [Page 24]
-
-RFC 1738 Uniform Resource Locators (URL) December 1994
-
-
- [20] "Coded Character Set -- 7-bit American Standard Code for
- Information Interchange", ANSI X3.4-1986.
-
-Editors' Addresses
-
-Tim Berners-Lee
-World-Wide Web project
-CERN,
-1211 Geneva 23,
-Switzerland
-
-Phone: +41 (22)767 3755
-Fax: +41 (22)767 7155
-EMail: [email protected]
-
-
-Larry Masinter
-Xerox PARC
-3333 Coyote Hill Road
-Palo Alto, CA 94034
-
-Phone: (415) 812-4365
-Fax: (415) 812-4333
-EMail: [email protected]
-
-
-Mark McCahill
-Computer and Information Services,
-University of Minnesota
-Room 152 Shepherd Labs
-100 Union Street SE
-Minneapolis, MN 55455
-
-Phone: (612) 625 1300
-EMail: [email protected]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Berners-Lee, Masinter & McCahill [Page 25]
-
diff --git a/doc/rfc/rfc1870.txt b/doc/rfc/rfc1870.txt
deleted file mode 100644
index edf3c98..0000000
--- a/doc/rfc/rfc1870.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Klensin, WG Chair
-Request For Comments: 1870 MCI
-STD: 10 N. Freed, Editor
-Obsoletes: 1653 Innosoft International, Inc.
-Category: Standards Track K. Moore
- University of Tennessee
- November 1995
-
-
- SMTP Service Extension
- for Message Size Declaration
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-1. Abstract
-
- This memo defines an extension to the SMTP service whereby an SMTP
- client and server may interact to give the server an opportunity to
- decline to accept a message (perhaps temporarily) based on the
- client's estimate of the message size.
-
-2. Introduction
-
- The MIME extensions to the Internet message protocol provide for the
- transmission of many kinds of data which were previously unsupported
- in Internet mail. One expected result of the use of MIME is that
- SMTP will be expected to carry a much wider range of message sizes
- than was previously the case. This has an impact on the amount of
- resources (e.g. disk space) required by a system acting as a server.
-
- This memo uses the mechanism defined in [5] to define extensions to
- the SMTP service whereby a client ("sender-SMTP") may declare the
- size of a particular message to a server ("receiver-SMTP"), after
- which the server may indicate to the client that it is or is not
- willing to accept the message based on the declared message size and
- whereby a server ("receiver-SMTP") may declare the maximum message
- size it is willing to accept to a client ("sender-SMTP").
-
-
-
-
-
-
-
-
-Klensin, et al Standards Track [Page 1]
-
-RFC 1870 SMTP Size Declaration November 1995
-
-
-3. Framework for the Size Declaration Extension
-
- The following service extension is therefore defined:
-
- (1) the name of the SMTP service extension is "Message Size
- Declaration";
-
- (2) the EHLO keyword value associated with this extension is "SIZE";
-
- (3) one optional parameter is allowed with this EHLO keyword value, a
- decimal number indicating the fixed maximum message size in bytes
- that the server will accept. The syntax of the parameter is as
- follows, using the augmented BNF notation of [2]:
-
- size-param ::= [1*DIGIT]
-
- A parameter value of 0 (zero) indicates that no fixed maximum
- message size is in force. If the parameter is omitted no
- information is conveyed about the server's fixed maximum message
- size;
-
- (4) one optional parameter using the keyword "SIZE" is added to the
- MAIL FROM command. The value associated with this parameter is a
- decimal number indicating the size of the message that is to be
- transmitted. The syntax of the value is as follows, using the
- augmented BNF notation of [2]:
-
- size-value ::= 1*20DIGIT
-
- (5) the maximum length of a MAIL FROM command line is increased by 26
- characters by the possible addition of the SIZE keyword and
- value;
-
- (6) no additional SMTP verbs are defined by this extension.
-
- The remainder of this memo specifies how support for the extension
- affects the behavior of an SMTP client and server.
-
-4. The Message Size Declaration service extension
-
- An SMTP server may have a fixed upper limit on message size. Any
- attempt by a client to transfer a message which is larger than this
- fixed upper limit will fail. In addition, a server normally has
- limited space with which to store incoming messages. Transfer of a
- message may therefore also fail due to a lack of storage space, but
- might succeed at a later time.
-
-
-
-
-
-Klensin, et al Standards Track [Page 2]
-
-RFC 1870 SMTP Size Declaration November 1995
-
-
- A client using the unextended SMTP protocol defined in [1], can only
- be informed of such failures after transmitting the entire message to
- the server (which discards the transferred message). If, however,
- both client and server support the Message Size Declaration service
- extension, such conditions may be detected before any transfer is
- attempted.
-
- An SMTP client wishing to relay a large content may issue the EHLO
- command to start an SMTP session, to determine if the server supports
- any of several service extensions. If the server responds with code
- 250 to the EHLO command, and the response includes the EHLO keyword
- value SIZE, then the Message Size Declaration extension is supported.
-
- If a numeric parameter follows the SIZE keyword value of the EHLO
- response, it indicates the size of the largest message that the
- server is willing to accept. Any attempt by a client to transfer a
- message which is larger than this limit will be rejected with a
- permanent failure (552) reply code.
-
- A server that supports the Message Size Declaration extension will
- accept the extended version of the MAIL command described below.
- When supported by the server, a client may use the extended MAIL
- command (instead of the MAIL command as defined in [1]) to declare an
- estimate of the size of a message it wishes to transfer. The server
- may then return an appropriate error code if it determines that an
- attempt to transfer a message of that size would fail.
-
-5. Definitions
-
- The message size is defined as the number of octets, including CR-LF
- pairs, but not the SMTP DATA command's terminating dot or doubled
- quoting dots, to be transmitted by the SMTP client after receiving
- reply code 354 to the DATA command.
-
- The fixed maximum message size is defined as the message size of the
- largest message that a server is ever willing to accept. An attempt
- to transfer any message larger than the fixed maximum message size
- will always fail. The fixed maximum message size may be an
- implementation artifact of the SMTP server, or it may be chosen by
- the administrator of the server.
-
- The declared message size is defined as a client's estimate of the
- message size for a particular message.
-
-
-
-
-
-
-
-
-Klensin, et al Standards Track [Page 3]
-
-RFC 1870 SMTP Size Declaration November 1995
-
-
-6. The extended MAIL command
-
- The extended MAIL command is issued by a client when it wishes to
- inform a server of the size of the message to be sent. The extended
- MAIL command is identical to the MAIL command as defined in [1],
- except that a SIZE parameter appears after the address.
-
- The complete syntax of this extended command is defined in [5]. The
- esmtp-keyword is "SIZE" and the syntax for esmtp-value is given by
- the syntax for size-value shown above.
-
- The value associated with the SIZE parameter is a decimal
- representation of the declared message size in octets. This number
- should include the message header, body, and the CR-LF sequences
- between lines, but not the SMTP DATA command's terminating dot or
- doubled quoting dots. Only one SIZE parameter may be specified in a
- single MAIL command.
-
- Ideally, the declared message size is equal to the true message size.
- However, since exact computation of the message size may be
- infeasable, the client may use a heuristically-derived estimate.
- Such heuristics should be chosen so that the declared message size is
- usually larger than the actual message size. (This has the effect of
- making the counting or non-counting of SMTP DATA dots largely an
- academic point.)
-
- NOTE: Servers MUST NOT use the SIZE parameter to determine end of
- content in the DATA command.
-
-6.1 Server action on receipt of the extended MAIL command
-
- Upon receipt of an extended MAIL command containing a SIZE parameter,
- a server should determine whether the declared message size exceeds
- its fixed maximum message size. If the declared message size is
- smaller than the fixed maximum message size, the server may also wish
- to determine whether sufficient resources are available to buffer a
- message of the declared message size and to maintain it in stable
- storage, until the message can be delivered or relayed to each of its
- recipients.
-
- A server may respond to the extended MAIL command with any of the
- error codes defined in [1] for the MAIL command. In addition, one of
- the following error codes may be returned:
-
- (1) If the server currently lacks sufficient resources to accept a
- message of the indicated size, but may be able to accept the
- message at a later time, it responds with code "452 insufficient
- system storage".
-
-
-
-Klensin, et al Standards Track [Page 4]
-
-RFC 1870 SMTP Size Declaration November 1995
-
-
- (2) If the indicated size is larger than the server's fixed maximum
- message size, the server responds with code "552 message size
- exceeds fixed maximium message size".
-
- A server is permitted, but not required, to accept a message which
- is, in fact, larger than declared in the extended MAIL command, such
- as might occur if the client employed a size-estimation heuristic
- which was inaccurate.
-
-6.2 Client action on receiving response to extended MAIL command
-
- The client, upon receiving the server's response to the extended MAIL
- command, acts as follows:
-
- (1) If the code "452 insufficient system storage" is returned, the
- client should next send either a RSET command (if it wishes to
- attempt to send other messages) or a QUIT command. The client
- should then repeat the attempt to send the message to the server
- at a later time.
-
- (2) If the code "552 message exceeds fixed maximum message size" is
- received, the client should immediately send either a RSET command
- (if it wishes to attempt to send additional messages), or a QUIT
- command. The client should then declare the message undeliverable
- and return appropriate notification to the sender (if a sender
- address was present in the MAIL command).
-
- A successful (250) reply code in response to the extended MAIL
- command does not constitute an absolute guarantee that the message
- transfer will succeed. SMTP clients using the extended MAIL command
- must still be prepared to handle both temporary and permanent error
- reply codes (including codes 452 and 552), either immediately after
- issuing the DATA command, or after transfer of the message.
-
-6.3 Messages larger than the declared size.
-
- Once a server has agreed (via the extended MAIL command) to accept a
- message of a particular size, it should not return a 552 reply code
- after the transfer phase of the DATA command, unless the actual size
- of the message transferred is greater than the declared message size.
- A server may also choose to accept a message which is somewhat larger
- than the declared message size.
-
- A client is permitted to declare a message to be smaller than its
- actual size. However, in this case, a successful (250) reply code is
- no assurance that the server will accept the message or has
- sufficient resources to do so. The server may reject such a message
- after its DATA transfer.
-
-
-
-Klensin, et al Standards Track [Page 5]
-
-RFC 1870 SMTP Size Declaration November 1995
-
-
-6.4 Per-recipient rejection based on message size.
-
- A server that implements this extension may return a 452 or 552 reply
- code in response to a RCPT command, based on its unwillingness to
- accept a message of the declared size for a particular recipient.
-
- (1) If a 452 code is returned, the client may requeue the message for
- later delivery to the same recipient.
-
- (2) If a 552 code is returned, the client may not requeue the message
- for later delivery to the same recipient.
-
-7. Minimal usage
-
- A "minimal" client may use this extension to simply compare its
- (perhaps estimated) size of the message that it wishes to relay, with
- the server's fixed maximum message size (from the parameter to the
- SIZE keyword in the EHLO response), to determine whether the server
- will ever accept the message. Such an implementation need not
- declare message sizes via the extended MAIL command. However,
- neither will it be able to discover temporary limits on message size
- due to server resource limitations, nor per-recipient limitations on
- message size.
-
- A minimal server that employs this service extension may simply use
- the SIZE keyword value to inform the client of the size of the
- largest message it will accept, or to inform the client that there is
- no fixed limit on message size. Such a server must accept the
- extended MAIL command and return a 552 reply code if the client's
- declared size exceeds its fixed size limit (if any), but it need not
- detect "temporary" limitations on message size.
-
- The numeric parameter to the EHLO SIZE keyword is optional. If the
- parameter is omitted entirely it indicates that the server does not
- advertise a fixed maximum message size. A server that returns the
- SIZE keyword with no parameter in response to the EHLO command may
- not issue a positive (250) response to an extended MAIL command
- containing a SIZE specification without first checking to see if
- sufficient resources are available to transfer a message of the
- declared size, and to retain it in stable storage until it can be
- relayed or delivered to its recipients. If possible, the server
- should actually reserve sufficient storage space to transfer the
- message.
-
-
-
-
-
-
-
-
-Klensin, et al Standards Track [Page 6]
-
-RFC 1870 SMTP Size Declaration November 1995
-
-
-8. Example
-
- The following example illustrates the use of size declaration with
- some permanent and temporary failures.
-
- S: <wait for connection on TCP port 25>
- C: <open connection to server>
- S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
- C: EHLO ymir.claremont.edu
- S: 250-sigurd.innosoft.com
- S: 250-EXPN
- S: 250-HELP
- S: 250 SIZE 1000000
- C: MAIL FROM:<[email protected]> SIZE=500000
- S: 250 Address Ok.
- C: RCPT TO:<[email protected]>
- S: 250 [email protected] OK; can accomodate 500000 byte message
- C: RCPT TO:<[email protected]>
- S: 552 Channel size limit exceeded: [email protected]
- C: RCPT TO:<[email protected]>
- S: 452 Insufficient channel storage: [email protected]
- 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: [email protected]
-
-
- 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: [email protected]
-
-
- Keith Moore
- Computer Science Dept.
- University of Tennessee
- 107 Ayres Hall
- Knoxville, TN 37996-1301
- USA
-
- EMail: [email protected]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin, et al Standards Track [Page 9]
-
diff --git a/doc/rfc/rfc1891.txt b/doc/rfc/rfc1891.txt
deleted file mode 100644
index 23b58ba..0000000
--- a/doc/rfc/rfc1891.txt
+++ /dev/null
@@ -1,1739 +0,0 @@
-
-
-
-
-
-
-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
- <[email protected]>. Requests to subscribe to the mailing
- list should be addressed to <[email protected]>.
- 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 [email protected] and later forwarded to [email protected], after such forwarding has
- taken place, the RCPT command will specify a mailbox of [email protected].
- However, the original recipient address remains [email protected].
-
- 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 [email protected] to
- [email protected], [email protected], [email protected],
- [email protected], [email protected], and [email protected], 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:<[email protected]> RET=HDRS ENVID=QQ314159
-<<< 250 <[email protected]> sender ok
->>> RCPT TO:<[email protected]> NOTIFY=SUCCESS \
- ORCPT=rfc822;[email protected]
-<<< 250 <[email protected]> recipient ok
->>> RCPT TO:<[email protected]> NOTIFY=FAILURE \
- ORCPT=rfc822;[email protected]
-<<< 250 <[email protected]> recipient ok
->>> RCPT TO:<[email protected]> NOTIFY=SUCCESS,FAILURE \
- ORCPT=rfc822;[email protected]
-<<< 250 <[email protected]> recipient ok
-
-
-
-Moore Standards Track [Page 23]
-
-RFC 1891 SMTP Delivery Status Notifications January 1996
-
-
->>> RCPT TO:<[email protected]> NOTIFY=FAILURE \
- ORCPT=rfc822;[email protected]
-<<< 250 <[email protected]> recipient ok
->>> RCPT TO:<[email protected]> NOTIFY=NEVER
-<<< 250 <[email protected]> recipient ok
->>> RCPT TO:<[email protected]> NOTIFY=FAILURE \
- ORCPT=rfc822;[email protected]
-<<< 250 <[email protected]> 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:<[email protected]> RET=HDRS ENVID=QQ314159
-<<< 250 sender okay
->>> RCPT TO:<[email protected]> NOTIFY=SUCCESS \
- ORCPT=rfc822;[email protected]
-<<< 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:<[email protected]> RET=HDRS ENVID=QQ314159
-<<< 250 ok
->>> RCPT TO:<[email protected]> NOTIFY=FAILURE \
- ORCPT=rfc822;[email protected]
-<<< 550 error - no such recipient
->>> RCPT TO:<[email protected]> NOTIFY=SUCCESS,FAILURE \
- ORCPT=rfc822;[email protected]
-<<< 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
- [email protected], 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 [email protected], 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:<[email protected]>
-<<< 250 ok
->>> RCPT TO:<[email protected]>
-<<< 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:<[email protected]>
-<<< 250 ok
->>> DATA
-<<< 354 send message
->>> (message goes here)
->>> .
-<<< 250 message accepted
->>> QUIT
-<<< 221 Bombs.AF.MIL closing connection
-
-10.5 Forward from [email protected] to [email protected]
-
- 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
- [email protected] (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:<[email protected]> RET=HDRS ENVID=QQ314159
-<<< 250 sender okay
->>> RCPT TO:<[email protected]> NOTIFY=SUCCESS \
- ORCPT=rfc822;[email protected]
-<<< 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 [email protected]
-
- 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: [email protected]
-From: [email protected]
-Subject: Delivery Notification (success) for [email protected]
-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
[email protected].
-
---abcde
-Content-type: message/delivery-status
-
-Reporting-MTA: dns; mail.Big-Bucks.COM
-Original-Envelope-ID: QQ314159
-
-Original-Recipient: rfc822;[email protected]
-Final-Recipient: rfc822;[email protected]
-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 [email protected]
-
- Because delivery to Carol failed and the sender specified
- NOTIFY=FAILURE for [email protected], MTA Pure-Heart.ORG (the SMTP
- client to which the failure was reported via SMTP) issues the
- following DSN.
-
-To: [email protected]
-From: [email protected]
-Subject: Delivery Notification (failure) for [email protected]
-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
[email protected].
-
-A transcript of the session follows:
-
-(while talking to Ivory.EDU)
->>> RCPT TO:<[email protected]> 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;[email protected]
-Final-Recipient: rfc822;[email protected]
-SMTP-Remote-Recipient: [email protected]
-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 [email protected]
-
- 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: [email protected]
-From: [email protected]
-Subject: mail relayed for [email protected]
-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 [email protected]) 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;[email protected]
-Final-Recipient: rfc822;[email protected]
-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 [email protected]
-
- The message originally addressed to [email protected] was forwarded
- to [email protected], 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: [email protected]
-From: [email protected]
-Subject: Delivery failure for [email protected]
-Content-Type: multipart/report; report-type=delivery-status;
- boundary=defgh
-MIME-Version: 1.0
-
---defgh
-Your message, originally addressed to [email protected], and forwarded
-from there to [email protected] 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;[email protected]
-Final-Recipient: rfc822;[email protected]
-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: [email protected]
-
-
-
-
-
-Moore Standards Track [Page 31]
-
diff --git a/doc/rfc/rfc1892.txt b/doc/rfc/rfc1892.txt
deleted file mode 100644
index c4bdbd5..0000000
--- a/doc/rfc/rfc1892.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-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: [email protected]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vaudreuil Standards Track [Page 4]
-
diff --git a/doc/rfc/rfc1893.txt b/doc/rfc/rfc1893.txt
deleted file mode 100644
index 9ca4efb..0000000
--- a/doc/rfc/rfc1893.txt
+++ /dev/null
@@ -1,843 +0,0 @@
-
-
-
-
-
-
-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: [email protected]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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/doc/rfc/rfc1894.txt b/doc/rfc/rfc1894.txt
deleted file mode 100644
index f1fc90d..0000000
--- a/doc/rfc/rfc1894.txt
+++ /dev/null
@@ -1,2187 +0,0 @@
-
-
-
-
-
-
-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
- <[email protected]>. Requests to subscribe to the mailing
- list should be addressed to <[email protected]>.
- 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 | <No! | MTA |
-|agent| +--------+ +---------+ +----v----+ +------+
-| | |
-| | <-------------------------------------------+
-+-----+ (DSN returned to sender by Reporting MTA)
-
-
- Figure 1. Original, Received-From, Reporting and Remote MTAs
-
-
- Each of these MTAs may provide information which is useful in a DSN:
-
-+ Ideally, the DSN will contain the address of each recipient as
- originally specified to the Original MTA by the sender of the message.
- This version of the address is needed (rather than a forwarding
- address or some modified version of the original address) so that the
- sender may compare the recipient address in the DSN with the address
- in the sender's records (e.g. an address book for an individual, the
- list of subscribers for a mailing list) and take appropriate action.
-
- Similarly, the DSN might contain an "envelope identifier" that was
- known to both the sender's user agent and the Original MTA at the time
- of message submission, and which, if included in the DSN, can be used
- by the sender to keep track of which messages were or were not
- delivered.
-
-+ If a message was (a) forwarded to a different address than that
- specified by the sender, (b) gatewayed to a different mail system than
- that used by the sender, or (c) subjected to address rewriting during
- transmission, the "final" form of the recipient address (i.e. the one
- seen by the Reporting MTA) will be different than the original
- (sender-specified) recipient address. Just as the sender's user agent
- (or the sender) prefers the original recipient address, so the "final"
- address is needed when reporting a problem to the postmaster of the
- site where message delivery failed, because only the final recipient
- address will allow her to reproduce the conditions that caused the
- failure.
-
-+ A "failed" DSN should contain the most accurate explanation for the
- delivery failure that is available. For ease of interpretation, this
- information should be a format which is independent of the mail
- transport system that issued the DSN. However, if a foreign error
-
-
-
-Moore & Vaudreuil Standards Track [Page 5]
-
-RFC 1894 Delivery Status Notifications January 1996
-
-
- code is translated into some transport-independent format, some
- information may be lost. It is therefore desirable to provide both a
- transport-independent status code and a mechanism for reporting
- transport-specific codes. Depending on the circumstances that
- produced delivery failure, the transport-specific code might be
- obtained from either the Reporting MTA or the Remote MTA.
-
- Since different values for "recipient address" and "delivery status
- code" are needed according to the circumstance in which a DSN will be
- used, and since the MTA that issues the DSN cannot anticipate those
- circumstances, the DSN format described here may contain both the
- original and final forms of a recipient address, and both a
- transport-independent and a transport-specific indication of delivery
- status.
-
- Extension fields may also be added by the Reporting MTA as needed to
- provide additional information for use in a trouble ticket or to
- preserve information for tunneling of foreign delivery reports
- through Internet DSNs.
-
- The Original, Reporting, and Remote MTAs may exist in very different
- environments and use dissimilar transport protocols, MTA names,
- address formats, and delivery status codes. DSNs therefore do not
- assume any particular format for mailbox addresses, MTA names, or
- transport-specific status codes. Instead, the various DSN fields
- that carry such quantities consist of a "type" subfield followed by a
- subfield whose contents are ordinary text characters, and the format
- of which is indicated by the "type" subfield. This allows a DSN to
- convey these quantities regardless of format.
-
-2. Format of a Delivery Status Notification
-
- A DSN is a MIME message with a top-level content-type of
- multipart/report (defined in [2]). When a multipart/report content
- is used to transmit a DSN:
-
-(a) The report-type parameter of the multipart/report content is
- "delivery-status".
-
-(b) The first component of the multipart/report contains a human-
- readable explanation of the DSN, as described in [2].
-
-(c) The second component of the multipart/report is of content-type
- message/delivery-status, described in section 2.1 of this document.
-
-(d) If the original message or a portion of the message is to be
- returned to the sender, it appears as the third component of the
- multipart/report.
-
-
-
-Moore & Vaudreuil Standards Track [Page 6]
-
-RFC 1894 Delivery Status Notifications January 1996
-
-
- NOTE: For delivery status notifications gatewayed from foreign
- systems, the headers of the original message may not be available.
- In this case the third component of the DSN may be omitted, or it
- may contain "simulated" RFC 822 headers which contain equivalent
- information. In particular, it is very desirable to preserve the
- subject, date, and message-id (or equivalent) fields from the
- original message.
-
- The DSN MUST be addressed (in both the message header and the
- transport envelope) to the return address from the transport envelope
- which accompanied the original message for which the DSN was
- generated. (For a message that arrived via SMTP, the envelope return
- address appears in the MAIL FROM command.)
-
- The From field of the message header of the DSN SHOULD contain the
- address of a human who is responsible for maintaining the mail system
- at the Reporting MTA site (e.g. Postmaster), so that a reply to the
- DSN will reach that person. Exception: if a DSN is translated from a
- foreign delivery report, and the gateway performing the translation
- cannot determine the appropriate address, the From field of the DSN
- MAY be the address of a human who is responsible for maintaining the
- gateway.
-
- The envelope sender address of the DSN SHOULD be chosen to ensure
- that no delivery status reports will be issued in response to the DSN
- itself, and MUST be chosen so that DSNs will not generate mail loops.
- Whenever an SMTP transaction is used to send a DSN, the MAIL FROM
- command MUST use a NULL return address, i.e. "MAIL FROM:<>".
-
- 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 |<No| MTA |
- |agent| +--------+ |Gateway | +---------+ +----v----+ +------+
- | | | | |
- | | <============| |<-------------------+
- +-----+ | |(4) (3)
- +--------+
- : :
-...........................: :.........................................
-
- Figure 2. DSNs in the presence of gateways
-
- (1) message is gatewayed into recipient's environment
- (2) attempt to relay message fails
- (3) reporting-mta (in recipient's environment) returns nondelivery
- notification
- (4) gateway translates foreign notification into a DSN
-
-
-
- The mta-name portion of the Reporting-MTA field is formatted
- according to the conventions indicated by the mta-name-type subfield.
- If an MTA functions as a gateway between dissimilar mail environments
- and thus is known by multiple names depending on the environment, the
- mta-name subfield SHOULD contain the name used by the environment
- from which the message was accepted by the Reporting-MTA.
-
- Because the exact spelling of an MTA name may be significant in a
- particular environment, MTA names are CASE-SENSITIVE.
-
-2.2.3 The DSN-Gateway field
-
- The DSN-Gateway field indicates the name of the gateway or MTA which
- translated a foreign (non-Internet) delivery status notification into
- this DSN. This field MUST appear in any DSN which was translated by
- a gateway from a foreign system into DSN format, and MUST NOT appear
- otherwise.
-
- dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name
-
-
-
-
-
-
-Moore & Vaudreuil Standards Track [Page 13]
-
-RFC 1894 Delivery Status Notifications January 1996
-
-
- For gateways into Internet mail, the MTA-name-type will normally be
- "smtp", and the mta-name will be the Internet domain name of the
- gateway.
-
-2.2.4 The Received-From-MTA DSN field
-
- The optional Received-From-MTA field indicates the name of the MTA
- from which the message was received.
-
- received-from-mta-field =
- "Received-From-MTA" ":" mta-name-type ";" mta-name
-
- If the message was received from an Internet host via SMTP, the
- contents of the mta-name subfield SHOULD be the Internet domain name
- supplied in the HELO or EHLO command, and the network address used by
- the SMTP client SHOULD be included as a comment enclosed in
- parentheses. (In this case, the MTA-name-type will be "smtp".)
-
- The mta-name portion of the Received-From-MTA field is formatted
- according to the conventions indicated by the MTA-name-type subfield.
-
- Since case is significant in some mail systems, the exact spelling,
- including case, of the MTA name SHOULD be preserved.
-
-2.2.5 The Arrival-Date DSN field
-
- The optional Arrival-Date field indicates the date and time at which
- the message arrived at the Reporting MTA. If the Last-Attempt-Date
- field is also provided in a per-recipient field, this can be used to
- determine the interval between when the message arrived at the
- Reporting MTA and when the report was issued for that recipient.
-
- arrival-date-field = "Arrival-Date" ":" date-time
-
- The date and time are expressed in RFC 822 'date-time' format, as
- modified by [8]. Numeric timezones ([+/-]HHMM format) MUST be used.
-
-2.3 Per-Recipient DSN fields
-
- A DSN contains information about attempts to deliver a message to one
- or more recipients. The delivery information for any particular
- recipient is contained in a group of contiguous per-recipient fields.
- Each group of per-recipient fields is preceded by a blank line.
-
-
-
-
-
-
-
-
-Moore & Vaudreuil Standards Track [Page 14]
-
-RFC 1894 Delivery Status Notifications January 1996
-
-
- The syntax for the group of per-recipient fields is as follows:
-
-
- 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 )
-
-2.3.1 Original-Recipient field
-
- The Original-Recipient field indicates the original recipient address
- as specified by the sender of the message for which the DSN is being
- issued.
-
- original-recipient-field =
- "Original-Recipient" ":" address-type ";" generic-address
-
- generic-address = *text
-
- The address-type field indicates the type of the original recipient
- address. If the message originated within the Internet, the
- address-type field field will normally be "rfc822", and the address
- will be according to the syntax specified in [6]. The value
- "unknown" should be used if the Reporting MTA cannot determine the
- type of the original recipient address from the message envelope.
-
- This field is optional. It should be included only if the sender-
- specified recipient address was present in the message envelope, such
- as by the SMTP extensions defined in [4]. This address is the same
- as that provided by the sender and can be used to automatically
- correlate DSN reports and message transactions.
-
-2.3.2 Final-Recipient field
-
- The Final-Recipient field indicates the recipient for which this set
- of per-recipient fields applies. This field MUST be present in each
- set of per-recipient data.
-
-
-
-
-
-
-
-
-Moore & Vaudreuil Standards Track [Page 15]
-
-RFC 1894 Delivery Status Notifications January 1996
-
-
- The syntax of the field is as follows:
-
- final-recipient-field =
- "Final-Recipient" ":" address-type ";" generic-address
-
- The generic-address subfield of the Final-Recipient field MUST
- contain the mailbox address of the recipient (from the transport
- envelope) as it was when the message was accepted for delivery by the
- Reporting MTA.
-
- The Final-Recipient address may differ from the address originally
- provided by the sender, because it may have been transformed during
- forwarding and gatewaying into an totally unrecognizable mess.
- However, in the absence of the optional Original-Recipient field, the
- Final-Recipient field and any returned content may be the only
- information available with which to correlate the DSN with a
- particular message submission.
-
- The address-type subfield indicates the type of address expected by
- the reporting MTA in that context. Recipient addresses obtained via
- SMTP will normally be of address-type "rfc822".
-
- NOTE: The Reporting MTA is not expected to ensure that the address
- actually conforms to the syntax conventions of the address-type.
- Instead, it MUST report exactly the address received in the envelope,
- unless that address contains characters such as CR or LF which may
- not appear in a DSN field.
-
- Since mailbox addresses (including those used in the Internet) may be
- case sensitive, the case of alphabetic characters in the address MUST
- be preserved.
-
-2.3.3 Action field
-
- The Action field indicates the action performed by the Reporting-MTA
- as a result of its attempt to deliver the message to this recipient
- address. This field MUST be present for each recipient named in the
- DSN.
-
- The syntax for the action-field is:
-
- action-field = "Action" ":" action-value
-
- action-value =
- "failed" / "delayed" / "delivered" / "relayed" / "expanded"
-
-
-
-
-
-
-Moore & Vaudreuil Standards Track [Page 16]
-
-RFC 1894 Delivery Status Notifications January 1996
-
-
- The action-value may be spelled in any combination of upper and lower
- case characters.
-
-"failed" indicates that the message could not be delivered to the
- recipient. The Reporting MTA has abandoned any attempts to
- deliver the message to this recipient. No further
- notifications should be expected.
-
-"delayed" indicates that the Reporting MTA has so far been unable to
- deliver or relay the message, but it will continue to
- attempt to do so. Additional notification messages may be
- issued as the message is further delayed or successfully
- delivered, or if delivery attempts are later abandoned.
-
-"delivered" indicates that the message was successfully delivered to
- the recipient address specified by the sender, which
- includes "delivery" to a mailing list exploder. It does
- not indicate that the message has been read. This is a
- terminal state and no further DSN for this recipient should
- be expected.
-
-"relayed" indicates that the message has been relayed or gatewayed
- into an environment that does not accept responsibility for
- generating DSNs upon successful delivery. This action-
- value SHOULD NOT be used unless the sender has requested
- notification of successful delivery for this recipient.
-
-"expanded" indicates that the message has been successfully delivered
- to the recipient address as specified by the sender, and
- forwarded by the Reporting-MTA beyond that destination to
- multiple additional recipient addresses. An action-value
- of "expanded" differs from "delivered" in that "expanded"
- is not a terminal state. Further "failed" and/or "delayed"
- notifications may be provided.
-
- Using the terms "mailing list" and "alias" as defined in
- [4], section 7.2.7: An action-value of "expanded" is only
- to be used when the message is delivered to a multiple-
- recipient "alias". An action-value of "expanded" SHOULD
- NOT be used with a DSN issued on delivery of a message to a
- "mailing list".
-
- NOTE ON ACTION VS. STATUS CODES: Although the 'action' field might
- seem to be redundant with the 'status' field, this is not the case.
- In particular, a "temporary failure" ("4") status code could be used
- with an action-value of either "delayed" or "failed". For example,
- assume that an SMTP client repeatedly tries to relay a message to the
- mail exchanger for a recipient, but fails because a query to a domain
-
-
-
-Moore & Vaudreuil Standards Track [Page 17]
-
-RFC 1894 Delivery Status Notifications January 1996
-
-
- name server timed out. After a few hours, it might issue a "delayed"
- DSN to inform the sender that the message had not yet been delivered.
- After a few days, the MTA might abandon its attempt to deliver the
- message and return a "failed" DSN. The status code (which would
- begin with a "4" to indicate "temporary failure") would be the same
- for both DSNs.
-
- Another example for which the action and status codes may appear
- contradictory: If an MTA or mail gateway cannot deliver a message
- because doing so would entail conversions resulting in an
- unacceptable loss of information, it would issue a DSN with the
- 'action' field of "failure" and a status code of 'XXX'. If the
- message had instead been relayed, but with some loss of information,
- it might generate a DSN with the same XXX status-code, but with an
- action field of "relayed".
-
-2.3.4 Status field
-
- The per-recipient Status field contains a transport-independent
- status code which indicates the delivery status of the message to
- that recipient. This field MUST be present for each delivery attempt
- which is described by a DSN.
-
- The syntax of the status field is:
-
- status-field = "Status" ":" status-code
-
- 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 codes thus consist of three numerical fields separated by ".".
- The first sub-field indicates whether the delivery attempt was
- successful (2 = success, 4 = persistent temporary failure, 5 =
- permanent failure). The second sub-field indicates the probable
- source of any delivery anomalies, and the third sub-field denotes a
- precise error condition, if known.
-
- The initial set of status-codes is defined in [5].
-
-
-
-
-
-
-
-
-Moore & Vaudreuil Standards Track [Page 18]
-
-RFC 1894 Delivery Status Notifications January 1996
-
-
-2.3.5 Remote-MTA field
-
- The value associated with the Remote-MTA DSN field is a printable
- ASCII representation of the name of the "remote" MTA that reported
- delivery status to the "reporting" MTA.
-
- remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name
-
- NOTE: The Remote-MTA field preserves the "while talking to"
- information that was provided in some pre-existing nondelivery
- reports.
-
- This field is optional. It MUST NOT be included if no remote MTA was
- involved in the attempted delivery of the message to that recipient.
-
-2.3.6 Diagnostic-Code field
-
- For a "failed" or "delayed" recipient, the Diagnostic-Code DSN field
- contains the actual diagnostic code issued by the mail transport.
- Since such codes vary from one mail transport to another, the
- diagnostic-type subfield is needed to specify which type of
- diagnostic code is represented.
-
- diagnostic-code-field =
- "Diagnostic-Code" ":" diagnostic-type ";" *text
-
- NOTE: The information in the Diagnostic-Code field may be somewhat
- redundant with that from the Status field. The Status field is
- needed so that any DSN, regardless of origin, may be understood by
- any user agent or gateway that parses DSNs. Since the Status code
- will sometimes be less precise than the actual transport diagnostic
- code, the Diagnostic-Code field is provided to retain the latter
- information. Such information may be useful in a trouble ticket sent
- to the administrator of the Reporting MTA, or when tunneling foreign
- nondelivery reports through DSNs.
-
- If the Diagnostic Code was obtained from a Remote MTA during an
- attempt to relay the message to that MTA, the Remote-MTA field should
- be present. When interpreting a DSN, the presence of a Remote-MTA
- field indicates that the Diagnostic Code was issued by the Remote
- MTA. The absence of a Remote-MTA indicates that the Diagnostic Code
- was issued by the Reporting MTA.
-
- In addition to the Diagnostic-Code itself, additional textual
- description of the diagnostic, MAY appear in a comment enclosed in
- parentheses.
-
-
-
-
-
-Moore & Vaudreuil Standards Track [Page 19]
-
-RFC 1894 Delivery Status Notifications January 1996
-
-
- This field is optional, because some mail systems supply no
- additional information beyond that which is returned in the 'action'
- and 'status' fields. However, this field SHOULD be included if
- transport-specific diagnostic information is available.
-
-2.3.7 Last-Attempt-Date field
-
- The Last-Attempt-Date field gives the date and time of the last
- attempt to relay, gateway, or deliver the message (whether successful
- or unsuccessful) by the Reporting MTA. This is not necessarily the
- same as the value of the Date field from the header of the message
- used to transmit this delivery status notification: In cases where
- the DSN was generated by a gateway, the Date field in the message
- header contains the time the DSN was sent by the gateway and the DSN
- Last-Attempt-Date field contains the time the last delivery attempt
- occurred.
-
- last-attempt-date-field = "Last-Attempt-Date" ":" date-time
-
- This field is optional. It MUST NOT be included if the actual date
- and time of the last delivery attempt are not available (which might
- be the case if the DSN were being issued by a gateway).
-
- The date and time are expressed in RFC 822 'date-time' format, as
- modified by [8]. Numeric timezones ([+/-]HHMM format) MUST be used.
-
- 3.2.1.5 final-log-id field
-
- The "final-log-id" field gives the final-log-id of the message that
- was used by the final-mta. This can be useful as an index to the
- final-mta's log entry for that delivery attempt.
-
- final-log-id-field = "Final-Log-ID" ":" *text
-
- This field is optional.
-
-2.3.8 Will-Retry-Until field
-
- For DSNs of type "delayed", the Will-Retry-Until field gives the date
- after which the Reporting MTA expects to abandon all attempts to
- deliver the message to that recipient. The Will-Retry-Until field is
- optional for "delay" DSNs, and MUST NOT appear in other DSNs.
-
- will-retry-until-field = "Will-Retry-Until" ":" date-time
-
- The date and time are expressed in RFC 822 'date-time' format, as
- modified by [8]. Numeric timezones ([+/-]HHMM format) MUST be used.
-
-
-
-
-Moore & Vaudreuil Standards Track [Page 20]
-
-RFC 1894 Delivery Status Notifications January 1996
-
-
-2.4 Extension fields
-
- Additional per-message or per-recipient DSN fields may be defined in
- the future by later revisions or extensions to this specification.
- Extension-field names beginning with "X-" will never be defined as
- standard fields; such names are reserved for experimental use. DSN
- field names NOT beginning with "X-" MUST be registered with the
- Internet Assigned Numbers Authority (IANA) and published in an RFC.
-
- Extension DSN fields may be defined for the following reasons:
-
- (a) To allow additional information from foreign delivery status
- reports to be tunneled through Internet DSNs. The names of such
- DSN fields should begin with an indication of the foreign
- environment name (e.g. X400-Physical-Forwarding-Address).
-
- (b) To allow the transmission of diagnostic information which is
- specific to a particular mail transport protocol. The names of
- such DSN fields should begin with an indication of the mail
- transport being used (e.g. SMTP-Remote-Recipient-Address). Such
- fields should be used for diagnostic purposes only and not by
- user agents or mail gateways.
-
- (c) To allow transmission of diagnostic information which is specific
- to a particular message transfer agent (MTA). The names of such
- DSN fields should begin with an indication of the MTA
- implementation which produced the DSN. (e.g. Foomail-Queue-ID).
-
- MTA implementors are encouraged to provide adequate information, via
- extension fields if necessary, to allow an MTA maintainer to
- understand the nature of correctable delivery failures and how to fix
- them. For example, if message delivery attempts are logged, the DSN
- might include information which allows the MTA maintainer to easily
- find the log entry for a failed delivery attempt.
-
- If an MTA developer does not wish to register the meanings of such
- extension fields, "X-" fields may be used for this purpose. To avoid
- name collisions, the name of the MTA implementation should follow the
- "X-", (e.g. "X-Foomail-Log-ID").
-
-3. Conformance and Usage Requirements
-
- An MTA or gateway conforms to this specification if it generates DSNs
- according to the protocol defined in this memo. For MTAs and
- gateways that do not support requests for positive delivery
- notification (such as in [4]), it is sufficient that delivery failure
- reports use this protocol.
-
-
-
-
-Moore & Vaudreuil Standards Track [Page 21]
-
-RFC 1894 Delivery Status Notifications January 1996
-
-
- A minimal implementation of this specification need generate only the
- Reporting-MTA per-message field, and the Final-Recipient, Action, and
- Status fields for each attempt to deliver a message to a recipient
- described by the DSN. Generation of the other fields, when
- appropriate, is strongly recommended.
-
- MTAs and gateways MUST NOT generate the Original-Recipient field of a
- DSN unless the mail transfer protocol provides the address originally
- specified by the sender at the time of submission. (Ordinary SMTP
- does not make that guarantee, but the SMTP extension defined in [4]
- permits such information to be carried in the envelope if it is
- available.)
-
- Each sender-specified recipient address SHOULD result in at most one
- "delivered" or "failed" DSN for that recipient. If a positive DSN is
- requested (e.g. one using NOTIFY=SUCCESS in SMTP) for a recipient
- that is forwarded to multiple recipients of an "alias" (as defined in
- [4], section 7.2.7), the forwarding MTA SHOULD normally issue a
- "expanded" DSN for the originally-specified recipient and not
- propagate the request for a DSN to the forwarding addresses.
- Alternatively, the forwarding MTA MAY relay the request for a DSN to
- exactly one of the forwarding addresses and not propagate the request
- to the others.
-
- By contrast, successful submission of a message to a mailing list
- exploder is considered final delivery of the message. Upon delivery
- of a message to a recipient address corresponding to a mailing list
- exploder, the Reporting MTA SHOULD issue an appropriate DSN exactly
- as if the recipient address were that of an ordinary mailbox.
-
- NOTE: This is actually intended to make DSNs usable by mailing lists
- themselves. Any message sent to a mailing list subscriber should
- have its envelope return address pointing to the list maintainer [see
- RFC 1123, section 5.3.7(E)]. Since DSNs are sent to the envelope
- return address, all DSNs resulting from delivery to the recipients of
- a mailing list will be sent to the list maintainer. The list
- maintainer may elect to mechanically process DSNs upon receipt, and
- thus automatically delete invalid addresses from the list. (See
- section 7 of this memo.)
-
- This specification places no restrictions on the processing of DSNs
- received by user agents or distribution lists.
-
-4. Security Considerations
-
- The following security considerations apply when using DSNs:
-
-
-
-
-
-Moore & Vaudreuil Standards Track [Page 22]
-
-RFC 1894 Delivery Status Notifications January 1996
-
-
-4.1 Forgery
-
- DSNs may be forged as easily as ordinary Internet electronic mail.
- User agents and automatic mail handling facilities (such as mail
- distribution list exploders) that wish to make automatic use of DSNs
- should take appropriate precautions to minimize the potential damage
- from denial-of-service attacks.
-
- Security threats related to forged DSNs include the sending of:
-
-(a) A falsified delivery notification when the message is not delivered
- to the indicated recipient,
-(b) A falsified non-delivery notification when the message was in fact
- delivered to the indicated recipient,
-(c) A falsified Final-Recipient address,
-(d) A falsified Remote-MTA identification,
-(e) A falsified relay notification when the message is "dead ended".
-(f) Unsolicited DSNs
-
-4.2 Confidentiality
-
- Another dimension of security is confidentiality. There may be cases
- in which a message recipient is autoforwarding messages but does not
- wish to divulge the address to which the messages are autoforwarded.
- The desire for such confidentiality will probably be heightened as
- "wireless mailboxes", such as pagers, become more widely used as
- autoforward addresses.
-
- MTA authors are encouraged to provide a mechanism which enables the
- end user to preserve the confidentiality of a forwarding address.
- Depending on the degree of confidentiality required, and the nature
- of the environment to which a message were being forwarded, this
- might be accomplished by one or more of:
-
-(a) issuing a "relayed" DSN (if a positive DSN was requested) when a
- message is forwarded to a confidential forwarding address, and
- disabling requests for positive DSNs for the forwarded message,
-
-(b) declaring the message to be delivered, issuing a "delivered" DSN,
- re-sending the message to the confidential forwarding address, and
- arranging for no DSNs to be issued for the re-sent message,
-
-(c) omitting "Remote-*" or extension fields of a DSN whenever they would
- otherwise contain confidential information (such as a confidential
- forwarding address),
-
-(d) for messages forwarded to a confidential address, setting the
- envelope return address (e.g. SMTP MAIL FROM address) to the NULL
-
-
-
-Moore & Vaudreuil Standards Track [Page 23]
-
-RFC 1894 Delivery Status Notifications January 1996
-
-
- reverse-path ("<>") (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 <[email protected]>.
-
-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 <[email protected]>
- Message-Id: <[email protected]>
- Subject: Returned mail: Cannot send message for 5 days
- To: <[email protected]>
- 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 -----
- <[email protected]> (unrecoverable error)
-
- ----- Transcript of session follows -----
- <[email protected]>... 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;[email protected]
- Final-Recipient: rfc822;[email protected]
- 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 <[email protected]>
- Subject: Returned mail: User unknown
- To: <[email protected]>
- 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 -----
- <[email protected]> (unrecoverable error)
- <[email protected]> (unrecoverable error)
-
- --JAA13167.773673707/CS.UTK.EDU
- content-type: message/delivery-status
-
- Reporting-MTA: dns; cs.utk.edu
-
- Original-Recipient: rfc822;[email protected]
- Final-Recipient: rfc822;[email protected]
- Action: failed
- Status: 5.0.0 (permanent failure)
- Diagnostic-Code: smtp;
- 550 '[email protected]' is not a registered gateway user
- Remote-MTA: dns; vnet.ibm.com
-
- Original-Recipient: rfc822;[email protected]
- Final-Recipient: rfc822;[email protected]
- Action: delayed
- Status: 4.0.0 (hpnjld.njd.jp.com: host name lookup failure)
-
- Original-Recipient: rfc822;[email protected]
- Final-Recipient: rfc822;[email protected]
- 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 <[email protected]>
- Subject: Status of : Re: Battery current sense
- To: [email protected]
- Message-id: <[email protected]>
- 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: <[email protected]>
- Message-Id: <[email protected]>
- Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
- id <[email protected]>;
- Sun, 10 Jul 1994 00:36:51 +0100
- To: [email protected]
- 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:
-
- [email protected]
-
- 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;[email protected]
- 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: [email protected]
- 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: [email protected]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Moore & Vaudreuil Standards Track [Page 39]
-
diff --git a/doc/rfc/rfc1939.txt b/doc/rfc/rfc1939.txt
deleted file mode 100644
index b11350e..0000000
--- a/doc/rfc/rfc1939.txt
+++ /dev/null
@@ -1,1291 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Myers
-Request for Comments: 1939 Carnegie Mellon
-STD: 53 M. Rose
-Obsoletes: 1725 Dover Beach Consulting, Inc.
-Category: Standards Track May 1996
-
-
- Post Office Protocol - Version 3
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Table of Contents
-
- 1. Introduction ................................................ 2
- 2. A Short Digression .......................................... 2
- 3. Basic Operation ............................................. 3
- 4. The AUTHORIZATION State ..................................... 4
- QUIT Command ................................................ 5
- 5. The TRANSACTION State ....................................... 5
- STAT Command ................................................ 6
- LIST Command ................................................ 6
- RETR Command ................................................ 8
- DELE Command ................................................ 8
- NOOP Command ................................................ 9
- RSET Command ................................................ 9
- 6. The UPDATE State ............................................ 10
- QUIT Command ................................................ 10
- 7. Optional POP3 Commands ...................................... 11
- TOP Command ................................................. 11
- UIDL Command ................................................ 12
- USER Command ................................................ 13
- PASS Command ................................................ 14
- APOP Command ................................................ 15
- 8. Scaling and Operational Considerations ...................... 16
- 9. POP3 Command Summary ........................................ 18
- 10. Example POP3 Session ....................................... 19
- 11. Message Format ............................................. 19
- 12. References ................................................. 20
- 13. Security Considerations .................................... 20
- 14. Acknowledgements ........................................... 20
- 15. Authors' Addresses ......................................... 21
- Appendix A. Differences from RFC 1725 .......................... 22
-
-
-
-Myers & Rose Standards Track [Page 1]
-
-RFC 1939 POP3 May 1996
-
-
- Appendix B. Command Index ...................................... 23
-
-1. Introduction
-
- On certain types of smaller nodes in the Internet it is often
- impractical to maintain a message transport system (MTS). For
- example, a workstation may not have sufficient resources (cycles,
- disk space) in order to permit a SMTP server [RFC821] and associated
- local mail delivery system to be kept resident and continuously
- running. Similarly, it may be expensive (or impossible) to keep a
- personal computer interconnected to an IP-style network for long
- amounts of time (the node is lacking the resource known as
- "connectivity").
-
- Despite this, it is often very useful to be able to manage mail on
- these smaller nodes, and they often support a user agent (UA) to aid
- the tasks of mail handling. To solve this problem, a node which can
- support an MTS entity offers a maildrop service to these less endowed
- nodes. The Post Office Protocol - Version 3 (POP3) is intended to
- permit a workstation to dynamically access a maildrop on a server
- host in a useful fashion. Usually, this means that the POP3 protocol
- is used to allow a workstation to retrieve mail that the server is
- holding for it.
-
- POP3 is not intended to provide extensive manipulation operations of
- mail on the server; normally, mail is downloaded and then deleted. A
- more advanced (and complex) protocol, IMAP4, is discussed in
- [RFC1730].
-
- For the remainder of this memo, the term "client host" refers to a
- host making use of the POP3 service, while the term "server host"
- refers to a host which offers the POP3 service.
-
-2. A Short Digression
-
- This memo does not specify how a client host enters mail into the
- transport system, although a method consistent with the philosophy of
- this memo is presented here:
-
- When the user agent on a client host wishes to enter a message
- into the transport system, it establishes an SMTP connection to
- its relay host and sends all mail to it. This relay host could
- be, but need not be, the POP3 server host for the client host. Of
- course, the relay host must accept mail for delivery to arbitrary
- recipient addresses, that functionality is not required of all
- SMTP servers.
-
-
-
-
-
-Myers & Rose Standards Track [Page 2]
-
-RFC 1939 POP3 May 1996
-
-
-3. Basic Operation
-
- Initially, the server host starts the POP3 service by listening on
- TCP port 110. When a client host wishes to make use of the service,
- it establishes a TCP connection with the server host. When the
- connection is established, the POP3 server sends a greeting. The
- client and POP3 server then exchange commands and responses
- (respectively) until the connection is closed or aborted.
-
- Commands in the POP3 consist of a case-insensitive keyword, possibly
- followed by one or more arguments. All commands are terminated by a
- CRLF pair. Keywords and arguments consist of printable ASCII
- characters. Keywords and arguments are each separated by a single
- SPACE character. Keywords are three or four characters long. Each
- argument may be up to 40 characters long.
-
- Responses in the POP3 consist of a status indicator and a keyword
- possibly followed by additional information. All responses are
- terminated by a CRLF pair. Responses may be up to 512 characters
- long, including the terminating CRLF. There are currently two status
- indicators: positive ("+OK") and negative ("-ERR"). Servers MUST
- send the "+OK" and "-ERR" in upper case.
-
- Responses to certain commands are multi-line. In these cases, which
- are clearly indicated below, after sending the first line of the
- response and a CRLF, any additional lines are sent, each terminated
- by a CRLF pair. When all lines of the response have been sent, a
- final line is sent, consisting of a termination octet (decimal code
- 046, ".") and a CRLF pair. If any line of the multi-line response
- begins with the termination octet, the line is "byte-stuffed" by
- pre-pending the termination octet to that line of the response.
- Hence a multi-line response is terminated with the five octets
- "CRLF.CRLF". When examining a multi-line response, the client checks
- to see if the line begins with the termination octet. If so and if
- octets other than CRLF follow, the first octet of the line (the
- termination octet) is stripped away. If so and if CRLF immediately
- follows the termination character, then the response from the POP
- server is ended and the line containing ".CRLF" is not considered
- part of the multi-line response.
-
- A POP3 session progresses through a number of states during its
- lifetime. Once the TCP connection has been opened and the POP3
- server has sent the greeting, the session enters the AUTHORIZATION
- state. In this state, the client must identify itself to the POP3
- server. Once the client has successfully done this, the server
- acquires resources associated with the client's maildrop, and the
- session enters the TRANSACTION state. In this state, the client
- requests actions on the part of the POP3 server. When the client has
-
-
-
-Myers & Rose Standards Track [Page 3]
-
-RFC 1939 POP3 May 1996
-
-
- issued the QUIT command, the session enters the UPDATE state. In
- this state, the POP3 server releases any resources acquired during
- the TRANSACTION state and says goodbye. The TCP connection is then
- closed.
-
- A server MUST respond to an unrecognized, unimplemented, or
- syntactically invalid command by responding with a negative status
- indicator. A server MUST respond to a command issued when the
- session is in an incorrect state by responding with a negative status
- indicator. There is no general method for a client to distinguish
- between a server which does not implement an optional command and a
- server which is unwilling or unable to process the command.
-
- A POP3 server MAY have an inactivity autologout timer. Such a timer
- MUST be of at least 10 minutes' duration. The receipt of any command
- from the client during that interval should suffice to reset the
- autologout timer. When the timer expires, the session does NOT enter
- the UPDATE state--the server should close the TCP connection without
- removing any messages or sending any response to the client.
-
-4. The AUTHORIZATION State
-
- Once the TCP connection has been opened by a POP3 client, the POP3
- server issues a one line greeting. This can be any positive
- response. An example might be:
-
- S: +OK POP3 server ready
-
- The POP3 session is now in the AUTHORIZATION state. The client must
- now identify and authenticate itself to the POP3 server. Two
- possible mechanisms for doing this are described in this document,
- the USER and PASS command combination and the APOP command. Both
- mechanisms are described later in this document. Additional
- authentication mechanisms are described in [RFC1734]. While there is
- no single authentication mechanism that is required of all POP3
- servers, a POP3 server must of course support at least one
- authentication mechanism.
-
- Once the POP3 server has determined through the use of any
- authentication command that the client should be given access to the
- appropriate maildrop, the POP3 server then acquires an exclusive-
- access lock on the maildrop, as necessary to prevent messages from
- being modified or removed before the session enters the UPDATE state.
- If the lock is successfully acquired, the POP3 server responds with a
- positive status indicator. The POP3 session now enters the
- TRANSACTION state, with no messages marked as deleted. If the
- maildrop cannot be opened for some reason (for example, a lock can
- not be acquired, the client is denied access to the appropriate
-
-
-
-Myers & Rose Standards Track [Page 4]
-
-RFC 1939 POP3 May 1996
-
-
- maildrop, or the maildrop cannot be parsed), the POP3 server responds
- with a negative status indicator. (If a lock was acquired but the
- POP3 server intends to respond with a negative status indicator, the
- POP3 server must release the lock prior to rejecting the command.)
- After returning a negative status indicator, the server may close the
- connection. If the server does not close the connection, the client
- may either issue a new authentication command and start again, or the
- client may issue the QUIT command.
-
- After the POP3 server has opened the maildrop, it assigns a message-
- number to each message, and notes the size of each message in octets.
- The first message in the maildrop is assigned a message-number of
- "1", the second is assigned "2", and so on, so that the nth message
- in a maildrop is assigned a message-number of "n". In POP3 commands
- and responses, all message-numbers and message sizes are expressed in
- base-10 (i.e., decimal).
-
- Here is the summary for the QUIT command when used in the
- AUTHORIZATION state:
-
- QUIT
-
- Arguments: none
-
- Restrictions: none
-
- Possible Responses:
- +OK
-
- Examples:
- C: QUIT
- S: +OK dewey POP3 server signing off
-
-5. The TRANSACTION State
-
- Once the client has successfully identified itself to the POP3 server
- and the POP3 server has locked and opened the appropriate maildrop,
- the POP3 session is now in the TRANSACTION state. The client may now
- issue any of the following POP3 commands repeatedly. After each
- command, the POP3 server issues a response. Eventually, the client
- issues the QUIT command and the POP3 session enters the UPDATE state.
-
-
-
-
-
-
-
-
-
-
-Myers & Rose Standards Track [Page 5]
-
-RFC 1939 POP3 May 1996
-
-
- Here are the POP3 commands valid in the TRANSACTION state:
-
- STAT
-
- Arguments: none
-
- Restrictions:
- may only be given in the TRANSACTION state
-
- Discussion:
- The POP3 server issues a positive response with a line
- containing information for the maildrop. This line is
- called a "drop listing" for that maildrop.
-
- In order to simplify parsing, all POP3 servers are
- required to use a certain format for drop listings. The
- positive response consists of "+OK" followed by a single
- space, the number of messages in the maildrop, a single
- space, and the size of the maildrop in octets. This memo
- makes no requirement on what follows the maildrop size.
- Minimal implementations should just end that line of the
- response with a CRLF pair. More advanced implementations
- may include other information.
-
- NOTE: This memo STRONGLY discourages implementations
- from supplying additional information in the drop
- listing. Other, optional, facilities are discussed
- later on which permit the client to parse the messages
- in the maildrop.
-
- Note that messages marked as deleted are not counted in
- either total.
-
- Possible Responses:
- +OK nn mm
-
- Examples:
- C: STAT
- S: +OK 2 320
-
-
- LIST [msg]
-
- Arguments:
- a message-number (optional), which, if present, may NOT
- refer to a message marked as deleted
-
-
-
-
-
-Myers & Rose Standards Track [Page 6]
-
-RFC 1939 POP3 May 1996
-
-
- Restrictions:
- may only be given in the TRANSACTION state
-
- Discussion:
- If an argument was given and the POP3 server issues a
- positive response with a line containing information for
- that message. This line is called a "scan listing" for
- that message.
-
- If no argument was given and the POP3 server issues a
- positive response, then the response given is multi-line.
- After the initial +OK, for each message in the maildrop,
- the POP3 server responds with a line containing
- information for that message. This line is also called a
- "scan listing" for that message. If there are no
- messages in the maildrop, then the POP3 server responds
- with no scan listings--it issues a positive response
- followed by a line containing a termination octet and a
- CRLF pair.
-
- In order to simplify parsing, all POP3 servers are
- required to use a certain format for scan listings. A
- scan listing consists of the message-number of the
- message, followed by a single space and the exact size of
- the message in octets. Methods for calculating the exact
- size of the message are described in the "Message Format"
- section below. This memo makes no requirement on what
- follows the message size in the scan listing. Minimal
- implementations should just end that line of the response
- with a CRLF pair. More advanced implementations may
- include other information, as parsed from the message.
-
- NOTE: This memo STRONGLY discourages implementations
- from supplying additional information in the scan
- listing. Other, optional, facilities are discussed
- later on which permit the client to parse the messages
- in the maildrop.
-
- Note that messages marked as deleted are not listed.
-
- Possible Responses:
- +OK scan listing follows
- -ERR no such message
-
- Examples:
- C: LIST
- S: +OK 2 messages (320 octets)
- S: 1 120
-
-
-
-Myers & Rose Standards Track [Page 7]
-
-RFC 1939 POP3 May 1996
-
-
- S: 2 200
- S: .
- ...
- C: LIST 2
- S: +OK 2 200
- ...
- C: LIST 3
- S: -ERR no such message, only 2 messages in maildrop
-
-
- RETR msg
-
- Arguments:
- a message-number (required) which may NOT refer to a
- message marked as deleted
-
- Restrictions:
- may only be given in the TRANSACTION state
-
- Discussion:
- If the POP3 server issues a positive response, then the
- response given is multi-line. After the initial +OK, the
- POP3 server sends the message corresponding to the given
- message-number, being careful to byte-stuff the termination
- character (as with all multi-line responses).
-
- Possible Responses:
- +OK message follows
- -ERR no such message
-
- Examples:
- C: RETR 1
- S: +OK 120 octets
- S: <the POP3 server sends the entire message here>
- S: .
-
-
- DELE msg
-
- Arguments:
- a message-number (required) which may NOT refer to a
- message marked as deleted
-
- Restrictions:
- may only be given in the TRANSACTION state
-
-
-
-
-
-
-Myers & Rose Standards Track [Page 8]
-
-RFC 1939 POP3 May 1996
-
-
- Discussion:
- The POP3 server marks the message as deleted. Any future
- reference to the message-number associated with the message
- in a POP3 command generates an error. The POP3 server does
- not actually delete the message until the POP3 session
- enters the UPDATE state.
-
- Possible Responses:
- +OK message deleted
- -ERR no such message
-
- Examples:
- C: DELE 1
- S: +OK message 1 deleted
- ...
- C: DELE 2
- S: -ERR message 2 already deleted
-
-
- NOOP
-
- Arguments: none
-
- Restrictions:
- may only be given in the TRANSACTION state
-
- Discussion:
- The POP3 server does nothing, it merely replies with a
- positive response.
-
- Possible Responses:
- +OK
-
- Examples:
- C: NOOP
- S: +OK
-
-
- RSET
-
- Arguments: none
-
- Restrictions:
- may only be given in the TRANSACTION state
-
- Discussion:
- If any messages have been marked as deleted by the POP3
- server, they are unmarked. The POP3 server then replies
-
-
-
-Myers & Rose Standards Track [Page 9]
-
-RFC 1939 POP3 May 1996
-
-
- with a positive response.
-
- Possible Responses:
- +OK
-
- Examples:
- C: RSET
- S: +OK maildrop has 2 messages (320 octets)
-
-6. The UPDATE State
-
- When the client issues the QUIT command from the TRANSACTION state,
- the POP3 session enters the UPDATE state. (Note that if the client
- issues the QUIT command from the AUTHORIZATION state, the POP3
- session terminates but does NOT enter the UPDATE state.)
-
- If a session terminates for some reason other than a client-issued
- QUIT command, the POP3 session does NOT enter the UPDATE state and
- MUST not remove any messages from the maildrop.
-
- QUIT
-
- Arguments: none
-
- Restrictions: none
-
- Discussion:
- The POP3 server removes all messages marked as deleted
- from the maildrop and replies as to the status of this
- operation. If there is an error, such as a resource
- shortage, encountered while removing messages, the
- maildrop may result in having some or none of the messages
- marked as deleted be removed. In no case may the server
- remove any messages not marked as deleted.
-
- Whether the removal was successful or not, the server
- then releases any exclusive-access lock on the maildrop
- and closes the TCP connection.
-
- Possible Responses:
- +OK
- -ERR some deleted messages not removed
-
- Examples:
- C: QUIT
- S: +OK dewey POP3 server signing off (maildrop empty)
- ...
- C: QUIT
-
-
-
-Myers & Rose Standards Track [Page 10]
-
-RFC 1939 POP3 May 1996
-
-
- S: +OK dewey POP3 server signing off (2 messages left)
- ...
-
-7. Optional POP3 Commands
-
- The POP3 commands discussed above must be supported by all minimal
- implementations of POP3 servers.
-
- The optional POP3 commands described below permit a POP3 client
- greater freedom in message handling, while preserving a simple POP3
- server implementation.
-
- NOTE: This memo STRONGLY encourages implementations to support
- these commands in lieu of developing augmented drop and scan
- listings. In short, the philosophy of this memo is to put
- intelligence in the part of the POP3 client and not the POP3
- server.
-
- TOP msg n
-
- Arguments:
- a message-number (required) which may NOT refer to to a
- message marked as deleted, and a non-negative number
- of lines (required)
-
- Restrictions:
- may only be given in the TRANSACTION state
-
- Discussion:
- If the POP3 server issues a positive response, then the
- response given is multi-line. After the initial +OK, the
- POP3 server sends the headers of the message, the blank
- line separating the headers from the body, and then the
- number of lines of the indicated message's body, being
- careful to byte-stuff the termination character (as with
- all multi-line responses).
-
- Note that if the number of lines requested by the POP3
- client is greater than than the number of lines in the
- body, then the POP3 server sends the entire message.
-
- Possible Responses:
- +OK top of message follows
- -ERR no such message
-
- Examples:
- C: TOP 1 10
- S: +OK
-
-
-
-Myers & Rose Standards Track [Page 11]
-
-RFC 1939 POP3 May 1996
-
-
- S: <the POP3 server sends the headers of the
- message, a blank line, and the first 10 lines
- of the body of the message>
- S: .
- ...
- C: TOP 100 3
- S: -ERR no such message
-
-
- UIDL [msg]
-
- Arguments:
- a message-number (optional), which, if present, may NOT
- refer to a message marked as deleted
-
- Restrictions:
- may only be given in the TRANSACTION state.
-
- Discussion:
- If an argument was given and the POP3 server issues a positive
- response with a line containing information for that message.
- This line is called a "unique-id listing" for that message.
-
- If no argument was given and the POP3 server issues a positive
- response, then the response given is multi-line. After the
- initial +OK, for each message in the maildrop, the POP3 server
- responds with a line containing information for that message.
- This line is called a "unique-id listing" for that message.
-
- In order to simplify parsing, all POP3 servers are required to
- use a certain format for unique-id listings. A unique-id
- listing consists of the message-number of the message,
- followed by a single space and the unique-id of the message.
- No information follows the unique-id in the unique-id listing.
-
- The unique-id of a message is an arbitrary server-determined
- string, consisting of one to 70 characters in the range 0x21
- to 0x7E, which uniquely identifies a message within a
- maildrop and which persists across sessions. This
- persistence is required even if a session ends without
- entering the UPDATE state. The server should never reuse an
- unique-id in a given maildrop, for as long as the entity
- using the unique-id exists.
-
- Note that messages marked as deleted are not listed.
-
- While it is generally preferable for server implementations
- to store arbitrarily assigned unique-ids in the maildrop,
-
-
-
-Myers & Rose Standards Track [Page 12]
-
-RFC 1939 POP3 May 1996
-
-
- this specification is intended to permit unique-ids to be
- calculated as a hash of the message. Clients should be able
- to handle a situation where two identical copies of a
- message in a maildrop have the same unique-id.
-
- Possible Responses:
- +OK unique-id listing follows
- -ERR no such message
-
- Examples:
- C: UIDL
- S: +OK
- S: 1 whqtswO00WBw418f9t5JxYwZ
- S: 2 QhdPYR:00WBw1Ph7x7
- S: .
- ...
- C: UIDL 2
- S: +OK 2 QhdPYR:00WBw1Ph7x7
- ...
- C: UIDL 3
- S: -ERR no such message, only 2 messages in maildrop
-
-
- USER name
-
- Arguments:
- a string identifying a mailbox (required), which is of
- significance ONLY to the server
-
- Restrictions:
- may only be given in the AUTHORIZATION state after the POP3
- greeting or after an unsuccessful USER or PASS command
-
- Discussion:
- To authenticate using the USER and PASS command
- combination, the client must first issue the USER
- command. If the POP3 server responds with a positive
- status indicator ("+OK"), then the client may issue
- either the PASS command to complete the authentication,
- or the QUIT command to terminate the POP3 session. If
- the POP3 server responds with a negative status indicator
- ("-ERR") to the USER command, then the client may either
- issue a new authentication command or may issue the QUIT
- command.
-
- The server may return a positive response even though no
- such mailbox exists. The server may return a negative
- response if mailbox exists, but does not permit plaintext
-
-
-
-Myers & Rose Standards Track [Page 13]
-
-RFC 1939 POP3 May 1996
-
-
- password authentication.
-
- Possible Responses:
- +OK name is a valid mailbox
- -ERR never heard of mailbox name
-
- Examples:
- C: USER frated
- S: -ERR sorry, no mailbox for frated here
- ...
- C: USER mrose
- S: +OK mrose is a real hoopy frood
-
-
- PASS string
-
- Arguments:
- a server/mailbox-specific password (required)
-
- Restrictions:
- may only be given in the AUTHORIZATION state immediately
- after a successful USER command
-
- Discussion:
- When the client issues the PASS command, the POP3 server
- uses the argument pair from the USER and PASS commands to
- determine if the client should be given access to the
- appropriate maildrop.
-
- Since the PASS command has exactly one argument, a POP3
- server may treat spaces in the argument as part of the
- password, instead of as argument separators.
-
- Possible Responses:
- +OK maildrop locked and ready
- -ERR invalid password
- -ERR unable to lock maildrop
-
- Examples:
- C: USER mrose
- S: +OK mrose is a real hoopy frood
- C: PASS secret
- S: -ERR maildrop already locked
- ...
- C: USER mrose
- S: +OK mrose is a real hoopy frood
- C: PASS secret
- S: +OK mrose's maildrop has 2 messages (320 octets)
-
-
-
-Myers & Rose Standards Track [Page 14]
-
-RFC 1939 POP3 May 1996
-
-
- APOP name digest
-
- Arguments:
- a string identifying a mailbox and a MD5 digest string
- (both required)
-
- Restrictions:
- may only be given in the AUTHORIZATION state after the POP3
- greeting or after an unsuccessful USER or PASS command
-
- Discussion:
- Normally, each POP3 session starts with a USER/PASS
- exchange. This results in a server/user-id specific
- password being sent in the clear on the network. For
- intermittent use of POP3, this may not introduce a sizable
- risk. However, many POP3 client implementations connect to
- the POP3 server on a regular basis -- to check for new
- mail. Further the interval of session initiation may be on
- the order of five minutes. Hence, the risk of password
- capture is greatly enhanced.
-
- An alternate method of authentication is required which
- provides for both origin authentication and replay
- protection, but which does not involve sending a password
- in the clear over the network. The APOP command provides
- this functionality.
-
- A POP3 server which implements the APOP command will
- include a timestamp in its banner greeting. The syntax of
- the timestamp corresponds to the `msg-id' in [RFC822], and
- MUST be different each time the POP3 server issues a banner
- greeting. For example, on a UNIX implementation in which a
- separate UNIX process is used for each instance of a POP3
- server, the syntax of the timestamp might be:
-
- <process-ID.clock@hostname>
-
- where `process-ID' is the decimal value of the process's
- PID, clock is the decimal value of the system clock, and
- hostname is the fully-qualified domain-name corresponding
- to the host where the POP3 server is running.
-
- The POP3 client makes note of this timestamp, and then
- issues the APOP command. The `name' parameter has
- identical semantics to the `name' parameter of the USER
- command. The `digest' parameter is calculated by applying
- the MD5 algorithm [RFC1321] to a string consisting of the
- timestamp (including angle-brackets) followed by a shared
-
-
-
-Myers & Rose Standards Track [Page 15]
-
-RFC 1939 POP3 May 1996
-
-
- secret. This shared secret is a string known only to the
- POP3 client and server. Great care should be taken to
- prevent unauthorized disclosure of the secret, as knowledge
- of the secret will allow any entity to successfully
- masquerade as the named user. The `digest' parameter
- itself is a 16-octet value which is sent in hexadecimal
- format, using lower-case ASCII characters.
-
- When the POP3 server receives the APOP command, it verifies
- the digest provided. If the digest is correct, the POP3
- server issues a positive response, and the POP3 session
- enters the TRANSACTION state. Otherwise, a negative
- response is issued and the POP3 session remains in the
- AUTHORIZATION state.
-
- Note that as the length of the shared secret increases, so
- does the difficulty of deriving it. As such, shared
- secrets should be long strings (considerably longer than
- the 8-character example shown below).
-
- Possible Responses:
- +OK maildrop locked and ready
- -ERR permission denied
-
- Examples:
- S: +OK POP3 server ready <[email protected]>
- 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
-
- <[email protected]>tanstaaf
-
- which produces a digest value of
-
- c4c9334bac560ecc979e58001b3e22fb
-
-8. Scaling and Operational Considerations
-
- Since some of the optional features described above were added to the
- POP3 protocol, experience has accumulated in using them in large-
- scale commercial post office operations where most of the users are
- unrelated to each other. In these situations and others, users and
- vendors of POP3 clients have discovered that the combination of using
- the UIDL command and not issuing the DELE command can provide a weak
- version of the "maildrop as semi-permanent repository" functionality
- normally associated with IMAP. Of course the other capabilities of
-
-
-
-Myers & Rose Standards Track [Page 16]
-
-RFC 1939 POP3 May 1996
-
-
- IMAP, such as polling an existing connection for newly arrived
- messages and supporting multiple folders on the server, are not
- present in POP3.
-
- When these facilities are used in this way by casual users, there has
- been a tendency for already-read messages to accumulate on the server
- without bound. This is clearly an undesirable behavior pattern from
- the standpoint of the server operator. This situation is aggravated
- by the fact that the limited capabilities of the POP3 do not permit
- efficient handling of maildrops which have hundreds or thousands of
- messages.
-
- Consequently, it is recommended that operators of large-scale multi-
- user servers, especially ones in which the user's only access to the
- maildrop is via POP3, consider such options as:
-
- * Imposing a per-user maildrop storage quota or the like.
-
- A disadvantage to this option is that accumulation of messages may
- result in the user's inability to receive new ones into the
- maildrop. Sites which choose this option should be sure to inform
- users of impending or current exhaustion of quota, perhaps by
- inserting an appropriate message into the user's maildrop.
-
- * Enforce a site policy regarding mail retention on the server.
-
- Sites are free to establish local policy regarding the storage and
- retention of messages on the server, both read and unread. For
- example, a site might delete unread messages from the server after
- 60 days and delete read messages after 7 days. Such message
- deletions are outside the scope of the POP3 protocol and are not
- considered a protocol violation.
-
- Server operators enforcing message deletion policies should take
- care to make all users aware of the policies in force.
-
- Clients must not assume that a site policy will automate message
- deletions, and should continue to explicitly delete messages using
- the DELE command when appropriate.
-
- It should be noted that enforcing site message deletion policies
- may be confusing to the user community, since their POP3 client
- may contain configuration options to leave mail on the server
- which will not in fact be supported by the server.
-
- One special case of a site policy is that messages may only be
- downloaded once from the server, and are deleted after this has
- been accomplished. This could be implemented in POP3 server
-
-
-
-Myers & Rose Standards Track [Page 17]
-
-RFC 1939 POP3 May 1996
-
-
- software by the following mechanism: "following a POP3 login by a
- client which was ended by a QUIT, delete all messages downloaded
- during the session with the RETR command". It is important not to
- delete messages in the event of abnormal connection termination
- (ie, if no QUIT was received from the client) because the client
- may not have successfully received or stored the messages.
- Servers implementing a download-and-delete policy may also wish to
- disable or limit the optional TOP command, since it could be used
- as an alternate mechanism to download entire messages.
-
-9. POP3 Command Summary
-
- Minimal POP3 Commands:
-
- USER name valid in the AUTHORIZATION state
- PASS string
- QUIT
-
- STAT valid in the TRANSACTION state
- LIST [msg]
- RETR msg
- DELE msg
- NOOP
- RSET
- QUIT
-
- Optional POP3 Commands:
-
- APOP name digest valid in the AUTHORIZATION state
-
- TOP msg n valid in the TRANSACTION state
- UIDL [msg]
-
- POP3 Replies:
-
- +OK
- -ERR
-
- Note that with the exception of the STAT, LIST, and UIDL commands,
- the reply given by the POP3 server to any command is significant
- only to "+OK" and "-ERR". Any text occurring after this reply
- may be ignored by the client.
-
-
-
-
-
-
-
-
-
-Myers & Rose Standards Track [Page 18]
-
-RFC 1939 POP3 May 1996
-
-
-10. Example POP3 Session
-
- S: <wait for connection on TCP port 110>
- C: <open connection>
- S: +OK POP3 server ready <[email protected]>
- C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
- S: +OK mrose's maildrop has 2 messages (320 octets)
- C: STAT
- S: +OK 2 320
- C: LIST
- S: +OK 2 messages (320 octets)
- S: 1 120
- S: 2 200
- S: .
- C: RETR 1
- S: +OK 120 octets
- S: <the POP3 server sends message 1>
- S: .
- C: DELE 1
- S: +OK message 1 deleted
- C: RETR 2
- S: +OK 200 octets
- S: <the POP3 server sends message 2>
- S: .
- C: DELE 2
- S: +OK message 2 deleted
- C: QUIT
- S: +OK dewey POP3 server signing off (maildrop empty)
- C: <close connection>
- S: <wait for next connection>
-
-11. Message Format
-
- All messages transmitted during a POP3 session are assumed to conform
- to the standard for the format of Internet text messages [RFC822].
-
- It is important to note that the octet count for a message on the
- server host may differ from the octet count assigned to that message
- due to local conventions for designating end-of-line. Usually,
- during the AUTHORIZATION state of the POP3 session, the POP3 server
- can calculate the size of each message in octets when it opens the
- maildrop. For example, if the POP3 server host internally represents
- end-of-line as a single character, then the POP3 server simply counts
- each occurrence of this character in a message as two octets. Note
- that lines in the message which start with the termination octet need
- not (and must not) be counted twice, since the POP3 client will
- remove all byte-stuffed termination characters when it receives a
- multi-line response.
-
-
-
-Myers & Rose Standards Track [Page 19]
-
-RFC 1939 POP3 May 1996
-
-
-12. References
-
- [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
- 821, USC/Information Sciences Institute, August 1982.
-
- [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text
- Messages", STD 11, RFC 822, University of Delaware, August 1982.
-
- [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
- MIT Laboratory for Computer Science, April 1992.
-
- [RFC1730] Crispin, M., "Internet Message Access Protocol - Version
- 4", RFC 1730, University of Washington, December 1994.
-
- [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,
- Carnegie Mellon, December 1994.
-
-13. Security Considerations
-
- It is conjectured that use of the APOP command provides origin
- identification and replay protection for a POP3 session.
- Accordingly, a POP3 server which implements both the PASS and APOP
- commands should not allow both methods of access for a given user;
- that is, for a given mailbox name, either the USER/PASS command
- sequence or the APOP command is allowed, but not both.
-
- Further, note that as the length of the shared secret increases, so
- does the difficulty of deriving it.
-
- Servers that answer -ERR to the USER command are giving potential
- attackers clues about which names are valid.
-
- Use of the PASS command sends passwords in the clear over the
- network.
-
- Use of the RETR and TOP commands sends mail in the clear over the
- network.
-
- Otherwise, security issues are not discussed in this memo.
-
-14. Acknowledgements
-
- The POP family has a long and checkered history. Although primarily
- a minor revision to RFC 1460, POP3 is based on the ideas presented in
- RFCs 918, 937, and 1081.
-
- In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff
- provided significant comments on the APOP command.
-
-
-
-Myers & Rose Standards Track [Page 20]
-
-RFC 1939 POP3 May 1996
-
-
-15. Authors' Addresses
-
- John G. Myers
- Carnegie-Mellon University
- 5000 Forbes Ave
- Pittsburgh, PA 15213
-
- EMail: [email protected]
-
-
- Marshall T. Rose
- Dover Beach Consulting, Inc.
- 420 Whisman Court
- Mountain View, CA 94043-2186
-
- EMail: [email protected]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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/doc/rfc/rfc1957.txt b/doc/rfc/rfc1957.txt
deleted file mode 100644
index 360330f..0000000
--- a/doc/rfc/rfc1957.txt
+++ /dev/null
@@ -1,115 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Nelson
-Request for Comments: 1957 Crynwr Software
-Updates: 1939 June 1996
-Category: Informational
-
-
- Some Observations on Implementations
- of the Post Office Protocol (POP3)
-
-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.
-
-Observations
-
- Sometimes an implementation is mistaken for a standard. POP3 servers
- and clients are no exception. The widely-used UCB POP3 server,
- popper, which has been further developed by Qualcomm, always has
- additional information following the status indicator. So, the
- status indicator always has a space following it. Two POP3 clients
- have been observed to expect that space, and fail when it has not
- been found. The RFC does not require the space, hence this memo.
- These clients are the freely copyable Unix "popclient" and the
- proprietary "netApp Systems Internet Series". The authors of both of
- these have been contacted, and new releases will not expect the
- space, but old versions should be supported.
-
- In addition, two popular clients require optional parts of the RFC.
- Netscape requires UIDL, and Eudora requires TOP.
-
- The optional APOP authentication command has not achieved wide
- penetration yet. Newer versions of the Qualcomm POP server implement
- it. Known client implementations of APOP include GNU Emacs VM client
- and Eudora Lite and Eudora Pro.
-
-Security Considerations
-
- Security issues are not discussed in this memo.
-
-References
-
- [1] Myers, J., and M. Rose, "Post Office Protocol - Version 3",
- STD 53, RFC 1939, May 1996.
-
-
-
-
-
-
-Nelson Informational [Page 1]
-
-RFC 1957 Notes on POP3 Implementations June 1996
-
-
-Author's Address
-
- Russell Nelson
- Crynwr Software
- 521 Pleasant Valley Rd.
- Potsdam, NY 13676
-
- Phone: +1.315.268.1925
- FAX: +1.315.268.9201
- EMail: [email protected]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nelson Informational [Page 2]
-
diff --git a/doc/rfc/rfc2045.txt b/doc/rfc/rfc2045.txt
deleted file mode 100644
index 9f286b1..0000000
--- a/doc/rfc/rfc2045.txt
+++ /dev/null
@@ -1,1739 +0,0 @@
-
-
-
-
-
-
-Network Working Group N. Freed
-Request for Comments: 2045 Innosoft
-Obsoletes: 1521, 1522, 1590 N. Borenstein
-Category: Standards Track First Virtual
- November 1996
-
-
- Multipurpose Internet Mail Extensions
- (MIME) Part One:
- Format of Internet Message Bodies
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- STD 11, RFC 822, defines a message representation protocol specifying
- considerable detail about US-ASCII message headers, and leaves the
- message content, or message body, as flat US-ASCII text. This set of
- documents, collectively called the Multipurpose Internet Mail
- Extensions, or MIME, redefines the format of messages to allow for
-
- (1) textual message bodies in character sets other than
- US-ASCII,
-
- (2) an extensible set of different formats for non-textual
- message bodies,
-
- (3) multi-part message bodies, and
-
- (4) textual header information in character sets other than
- US-ASCII.
-
- These documents are based on earlier work documented in RFC 934, STD
- 11, and RFC 1049, but extends and revises them. Because RFC 822 said
- so little about message bodies, these documents are largely
- orthogonal to (rather than a revision of) RFC 822.
-
- This initial document specifies the various headers used to describe
- the structure of MIME messages. The second document, RFC 2046,
- defines the general structure of the MIME media typing system and
- defines an initial set of media types. The third document, RFC 2047,
- describes extensions to RFC 822 to allow non-US-ASCII text data in
-
-
-
-Freed & Borenstein Standards Track [Page 1]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- Internet mail header fields. The fourth document, RFC 2048, specifies
- various IANA registration procedures for MIME-related facilities. The
- fifth and final document, RFC 2049, describes MIME conformance
- criteria as well as providing some illustrative examples of MIME
- message formats, acknowledgements, and the bibliography.
-
- These documents are revisions of RFCs 1521, 1522, and 1590, which
- themselves were revisions of RFCs 1341 and 1342. An appendix in RFC
- 2049 describes differences and changes from previous versions.
-
-Table of Contents
-
- 1. Introduction ......................................... 3
- 2. Definitions, Conventions, and Generic BNF Grammar .... 5
- 2.1 CRLF ................................................ 5
- 2.2 Character Set ....................................... 6
- 2.3 Message ............................................. 6
- 2.4 Entity .............................................. 6
- 2.5 Body Part ........................................... 7
- 2.6 Body ................................................ 7
- 2.7 7bit Data ........................................... 7
- 2.8 8bit Data ........................................... 7
- 2.9 Binary Data ......................................... 7
- 2.10 Lines .............................................. 7
- 3. MIME Header Fields ................................... 8
- 4. MIME-Version Header Field ............................ 8
- 5. Content-Type Header Field ............................ 10
- 5.1 Syntax of the Content-Type Header Field ............. 12
- 5.2 Content-Type Defaults ............................... 14
- 6. Content-Transfer-Encoding Header Field ............... 14
- 6.1 Content-Transfer-Encoding Syntax .................... 14
- 6.2 Content-Transfer-Encodings Semantics ................ 15
- 6.3 New Content-Transfer-Encodings ...................... 16
- 6.4 Interpretation and Use .............................. 16
- 6.5 Translating Encodings ............................... 18
- 6.6 Canonical Encoding Model ............................ 19
- 6.7 Quoted-Printable Content-Transfer-Encoding .......... 19
- 6.8 Base64 Content-Transfer-Encoding .................... 24
- 7. Content-ID Header Field .............................. 26
- 8. Content-Description Header Field ..................... 27
- 9. Additional MIME Header Fields ........................ 27
- 10. Summary ............................................. 27
- 11. Security Considerations ............................. 27
- 12. Authors' Addresses .................................. 28
- A. Collected Grammar .................................... 29
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 2]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-1. Introduction
-
- Since its publication in 1982, RFC 822 has defined the standard
- format of textual mail messages on the Internet. Its success has
- been such that the RFC 822 format has been adopted, wholly or
- partially, well beyond the confines of the Internet and the Internet
- SMTP transport defined by RFC 821. As the format has seen wider use,
- a number of limitations have proven increasingly restrictive for the
- user community.
-
- RFC 822 was intended to specify a format for text messages. As such,
- non-text messages, such as multimedia messages that might include
- audio or images, are simply not mentioned. Even in the case of text,
- however, RFC 822 is inadequate for the needs of mail users whose
- languages require the use of character sets richer than US-ASCII.
- Since RFC 822 does not specify mechanisms for mail containing audio,
- video, Asian language text, or even text in most European languages,
- additional specifications are needed.
-
- 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 (e.g. 1000 characters or less [RFC-821]) of
- 7bit US-ASCII. This forces users to convert any non-textual data
- that they may wish to send into seven-bit bytes representable as
- printable US-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 material 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 material must be
- converted to (not encoded in) IA5Text 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
- receive is lost. Even though a user agent may not have the
- capability of dealing with the non-textual material, the user might
- have some mechanism external to the UA that can extract useful
- information from the material. 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.
-
-
-
-
-Freed & Borenstein Standards Track [Page 3]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- 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 MIME
- and allows mail processing agents to distinguish
- between such messages and those generated by older or
- non-conformant software, which are presumed to lack
- such a field.
-
- (2) A Content-Type header field, generalized from RFC 1049,
- which can be used to specify the media type and subtype
- of data in the body of a message and to fully specify
- the native representation (canonical form) of such
- data.
-
- (3) A Content-Transfer-Encoding header field, which can be
- used to specify both the encoding transformation that
- was applied to the body and the domain of the result.
- Encoding transformations other than the identity
- transformation are usually applied to 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 body, the Content-ID and
- Content-Description header fields.
-
- All of the header fields defined in this document are subject to the
- general syntactic rules for header fields specified in RFC 822. In
- particular, all of these header fields except for Content-Disposition
- can include RFC 822 comments, which have no semantic content and
- should be ignored during MIME processing.
-
- Finally, to specify and promote interoperability, RFC 2049 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 set of
- documents 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 set of documents.
- In particular, compatibility was always favored over elegance.
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 4]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- Please refer to the current edition of the "Internet Official
- Protocol Standards" for the standardization state and status of this
- protocol. RFC 822 and STD 3, RFC 1123 also provide essential
- background for MIME since no conforming implementation of MIME can
- violate them. In addition, several other informational RFC documents
- will be of interest to the MIME implementor, in particular RFC 1344,
- RFC 1345, and RFC 1524.
-
-2. Definitions, Conventions, and Generic BNF Grammar
-
- Although the mechanisms specified in this set of documents are all
- described in prose, most are also described formally in the augmented
- BNF notation of RFC 822. Implementors will need to be familiar with
- this notation in order to understand this set of documents, and are
- referred to RFC 822 for a complete explanation of the augmented BNF
- notation.
-
- Some of the augmented BNF in this set of documents makes named
- references to syntax rules defined in RFC 822. A complete formal
- grammar, then, is obtained by combining the collected grammar
- appendices in each document in this set with the BNF of RFC 822 plus
- the modifications to RFC 822 defined in RFC 1123 (which specifically
- changes the syntax for `return', `date' and `mailbox').
-
- All numeric and octet values are given in decimal notation in this
- set of documents. All media type values, subtype values, and
- parameter names as defined are case-insensitive. However, parameter
- values are case-sensitive unless otherwise specified for the specific
- parameter.
-
- FORMATTING NOTE: Notes, such at this one, provide additional
- nonessential information which may be skipped by the reader without
- missing anything essential. The primary purpose of these non-
- essential notes is to convey information about the rationale of this
- set of documents, or to place these documents in the proper
- historical or evolutionary context. Such information may in
- particular 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 certain design choices were made.
-
-2.1. CRLF
-
- The term CRLF, in this set of documents, refers to the sequence of
- octets corresponding to the two US-ASCII characters CR (decimal value
- 13) and LF (decimal value 10) which, taken together, in this order,
- denote a line break in RFC 822 mail.
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 5]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-2.2. Character Set
-
- The term "character set" is used in MIME to refer to a method of
- converting a sequence of octets into a sequence of characters. Note
- that unconditional and unambiguous conversion in the other direction
- is not required, in that not all characters may be representable by a
- given character set and a character set may provide more than one
- sequence of octets to represent a particular sequence of characters.
-
- This definition is intended to allow various kinds of character
- encodings, from simple single-table mappings such as US-ASCII to
- complex table switching methods such as those that use ISO 2022's
- techniques, to be used as character sets. However, the definition
- associated with a MIME character set name must fully specify the
- mapping to be performed. In particular, use of external profiling
- information to determine the exact mapping is not permitted.
-
- NOTE: The term "character set" was originally to describe such
- straightforward schemes as US-ASCII and ISO-8859-1 which have a
- simple one-to-one mapping from single octets to single characters.
- Multi-octet coded character sets and switching techniques make the
- situation more complex. For example, some communities use the term
- "character encoding" for what MIME calls a "character set", while
- using the phrase "coded character set" to denote an abstract mapping
- from integers (not octets) to characters.
-
-2.3. Message
-
- The term "message", when not further qualified, means either a
- (complete or "top-level") RFC 822 message being transferred on a
- network, or a message encapsulated in a body of type "message/rfc822"
- or "message/partial".
-
-2.4. Entity
-
- The term "entity", refers specifically to the MIME-defined header
- fields and contents of either a message or one of the parts in the
- body of a multipart entity. The specification of such entities is
- the essence of MIME. Since the contents of an entity are often
- called the "body", it makes sense to speak about the body of an
- entity. Any sort of field may be present in the header of an entity,
- but only those fields whose names begin with "content-" actually have
- any MIME-related meaning. Note that this does NOT imply thay they
- have no meaning at all -- an entity that is also a message has non-
- MIME header fields whose meanings are defined by RFC 822.
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 6]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-2.5. Body Part
-
- The term "body part" refers to an entity inside of a multipart
- entity.
-
-2.6. 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.
-
- NOTE: The previous four definitions are clearly circular. This is
- unavoidable, since the overall structure of a MIME message is indeed
- recursive.
-
-2.7. 7bit Data
-
- "7bit data" refers to data that is all represented as relatively
- short lines with 998 octets or less between CRLF line separation
- sequences [RFC-821]. No octets with decimal values greater than 127
- are allowed and neither are NULs (octets with decimal value 0). CR
- (decimal value 13) and LF (decimal value 10) octets only occur as
- part of CRLF line separation sequences.
-
-2.8. 8bit Data
-
- "8bit data" refers to data that is all represented as relatively
- short lines with 998 octets or less between CRLF line separation
- sequences [RFC-821]), but octets with decimal values greater than 127
- may be used. As with "7bit data" CR and LF octets only occur as part
- of CRLF line separation sequences and no NULs are allowed.
-
-2.9. Binary Data
-
- "Binary data" refers to data where any sequence of octets whatsoever
- is allowed.
-
-2.10. Lines
-
- "Lines" are defined as sequences of octets separated by a CRLF
- sequences. This is consistent with both RFC 821 and RFC 822.
- "Lines" only refers to a unit of data in a message, which may or may
- not correspond to something that is actually displayed by a user
- agent.
-
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 7]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-3. MIME Header Fields
-
- MIME defines a number of new RFC 822 header fields that are used to
- describe the content of a MIME entity. These header fields occur in
- at least two contexts:
-
- (1) As part of a regular RFC 822 message header.
-
- (2) In a MIME body part header within a multipart
- construct.
-
- The formal definition of these header fields is as follows:
-
- entity-headers := [ content CRLF ]
- [ encoding CRLF ]
- [ id CRLF ]
- [ description CRLF ]
- *( MIME-extension-field CRLF )
-
- MIME-message-headers := entity-headers
- fields
- version CRLF
- ; The ordering of the header
- ; fields implied by this BNF
- ; definition should be ignored.
-
- MIME-part-headers := entity-headers
- [ fields ]
- ; Any field not beginning with
- ; "content-" can have no defined
- ; meaning and may be ignored.
- ; The ordering of the header
- ; fields implied by this BNF
- ; definition should be ignored.
-
- The syntax of the various specific MIME header fields will be
- described in the following sections.
-
-4. 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 specification 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.
-
-
-
-Freed & Borenstein Standards Track [Page 8]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- 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
- 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 document.
-
- 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/rfc822" or "message/partial" 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".
-
- It is also worth noting that version control for specific media 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 media format. Where such
- conventions exist, MIME does nothing to supersede them. Where no
- such conventions exist, a MIME media type might use a "version"
- parameter in the content-type field if necessary.
-
-
-
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 9]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- NOTE TO IMPLEMENTORS: When checking MIME-Version values any RFC 822
- comment strings that are present must be ignored. In particular, the
- following four MIME-Version fields are equivalent:
-
- MIME-Version: 1.0
-
- MIME-Version: 1.0 (produced by MetaSend Vx.x)
-
- MIME-Version: (produced by MetaSend Vx.x) 1.0
-
- MIME-Version: 1.(produced by MetaSend Vx.x)0
-
- In the absence of a MIME-Version field, a receiving mail user agent
- (whether conforming to MIME requirements or not) may optionally
- choose to interpret the body of the message according to local
- conventions. Many such conventions are currently in use and it
- should be noted that in practice non-MIME messages can contain just
- about anything.
-
- It is impossible to be certain that a non-MIME mail message is
- actually plain text in the US-ASCII character set since it might well
- be a message that, using some set of nonstandard local conventions
- that predate MIME, includes text in another character set or non-
- textual data presented in a manner that cannot be automatically
- recognized (e.g., a uuencoded compressed UNIX tar file).
-
-5. 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. The
- value in this field is called a media type.
-
- HISTORICAL NOTE: The Content-Type header field was first defined in
- RFC 1049. RFC 1049 used a simpler and less powerful syntax, but one
- that is largely compatible with the mechanism given here.
-
- The Content-Type header field specifies the nature of the data in the
- body of an entity by giving media type and subtype identifiers, and
- by providing auxiliary information that may be required for certain
- media types. After the media type and subtype names, the remainder
- of the header field is simply a set of parameters, specified in an
- attribute=value notation. The ordering of parameters is not
- significant.
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 10]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- In general, the top-level media type is used to declare the general
- type of data, while the subtype specifies a specific format for that
- type of data. Thus, a media 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 text, image, audio, and video should not contain embedded
- information that is really of a different type. Such compound
- formats should be represented using the "multipart" or "application"
- types.
-
- Parameters are modifiers of the media subtype, and as such do not
- fundamentally affect the nature of the content. The set of
- meaningful parameters depends on the media type and subtype. Most
- parameters are associated with a single specific subtype. However, a
- given top-level media type may define parameters which are applicable
- to any subtype of that type. Parameters may be required by their
- defining content type or subtype or they may be optional. MIME
- implementations must ignore any parameters whose names they do not
- recognize.
-
- For example, the "charset" parameter is applicable to any subtype of
- "text", while the "boundary" parameter is required for any subtype of
- the "multipart" media type.
-
- There are NO globally-meaningful parameters that apply to all media
- types. Truly global mechanisms are best addressed, in the MIME
- model, by the definition of additional Content-* header fields.
-
- An initial set of seven top-level media types is defined in RFC 2046.
- Five of these are discrete types whose content is essentially opaque
- as far as MIME processing is concerned. The remaining two are
- composite types whose contents require additional handling by MIME
- processors.
-
- This set of top-level media types 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 a standards-track extension to this standard.
- If another top-level 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.
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 11]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-5.1. Syntax of the Content-Type Header Field
-
- In the Augmented BNF notation of RFC 822, a Content-Type header field
- value is defined as follows:
-
- content := "Content-Type" ":" type "/" subtype
- *(";" parameter)
- ; Matching of media type and subtype
- ; is ALWAYS case-insensitive.
-
- type := discrete-type / composite-type
-
- discrete-type := "text" / "image" / "audio" / "video" /
- "application" / extension-token
-
- composite-type := "message" / "multipart" / extension-token
-
- extension-token := ietf-token / x-token
-
- ietf-token := <An extension token defined by a
- standards-track RFC and registered
- with IANA.>
-
- x-token := <The two characters "X-" or "x-" followed, with
- no intervening white space, by any token>
-
- subtype := extension-token / iana-token
-
- iana-token := <A publicly-defined extension token. Tokens
- of this form must be registered with IANA
- as specified in RFC 2048.>
-
- parameter := attribute "=" value
-
- attribute := token
- ; Matching of attributes
- ; is ALWAYS case-insensitive.
-
- value := token / quoted-string
-
- token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
- or tspecials>
-
- tspecials := "(" / ")" / "<" / ">" / "@" /
- "," / ";" / ":" / "\" / <">
- "/" / "[" / "]" / "?" / "="
- ; Must be in quoted-string,
- ; to use within parameter values
-
-
-
-Freed & Borenstein Standards Track [Page 12]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- 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 -- it may not be
- omitted from a Content-Type header field. As such, there are no
- default subtypes.
-
- The type, subtype, and parameter names are not case sensitive. For
- example, TEXT, Text, and TeXt are all equivalent top-level media
- types. Parameter values are normally case sensitive, but sometimes
- are interpreted in a case-insensitive fashion, depending on the
- intended use. (For example, multipart boundaries are case-sensitive,
- but the "access-type" parameter for message/External-body is not
- case-sensitive.)
-
- Note that the value of a quoted string parameter does not include the
- quotes. That is, the quotation marks in a quoted-string are not a
- part of the value of the parameter, but are merely used to delimit
- that parameter value. In addition, comments are allowed in
- accordance with RFC 822 rules for structured header fields. Thus the
- following two forms
-
- Content-type: text/plain; charset=us-ascii (Plain text)
-
- Content-type: text/plain; charset="us-ascii"
-
- are completely equivalent.
-
- Beyond this syntax, the only syntactic 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 media subtypes, then, is not
- intended to be a mechanism for imposing restrictions, but simply a
- mechanism for publicizing their definition and usage. There are,
- therefore, two acceptable mechanisms for defining new media subtypes:
-
- (1) Private values (starting with "X-") may be defined
- bilaterally between two cooperating agents without
- outside registration or standardization. Such values
- cannot be registered or standardized.
-
- (2) New standard values should be registered with IANA as
- described in RFC 2048.
-
- The second document in this set, RFC 2046, defines the initial set of
- media types for MIME.
-
-
-
-Freed & Borenstein Standards Track [Page 13]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-5.2. Content-Type Defaults
-
- Default RFC 822 messages without a MIME Content-Type header are taken
- by this protocol to be plain text in the US-ASCII character set,
- which can be explicitly specified as:
-
- Content-type: text/plain; charset=us-ascii
-
- This default is assumed if no Content-Type header field is specified.
- It is also recommend that this default be assumed when a
- syntactically invalid Content-Type header field is encountered. In
- the presence of a MIME-Version header field and the absence of any
- Content-Type header field, a receiving User Agent can also assume
- that plain US-ASCII text was the sender's intent. Plain US-ASCII
- text may still be assumed in the absence of a MIME-Version or the
- presence of an syntactically invalid Content-Type header field, but
- the sender's intent might have been otherwise.
-
-6. Content-Transfer-Encoding Header Field
-
- Many media types which could be usefully transported via email are
- represented, in their "natural" format, as 8bit character or binary
- data. Such data cannot be transmitted over some transfer protocols.
- For example, RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII
- data with lines no longer than 1000 characters including any trailing
- CRLF line separator.
-
- It is necessary, therefore, to define a standard mechanism for
- encoding such data into a 7bit short line format. Proper labelling
- of unencoded material in less restrictive formats for direct use over
- less restrictive transports is also desireable. This document
- specifies that such encodings will be indicated by a new "Content-
- Transfer-Encoding" header field. This field has not been defined by
- any previous standard.
-
-6.1. Content-Transfer-Encoding Syntax
-
- The Content-Transfer-Encoding field's value is a single token
- specifying the type of encoding, as enumerated below. Formally:
-
- encoding := "Content-Transfer-Encoding" ":" mechanism
-
- mechanism := "7bit" / "8bit" / "binary" /
- "quoted-printable" / "base64" /
- ietf-token / x-token
-
- These values are not case sensitive -- Base64 and BASE64 and bAsE64
- are all equivalent. An encoding type of 7BIT requires that the body
-
-
-
-Freed & Borenstein Standards Track [Page 14]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- is already in a 7bit 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.
-
-6.2. Content-Transfer-Encodings Semantics
-
- This single Content-Transfer-Encoding token actually provides two
- pieces of information. It specifies what sort of encoding
- transformation the body was subjected to and hence what decoding
- operation must be used to restore it to its original form, and it
- specifies what the domain of the result is.
-
- The transformation part of any Content-Transfer-Encodings specifies,
- either explicitly or implicitly, a single, well-defined decoding
- algorithm, which for any sequence of encoded octets either transforms
- it to the original sequence of octets which was encoded, or shows
- that it is illegal as an encoded sequence. Content-Transfer-
- Encodings transformations never depend on any additional external
- profile information for proper operation. Note that while decoders
- must produce a single, well-defined output for a valid encoding no
- such restrictions exist for encoders: Encoding a given sequence of
- octets to different, equivalent encoded sequences is perfectly legal.
-
- Three transformations are currently defined: identity, the "quoted-
- printable" encoding, and the "base64" encoding. The domains are
- "binary", "8bit" and "7bit".
-
- The Content-Transfer-Encoding values "7bit", "8bit", and "binary" all
- mean that the identity (i.e. NO) encoding transformation has been
- performed. As such, they serve simply as indicators of the domain of
- the body data, and provide useful information about the sort of
- encoding that might be needed for transmission in a given transport
- system. The terms "7bit data", "8bit data", and "binary data" are
- all defined in Section 2.
-
- The quoted-printable and base64 encodings transform their input from
- an arbitrary domain into material in the "7bit" range, thus making it
- safe to carry over restricted transports. The specific definition of
- the transformations are given below.
-
- The proper Content-Transfer-Encoding label must always be used.
- Labelling unencoded data containing 8bit characters as "7bit" is not
- allowed, nor is labelling unencoded non-line-oriented data as
- anything other than "binary" allowed.
-
- Unlike media subtypes, a proliferation of Content-Transfer-Encoding
- values is both undesirable and unnecessary. However, establishing
- only a single transformation into the "7bit" domain does not seem
-
-
-
-Freed & Borenstein Standards Track [Page 15]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- possible. There is a tradeoff between the desire for a compact and
- efficient encoding of largely- binary data and the desire for a
- somewhat readable encoding of data that is mostly, but not entirely,
- 7bit. For this reason, at least two encoding mechanisms are
- necessary: a more or less readable encoding (quoted-printable) and a
- "dense" or "uniform" encoding (base64).
-
- Mail transport for unencoded 8bit data is defined in RFC 1652. As of
- the initial 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 valid in Internet mail. However, in the event that binary
- mail transport becomes a reality in Internet mail, or when MIME is
- used in conjunction with any other binary-capable mail transport
- mechanism, binary bodies must be labelled as such using this
- mechanism.
-
- NOTE: The five values defined for the Content-Transfer-Encoding field
- imply nothing about the media type other than the algorithm by which
- it was encoded or the transport system requirements if unencoded.
-
-6.3. New Content-Transfer-Encodings
-
- Implementors may, if necessary, define private 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". Additional standardized Content-
- Transfer-Encoding values must be specified by a standards-track RFC.
- The requirements such specifications must meet are given in RFC 2048.
- As such, all content-transfer-encoding namespace except that
- beginning with "X-" is explicitly reserved to the IETF for future
- use.
-
- Unlike media types and subtypes, the creation of new Content-
- Transfer-Encoding values is STRONGLY discouraged, as it seems likely
- to hinder interoperability with little potential benefit
-
-6.4. Interpretation and Use
-
- 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 an entity's
- headers, it applies only to the body of that entity. If an entity is
- of type "multipart" the Content-Transfer-Encoding is not permitted to
- have any value other than "7bit", "8bit" or "binary". Even more
- severe restrictions apply to some subtypes of the "message" type.
-
-
-
-
-Freed & Borenstein Standards Track [Page 16]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- It should be noted that most media types are defined in terms of
- octets rather than bits, 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 8bit 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 8bit byte. A bit stream not ending
- at an 8bit boundary must be padded with zeroes. RFC 2046 provides a
- mechanism for noting the addition of such padding in the case of the
- application/octet-stream media type, which has a "padding" parameter.
-
- The encoding mechanisms defined here explicitly encode all data in
- US-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 US-ASCII
- encoding of data that was originally in ISO-8859-1, and will be in
- that character set again after decoding.
-
- Certain Content-Transfer-Encoding values may only be used on certain
- media types. In particular, it is EXPRESSLY FORBIDDEN to use any
- encodings other than "7bit", "8bit", or "binary" with any composite
- media type, i.e. one that recursively includes other Content-Type
- fields. Currently the only composite media types are "multipart" and
- "message". 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.
-
- It should also be noted that, by definition, if a composite entity
- has a transfer-encoding value such as "7bit", but one of the enclosed
- entities has a less restrictive value such as "8bit", then either the
- outer "7bit" labelling is in error, because 8bit data are included,
- or the inner "8bit" labelling placed an unnecessarily high demand on
- the transport system because the actual included data were actually
- 7bit-safe.
-
- NOTE ON ENCODING RESTRICTIONS: Though the prohibition against using
- content-transfer-encodings on composite body data 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
-
-
-
-Freed & Borenstein Standards Track [Page 17]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- to find out what types of bodies 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.
-
- Any entity with an unrecognized Content-Transfer-Encoding must be
- treated as if it has a Content-Type of "application/octet-stream",
- regardless of what the Content-Type header field actually says.
-
- 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 media that is to be encoded,
- or, at the very least, that certain Content-Transfer-Encodings could
- be mandated for use with specific media 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
- combinations of media types and transports but not for others. (For
- example, in an 8bit transport, no encoding would be required for text
- in certain character sets, while such encodings are clearly required
- for 7bit SMTP.)
-
- Second, certain media types may require different types of transfer
- encoding under different circumstances. For example, many PostScript
- bodies might consist entirely of short lines of 7bit data and hence
- require no encoding at all. 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 the Content-Type field is intended to be an open-ended
- specification mechanism, strict specification of an association
- between media 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 media
- type should not have to be aware of all the transports in use and
- what their limitations are.
-
-6.5. 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 hard line breaks in quoted-
- printable encoding output. When converting from quoted-printable to
- base64 a hard line break in the quoted-printable form represents a
- CRLF sequence in the canonical form of the data. It must therefore be
- converted to a corresponding encoded CRLF in the base64 form of the
- data. Similarly, a CRLF sequence in the canonical form of the data
- obtained after base64 decoding must be converted to a quoted-
- printable hard line break, but ONLY when converting text data.
-
-
-
-
-Freed & Borenstein Standards Track [Page 18]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-6.6. Canonical Encoding Model
-
- There was some confusion, in the previous versions of this RFC,
- 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. A canonical
- model for encoding is presented in RFC 2049 for this reason.
-
-6.7. 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 US-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 US-ASCII text, the encoded form
- of the data remains largely recognizable by humans. A body which is
- entirely US-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:
-
- (1) (General 8bit representation) Any octet, except a CR or
- LF that is part of a CRLF line break 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; lowercase letters are not allowed. Thus, for
- example, the decimal value 12 (US-ASCII form feed) can
- be represented by "=0C", and the decimal value 61 (US-
- ASCII EQUAL SIGN) can be represented by "=3D". This
- rule must be followed except when the following rules
- allow an alternative encoding.
-
- (2) (Literal representation) Octets with decimal values of
- 33 through 60 inclusive, and 62 through 126, inclusive,
- MAY be represented as the US-ASCII characters which
- correspond to those octets (EXCLAMATION POINT through
- LESS THAN, and GREATER THAN through TILDE,
- respectively).
-
- (3) (White Space) Octets with values of 9 and 32 MAY be
- represented as US-ASCII TAB (HT) and SPACE characters,
-
-
-
-Freed & Borenstein Standards Track [Page 19]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- 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 "=" 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 decimal
- 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 portion 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.
-
- (4) (Line Breaks) A line break in a text body, represented
- as a CRLF sequence in the text canonical form, must be
- represented by a (RFC 822) line break, which is also a
- CRLF sequence, in the Quoted-Printable encoding. Since
- the canonical representation of media types other than
- text do not generally include the representation of
- line breaks as CRLF sequences, no hard line breaks
- (i.e. line breaks that are intended to be meaningful
- and to be displayed to the user) can occur in the
- quoted-printable encoding of such types. Sequences
- like "=0D", "=0A", "=0A=0D" and "=0D=0A" will routinely
- appear in non-text data represented in quoted-
- printable, of course.
-
- Note that many implementations may elect to encode the
- local representation of various content types directly
- rather than converting to canonical form first,
- encoding, and then converting back to local
- representation. In particular, this may apply to plain
- text material on systems that use newline conventions
- other than a CRLF terminator sequence. Such an
- implementation optimization is permissible, but only
- when the combined canonicalization-encoding step is
- equivalent to performing the three steps separately.
-
- (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
-
-
-
-Freed & Borenstein Standards Track [Page 20]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- 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:
-
- 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 ("-") may be represented as itself in the
- Quoted-Printable encoding, care must be taken, when encapsulating a
- quoted-printable encoded body inside one or more multipart entities,
- to ensure that the boundary delimiter 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 in
- RFC 2046.)
-
- 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. 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 US-ASCII characters
-
- !"#$@[\]^`{|}~
-
- according to rule #1.
-
- 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
-
-
-
-Freed & Borenstein Standards Track [Page 21]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- corruption of the data, it is probably more sensible to use the
- base64 encoding rather than the quoted-printable encoding.
-
- NOTE: Several kinds of substrings cannot be generated according to
- the encoding rules for the quoted-printable content-transfer-
- encoding, and hence are formally illegal if they appear in the output
- of a quoted-printable encoder. This note enumerates these cases and
- suggests ways to handle such illegal substrings if any are
- encountered in quoted-printable data that is to be decoded.
-
- (1) An "=" followed by two hexadecimal digits, one or both
- of which are lowercase letters in "abcdef", is formally
- illegal. A robust implementation might choose to
- recognize them as the corresponding uppercase letters.
-
- (2) An "=" followed by a character that is neither a
- hexadecimal digit (including "abcdef") nor the CR
- character of a CRLF pair is illegal. This case can be
- the result of US-ASCII text having been included in a
- quoted-printable part of a message without itself
- having been subjected to quoted-printable encoding. A
- reasonable approach by a robust implementation might be
- to include the "=" character and the following
- character in the decoded data without any
- transformation and, if possible, indicate to the user
- that proper decoding was not possible at this point in
- the data.
-
- (3) An "=" cannot be the ultimate or penultimate character
- in an encoded object. This could be handled as in case
- (2) above.
-
- (4) Control characters other than TAB, or CR and LF as
- parts of CRLF pairs, must not appear. The same is true
- for octets with decimal values greater than 126. If
- found in incoming quoted-printable data by a decoder, a
- robust implementation might exclude them from the
- decoded data and warn the user that illegal characters
- were discovered.
-
- (5) Encoded lines must not be longer than 76 characters,
- not counting the trailing CRLF. If longer lines are
- found in incoming, encoded data, a robust
- implementation might nevertheless decode the lines, and
- might report the erroneous encoding to the user.
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 22]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- WARNING TO IMPLEMENTORS: If binary data is 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
- platforms with different line break conventions.
-
- For formalists, the syntax of quoted-printable data is described by
- the following grammar:
-
- quoted-printable := qp-line *(CRLF qp-line)
-
- qp-line := *(qp-segment transport-padding CRLF)
- qp-part transport-padding
-
- qp-part := qp-section
- ; Maximum length of 76 characters
-
- qp-segment := qp-section *(SPACE / TAB) "="
- ; Maximum length of 76 characters
-
- qp-section := [*(ptext / SPACE / TAB) ptext]
-
- ptext := hex-octet / safe-char
-
- safe-char := <any octet with decimal value of 33 through
- 60 inclusive, and 62 through 126>
- ; Characters not listed as "mail-safe" in
- ; RFC 2049 are also not recommended.
-
- hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
- ; Octet must be used for characters > 127, =,
- ; SPACEs or TABs at the ends of lines, and is
- ; recommended for any character not listed in
- ; RFC 2049 as "mail-safe".
-
- transport-padding := *LWSP-char
- ; Composers MUST NOT generate
- ; non-zero length transport
- ; padding, but receivers MUST
- ; be able to handle padding
- ; added by message transports.
-
- IMPORTANT: The addition of LWSP between the elements shown in this
- BNF is NOT allowed since this BNF does not specify a structured
- header field.
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 23]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-6.8. 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.
-
- 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, Macintosh binhex 4.0 [RFC-1741], 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 8bit 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.
- That is, the first bit in the stream will be the high-order bit in
- the first 8bit byte, and the eighth bit will be the low-order bit in
- the first 8bit 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 multipart boundary delimiters defined in RFC 2046 (e.g.,
- "-").
-
-
-
-
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 24]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- 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 encoded output stream 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
- 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
-
-
-
-Freed & Borenstein Standards Track [Page 25]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- such assurance is possible, however, when the number of octets
- transmitted was a multiple of three and no "=" characters are
- present.
-
- Any characters outside of the base64 alphabet are to be ignored in
- base64-encoded data.
-
- 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 potential boundary
- delimiters within base64-encoded bodies within multipart entities
- because no hyphen characters are used in the base64 encoding.
-
-7. 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
- labelled 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 caching data
- referenced by the message/external-body mechanism. Although the
- Content-ID header is generally optional, its use is MANDATORY in
- implementations which generate data of the optional MIME media type
- "message/external-body". That is, each message/external-body entity
- must have a Content-ID field to permit caching of such data.
-
- It is also worth noting that the Content-ID value has special
- semantics in the case of the multipart/alternative media type. This
- is explained in the section of RFC 2046 dealing with
- multipart/alternative.
-
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 26]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-8. 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. This header
- field is always optional.
-
- description := "Content-Description" ":" *text
-
- The description is presumed to be given in the US-ASCII character
- set, although the mechanism specified in RFC 2047 may be used for
- non-US-ASCII Content-Description values.
-
-9. Additional MIME Header Fields
-
- Future documents may elect to define additional MIME header fields
- for various purposes. Any new header field that further describes
- the content of a message should begin with the string "Content-" to
- allow such fields which appear in a message header to be
- distinguished from ordinary RFC 822 message header fields.
-
- MIME-extension-field := <Any RFC 822 header field which
- begins with the string
- "Content-">
-
-10. 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 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 RFC 2049).
-
- The next document in this set, RFC 2046, specifies the initial set of
- media types that can be labelled and transported using these headers.
-
-11. Security Considerations
-
- Security issues are discussed in the second document in this set, RFC
- 2046.
-
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 27]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-12. Authors' Addresses
-
- For more information, the authors of this document are best contacted
- via Internet mail:
-
- Ned Freed
- Innosoft International, Inc.
- 1050 East Garvey Avenue South
- West Covina, CA 91790
- USA
-
- Phone: +1 818 919 3600
- Fax: +1 818 919 3614
- EMail: [email protected]
-
-
- Nathaniel S. Borenstein
- First Virtual Holdings
- 25 Washington Avenue
- Morristown, NJ 07960
- USA
-
- Phone: +1 201 540 8967
- Fax: +1 201 993 3032
- EMail: [email protected]
-
-
- MIME is a result of the work of the Internet Engineering Task Force
- Working Group on RFC 822 Extensions. The chairman of that group,
- Greg Vaudreuil, may be reached at:
-
- Gregory M. Vaudreuil
- Octel Network Services
- 17080 Dallas Parkway
- Dallas, TX 75248-1905
- USA
-
- EMail: [email protected]
-
-
-
-
-
-
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 28]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-Appendix A -- 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 by name to
- several syntax rules 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.
-
- attribute := token
- ; Matching of attributes
- ; is ALWAYS case-insensitive.
-
- composite-type := "message" / "multipart" / extension-token
-
- content := "Content-Type" ":" type "/" subtype
- *(";" parameter)
- ; Matching of media type and subtype
- ; is ALWAYS case-insensitive.
-
- description := "Content-Description" ":" *text
-
- discrete-type := "text" / "image" / "audio" / "video" /
- "application" / extension-token
-
- encoding := "Content-Transfer-Encoding" ":" mechanism
-
- entity-headers := [ content CRLF ]
- [ encoding CRLF ]
- [ id CRLF ]
- [ description CRLF ]
- *( MIME-extension-field CRLF )
-
- extension-token := ietf-token / x-token
-
- hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
- ; Octet must be used for characters > 127, =,
- ; SPACEs or TABs at the ends of lines, and is
- ; recommended for any character not listed in
- ; RFC 2049 as "mail-safe".
-
- iana-token := <A publicly-defined extension token. Tokens
- of this form must be registered with IANA
- as specified in RFC 2048.>
-
-
-
-
-Freed & Borenstein Standards Track [Page 29]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- ietf-token := <An extension token defined by a
- standards-track RFC and registered
- with IANA.>
-
- id := "Content-ID" ":" msg-id
-
- mechanism := "7bit" / "8bit" / "binary" /
- "quoted-printable" / "base64" /
- ietf-token / x-token
-
- MIME-extension-field := <Any RFC 822 header field which
- begins with the string
- "Content-">
-
- MIME-message-headers := entity-headers
- fields
- version CRLF
- ; The ordering of the header
- ; fields implied by this BNF
- ; definition should be ignored.
-
- MIME-part-headers := entity-headers
- [fields]
- ; Any field not beginning with
- ; "content-" can have no defined
- ; meaning and may be ignored.
- ; The ordering of the header
- ; fields implied by this BNF
- ; definition should be ignored.
-
- parameter := attribute "=" value
-
- ptext := hex-octet / safe-char
-
- qp-line := *(qp-segment transport-padding CRLF)
- qp-part transport-padding
-
- qp-part := qp-section
- ; Maximum length of 76 characters
-
- qp-section := [*(ptext / SPACE / TAB) ptext]
-
- qp-segment := qp-section *(SPACE / TAB) "="
- ; Maximum length of 76 characters
-
- quoted-printable := qp-line *(CRLF qp-line)
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 30]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- safe-char := <any octet with decimal value of 33 through
- 60 inclusive, and 62 through 126>
- ; Characters not listed as "mail-safe" in
- ; RFC 2049 are also not recommended.
-
- subtype := extension-token / iana-token
-
- token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
- or tspecials>
-
- transport-padding := *LWSP-char
- ; Composers MUST NOT generate
- ; non-zero length transport
- ; padding, but receivers MUST
- ; be able to handle padding
- ; added by message transports.
-
- tspecials := "(" / ")" / "<" / ">" / "@" /
- "," / ";" / ":" / "\" / <">
- "/" / "[" / "]" / "?" / "="
- ; Must be in quoted-string,
- ; to use within parameter values
-
- type := discrete-type / composite-type
-
- value := token / quoted-string
-
- version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
-
- x-token := <The two characters "X-" or "x-" followed, with
- no intervening white space, by any token>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 31]
-
diff --git a/doc/rfc/rfc2046.txt b/doc/rfc/rfc2046.txt
deleted file mode 100644
index 84d90c1..0000000
--- a/doc/rfc/rfc2046.txt
+++ /dev/null
@@ -1,2467 +0,0 @@
-
-
-
-
-
-
-Network Working Group N. Freed
-Request for Comments: 2046 Innosoft
-Obsoletes: 1521, 1522, 1590 N. Borenstein
-Category: Standards Track First Virtual
- November 1996
-
-
- Multipurpose Internet Mail Extensions
- (MIME) Part Two:
- Media Types
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- STD 11, RFC 822 defines a message representation protocol specifying
- considerable detail about US-ASCII message headers, but which leaves
- the message content, or message body, as flat US-ASCII text. This
- set of documents, collectively called the Multipurpose Internet Mail
- Extensions, or MIME, redefines the format of messages to allow for
-
- (1) textual message bodies in character sets other than
- US-ASCII,
-
- (2) an extensible set of different formats for non-textual
- message bodies,
-
- (3) multi-part message bodies, and
-
- (4) textual header information in character sets other than
- US-ASCII.
-
- These documents are based on earlier work documented in RFC 934, STD
- 11, and RFC 1049, but extends and revises them. Because RFC 822 said
- so little about message bodies, these documents are largely
- orthogonal to (rather than a revision of) RFC 822.
-
- The initial document in this set, RFC 2045, specifies the various
- headers used to describe the structure of MIME messages. This second
- document defines the general structure of the MIME media typing
- system and defines an initial set of media types. The third document,
- RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text
-
-
-
-Freed & Borenstein Standards Track [Page 1]
-
-RFC 2046 Media Types November 1996
-
-
- data in Internet mail header fields. The fourth document, RFC 2048,
- specifies various IANA registration procedures for MIME-related
- facilities. The fifth and final document, RFC 2049, describes MIME
- conformance criteria as well as providing some illustrative examples
- of MIME message formats, acknowledgements, and the bibliography.
-
- These documents are revisions of RFCs 1521 and 1522, which themselves
- were revisions of RFCs 1341 and 1342. An appendix in RFC 2049
- describes differences and changes from previous versions.
-
-Table of Contents
-
- 1. Introduction ......................................... 3
- 2. Definition of a Top-Level Media Type ................. 4
- 3. Overview Of The Initial Top-Level Media Types ........ 4
- 4. Discrete Media Type Values ........................... 6
- 4.1 Text Media Type ..................................... 6
- 4.1.1 Representation of Line Breaks ..................... 7
- 4.1.2 Charset Parameter ................................. 7
- 4.1.3 Plain Subtype ..................................... 11
- 4.1.4 Unrecognized Subtypes ............................. 11
- 4.2 Image Media Type .................................... 11
- 4.3 Audio Media Type .................................... 11
- 4.4 Video Media Type .................................... 12
- 4.5 Application Media Type .............................. 12
- 4.5.1 Octet-Stream Subtype .............................. 13
- 4.5.2 PostScript Subtype ................................ 14
- 4.5.3 Other Application Subtypes ........................ 17
- 5. Composite Media Type Values .......................... 17
- 5.1 Multipart Media Type ................................ 17
- 5.1.1 Common Syntax ..................................... 19
- 5.1.2 Handling Nested Messages and Multiparts ........... 24
- 5.1.3 Mixed Subtype ..................................... 24
- 5.1.4 Alternative Subtype ............................... 24
- 5.1.5 Digest Subtype .................................... 26
- 5.1.6 Parallel Subtype .................................. 27
- 5.1.7 Other Multipart Subtypes .......................... 28
- 5.2 Message Media Type .................................. 28
- 5.2.1 RFC822 Subtype .................................... 28
- 5.2.2 Partial Subtype ................................... 29
- 5.2.2.1 Message Fragmentation and Reassembly ............ 30
- 5.2.2.2 Fragmentation and Reassembly Example ............ 31
- 5.2.3 External-Body Subtype ............................. 33
- 5.2.4 Other Message Subtypes ............................ 40
- 6. Experimental Media Type Values ....................... 40
- 7. Summary .............................................. 41
- 8. Security Considerations .............................. 41
- 9. Authors' Addresses ................................... 42
-
-
-
-Freed & Borenstein Standards Track [Page 2]
-
-RFC 2046 Media Types November 1996
-
-
- A. Collected Grammar .................................... 43
-
-1. Introduction
-
- The first document in this set, RFC 2045, defines a number of header
- fields, including Content-Type. The Content-Type field is used to
- specify the nature of the data in the body of a MIME entity, by
- giving media type and subtype identifiers, and by providing auxiliary
- information that may be required for certain media 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
- ordering of parameters is not significant.
-
- In general, the top-level media type is used to declare the general
- type of data, while the subtype specifies a specific format for that
- type of data. Thus, a media 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 "text", "image", "audio", and "video" should
- not contain embedded information that is really of a different type.
- Such compound formats should be represented using the "multipart" or
- "application" types.
-
- Parameters are modifiers of the media subtype, and as such do not
- fundamentally affect the nature of the content. The set of
- meaningful parameters depends on the media type and subtype. Most
- parameters are associated with a single specific subtype. However, a
- given top-level media type may define parameters which are applicable
- to any subtype of that type. Parameters may be required by their
- defining media type or subtype or they may be optional. MIME
- implementations must also ignore any parameters whose names they do
- not recognize.
-
- MIME's Content-Type header field and media type mechanism has been
- carefully designed to be extensible, and it is expected that the set
- of media type/subtype pairs and their associated parameters will grow
- significantly over time. Several other MIME facilities, such as
- transfer encodings and "message/external-body" access types, 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 sets up a registration process which uses the
- Internet Assigned Numbers Authority (IANA) as a central registry for
- MIME's various areas of extensibility. The registration process for
- these areas is described in a companion document, RFC 2048.
-
-
-
-Freed & Borenstein Standards Track [Page 3]
-
-RFC 2046 Media Types November 1996
-
-
- The initial seven standard top-level media type are defined and
- described in the remainder of this document.
-
-2. Definition of a Top-Level Media Type
-
- The definition of a top-level media type consists of:
-
- (1) a name and a description of the type, including
- criteria for whether a particular type would qualify
- under that type,
-
- (2) the names and definitions of parameters, if any, which
- are defined for all subtypes of that type (including
- whether such parameters are required or optional),
-
- (3) how a user agent and/or gateway should handle unknown
- subtypes of this type,
-
- (4) general considerations on gatewaying entities of this
- top-level type, if any, and
-
- (5) any restrictions on content-transfer-encodings for
- entities of this top-level type.
-
-3. Overview Of The Initial Top-Level Media Types
-
- The five discrete top-level media types are:
-
- (1) text -- textual information. The subtype "plain" in
- particular indicates plain text containing no
- formatting commands or directives of any sort. Plain
- text is intended to be displayed "as-is". No special
- software is required to get the full meaning of the
- text, aside from support for the indicated character
- set. Other 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 of "text" thus include any
- word processor format that can be read without
- resorting to software that understands the format. In
- particular, formats that employ embeddded binary
- formatting information are not considered directly
- readable. A very simple and portable subtype,
- "richtext", was defined in RFC 1341, with a further
- revision in RFC 1896 under the name "enriched".
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 4]
-
-RFC 2046 Media Types November 1996
-
-
- (2) image -- image data. "Image" requires a display device
- (such as a graphical display, a graphics printer, or a
- FAX machine) to view the information. An initial
- subtype is defined for the widely-used image format
- JPEG. . subtypes are defined for two widely-used image
- formats, jpeg and gif.
-
- (3) audio -- audio data. "Audio" requires an audio output
- device (such as a speaker or a telephone) to "display"
- the contents. An initial subtype "basic" is defined in
- this document.
-
- (4) video -- video data. "Video" requires the capability
- to display moving images, typically including
- specialized hardware and software. An initial subtype
- "mpeg" is defined in this document.
-
- (5) application -- some other kind of data, typically
- either uninterpreted binary data or information to be
- processed by an application. The 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. The "PostScript" subtype is also defined
- for the transport of PostScript material. Other
- expected uses for "application" include spreadsheets,
- data for mail-based scheduling systems, and languages
- for "active" (computational) messaging, and word
- processing formats that are not directly readable.
- Note that security considerations may exist for some
- types of application data, most notably
- "application/PostScript" and any form of active
- messaging. These issues are discussed later in this
- document.
-
- The two composite top-level media types are:
-
- (1) multipart -- data consisting of multiple entities of
- independent data types. Four subtypes are initially
- defined, including the basic "mixed" subtype specifying
- a generic mixed set of parts, "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 has a default type of "message/rfc822".
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 5]
-
-RFC 2046 Media Types November 1996
-
-
- (2) message -- an encapsulated message. A body of media
- type "message" is itself all or a portion of some kind
- of message object. Such objects may or may not in turn
- contain other entities. The "rfc822" subtype is used
- when the encapsulated content is itself an RFC 822
- message. The "partial" subtype is defined for partial
- RFC 822 messages, to permit the fragmented transmission
- of bodies that are thought to be too large to be passed
- through transport facilities in one piece. Another
- subtype, "external-body", is defined for specifying
- large bodies by reference to an external data source.
-
- It should be noted that the list of media 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.
-
-4. Discrete Media Type Values
-
- Five of the seven initial media type values refer to discrete bodies.
- The content of these types must be handled by non-MIME mechanisms;
- they are opaque to MIME processors.
-
-4.1. Text Media Type
-
- The "text" media type is intended for sending material which is
- principally textual in form. A "charset" parameter may be used to
- indicate the character set of the body text for "text" subtypes,
- notably including the subtype "text/plain", which is a generic
- subtype for plain text. Plain text does not provide for or allow
- formatting commands, font attribute specifications, processing
- instructions, interpretation directives, or content markup. Plain
- text is seen simply as a linear sequence of characters, possibly
- interrupted by line breaks or page breaks. Plain text may allow the
- stacking of several characters in the same position in the text.
- Plain text in scripts like Arabic and Hebrew may also include
- facilitites that allow the arbitrary mixing of text segments with
- opposite writing directions.
-
- Beyond plain text, there are many formats for representing what might
- be known as "rich text". 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
- 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".
-
-
-
-Freed & Borenstein Standards Track [Page 6]
-
-RFC 2046 Media Types November 1996
-
-
-4.1.1. Representation of Line Breaks
-
- The canonical form of any MIME "text" subtype MUST always represent a
- line break as a CRLF sequence. Similarly, any occurrence of CRLF in
- MIME "text" MUST represent a line break. Use of CR and LF outside of
- line break sequences is also forbidden.
-
- This rule applies regardless of format or character set or sets
- involved.
-
- NOTE: The proper interpretation of line breaks when a body is
- displayed depends on the media type. In particular, while it is
- appropriate to treat a line break as a transition to a new line when
- displaying a "text/plain" body, this treatment is actually incorrect
- for other subtypes of "text" like "text/enriched" [RFC-1896].
- Similarly, whether or not line breaks should be added during display
- operations is also a function of the media type. It should not be
- necessary to add any line breaks to display "text/plain" correctly,
- whereas proper display of "text/enriched" requires the appropriate
- addition of line breaks.
-
- NOTE: Some protocols defines a maximum line length. E.g. SMTP [RFC-
- 821] allows a maximum of 998 octets before the next CRLF sequence.
- To be transported by such protocols, data which includes too long
- segments without CRLF sequences must be encoded with a suitable
- content-transfer-encoding.
-
-4.1.2. 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=iso-8859-1
-
- 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. For other subtypes of "text"
- than "text/plain", the semantics of the "charset" parameter should be
- defined to 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 to the implications of multioctet character sets for their
- subtype definitions.
-
-
-
-Freed & Borenstein Standards Track [Page 7]
-
-RFC 2046 Media Types November 1996
-
-
- The charset parameter for subtypes of "text" gives a name of a
- character set, as "character set" is defined in RFC 2045. The rules
- regarding line breaks detailed in the previous section must also be
- observed -- a character set whose definition does not conform to
- these rules cannot be used in a MIME "text" subtype.
-
- 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.
-
- Other media types than subtypes of "text" might choose to employ the
- charset parameter as defined here, but with the CRLF/line break
- restriction removed. Therefore, all character sets that conform to
- the general definition of "character set" in RFC 2045 can be
- registered for MIME use.
-
- Note that if the specified character set includes 8-bit characters
- and such characters are used in the body, 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 [RFC-821].
-
- 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
- future, it is strongly recommended that new user agents explicitly
- specify a character set as a media type parameter in the Content-Type
- header field. "US-ASCII" does not indicate an arbitrary 7-bit
- character set, but specifies that all octets in the body must be
- interpreted as characters according to the US-ASCII character set.
- National and application-oriented versions of ISO 646 [ISO-646] are
- usually NOT identical to US-ASCII, and in that case their use in
- Internet mail is explicitly discouraged. The omission of the ISO 646
- character set from this document is deliberate in this regard. The
- character set name of "US-ASCII" explicitly refers to the character
- set defined in ANSI X3.4-1986 [US- ASCII]. The new international
- reference version (IRV) of the 1991 edition of ISO 646 is identical
- to US-ASCII. 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 media 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
-
-
-
-Freed & Borenstein Standards Track [Page 8]
-
-RFC 2046 Media Types November 1996
-
-
- messages containing characters coded according to other versions of
- ISO 646 than US-ASCII and the 1991 IRV, or using code-switching
- procedures (e.g., those of ISO 2022), as well as 8bit or multiple
- octet character encodings MUST use an appropriate character set
- specification to be consistent with MIME.
-
- The complete US-ASCII character set is listed in ANSI X3.4- 1986.
- Note that the control characters including DEL (0-31, 127) have no
- defined meaning in apart from the combination CRLF (US-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)." Aside from these
- conventions, any use of the control characters or DEL in a body must
- either occur
-
- (1) because a subtype of text other than "plain"
- specifically assigns some additional meaning, or
-
- (2) within the context 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: An enormous proliferation of character sets exist beyond US-
- ASCII. A large number of partially or totally overlapping character
- sets is NOT a good thing. A SINGLE character set that can be used
- universally for representing all of the world's languages in Internet
- mail would be preferrable. Unfortunately, existing practice in
- several communities seems to point to the continued use of multiple
- character sets in the near future. A small number of standard
- character sets are, therefore, defined for Internet use in this
- document.
-
- The defined charset values are:
-
- (1) US-ASCII -- as defined in ANSI X3.4-1986 [US-ASCII].
-
- (2) 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 10.
-
-
-
-
-Freed & Borenstein Standards Track [Page 9]
-
-RFC 2046 Media Types November 1996
-
-
- Characters in the range 128-159 has no assigned meaning in ISO-8859-
- X. Characters with values below 128 in ISO-8859-X have the same
- assigned meaning as they do in US-ASCII.
-
- Part 6 of ISO 8859 (Latin/Arabic alphabet) and part 8 (Latin/Hebrew
- alphabet) includes both characters for which the normal writing
- direction is right to left and characters for which it is left to
- right, but do not define a canonical ordering method for representing
- bi-directional text. The charset values "ISO-8859-6" and "ISO-8859-
- 8", however, specify that the visual method is used [RFC-1556].
-
- All of these character sets are used as pure 7bit or 8bit sets
- without any shift or escape functions. The meaning of shift and
- escape sequences in these character sets is not defined.
-
- 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.
-
- Note that the character set used, if anything other than US- ASCII,
- must always be explicitly specified in the Content-Type field.
-
- No character set name other than those defined above 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 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, composition software should always use the "lowest common
- denominator" character set possible. For example, if a body contains
- only US-ASCII characters, it SHOULD 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
- should be labelled as being in that subset. This will increase the
- chances that the recipient will be able to view the resulting entity
- correctly.
-
-
-
-Freed & Borenstein Standards Track [Page 10]
-
-RFC 2046 Media Types November 1996
-
-
-4.1.3. Plain Subtype
-
- The simplest and most important subtype of "text" is "plain". This
- indicates plain text that does not contain any formatting commands or
- directives. Plain text is intended to be displayed "as-is", that is,
- no interpretation of embedded formatting commands, font attribute
- specifications, processing instructions, interpretation directives,
- or content markup should be necessary for proper display. The
- default media type of "text/plain; charset=us-ascii" for Internet
- mail 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.
-
-4.1.4. Unrecognized Subtypes
-
- Unrecognized subtypes of "text" should be treated as subtype "plain"
- as long as the MIME implementation knows how to handle the charset.
- Unrecognized subtypes which also specify an unrecognized charset
- should be treated as "application/octet- stream".
-
-4.2. Image Media Type
-
- A media type of "image" indicates that the body contains an image.
- The subtype names the specific image format. These names are not
- case sensitive. An initial subtype is "jpeg" for the JPEG format
- using JFIF encoding [JPEG].
-
- 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 RFC 2048.
-
- Unrecognized subtypes of "image" should at a miniumum be treated as
- "application/octet-stream". Implementations may optionally elect to
- pass subtypes of "image" that they do not specifically recognize to a
- secure and robust general-purpose image viewing application, if such
- an application is available.
-
- NOTE: Using of a generic-purpose image viewing application this way
- inherits the security problems of the most dangerous type supported
- by the application.
-
-4.3. Audio Media Type
-
- A media 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.
-
-
-
-Freed & Borenstein Standards Track [Page 11]
-
-RFC 2046 Media Types November 1996
-
-
- 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 single channel audio
- encoded using 8bit ISDN mu-law [PCM] at a sample rate of 8000 Hz.
-
- Unrecognized subtypes of "audio" should at a miniumum be treated as
- "application/octet-stream". Implementations may optionally elect to
- pass subtypes of "audio" that they do not specifically recognize to a
- robust general-purpose audio playing application, if such an
- application is available.
-
-4.4. Video Media Type
-
- A media type of "video" indicates that the body contains a time-
- varying-picture image, possibly with color and coordinated sound.
- The term 'video' is used in its most generic sense, 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".
-
- Unrecognized subtypes of "video" should at a minumum be treated as
- "application/octet-stream". Implementations may optionally elect to
- pass subtypes of "video" that they do not specifically recognize to a
- robust general-purpose video display application, if such an
- application is available.
-
-4.5. Application Media Type
-
- The "application" media type is to be used for discrete data which do
- not fit in any of the other categories, and particularly for data to
- be processed by some type of application program. This is
- information which must be processed by an application before it is
- viewable or usable by a user. Expected uses for the "application"
- media type include file transfer, spreadsheets, data for mail-based
- scheduling systems, and languages for "active" (computational)
- material. (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" media type.)
-
-
-
-
-Freed & Borenstein Standards Track [Page 12]
-
-RFC 2046 Media Types November 1996
-
-
- 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 additional material based on that
- dialog. More generally, there have been several "active" messaging
- languages developed in which programs in a suitably specialized
- language are transported to a remote location and automatically run
- in the recipient's environment.
-
- Such applications may be defined as subtypes of the "application"
- media type. This document defines two subtypes:
-
- octet-stream, and PostScript.
-
- The subtype of "application" will often be either the name or include
- part of 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".
-
-4.5.1. Octet-Stream Subtype
-
- The "octet-stream" subtype is used to indicate that a body contains
- arbitrary binary data. The set of currently defined parameters is:
-
- (1) TYPE -- the general type or category of binary data.
- This is intended as information for the human recipient
- rather than for any automatic processing.
-
- (2) PADDING -- the number of bits of padding that were
- appended to the bit-stream comprising the actual
- contents to produce the enclosed 8bit 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
- 8.
-
- Both of these parameters are optional.
-
- An additional parameter, "CONVERSIONS", was defined in RFC 1341 but
- has since 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 an
- "application/octet-stream" entity 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.
-
-
-
-Freed & Borenstein Standards Track [Page 13]
-
-RFC 2046 Media Types November 1996
-
-
- To reduce the danger of transmitting rogue programs, 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 message body as input.
-
-4.5.2. PostScript Subtype
-
- A media 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 media type "application/postscript" implies recognition of
- that trademark and all the rights it entails.
-
- The PostScript language definition provides facilities for internal
- labelling of the specific language features a given program uses.
- This labelling, called the PostScript document structuring
- conventions, or DSC, 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 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 by typical printer environments,
- implementors should consider all of the following before they add
- interactive display of PostScript bodies to their MIME readers.
-
- The remainder of this section outlines some, though probably not all,
- of the possible problems with the transport of PostScript entities.
-
- (1) 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.
-
-
-
-Freed & Borenstein Standards Track [Page 14]
-
-RFC 2046 Media Types November 1996
-
-
- 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.
-
- (2) 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 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, since the ability to exit
- will probably be unavailable in secure PostScript
- implementations. Message receiving and displaying
- software should completely disable the ability to make
- retained changes to the PostScript environment by
- eliminating or disabling the "startjob" and
- "exitserver" operations. If these operations cannot be
- eliminated or completely disabled the password
- associated with them should at least be set to a hard-
- to-guess value.
-
- (3) 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
-
-
-
-Freed & Borenstein Standards Track [Page 15]
-
-RFC 2046 Media Types November 1996
-
-
- 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
- disable the ability to change system and device
- parameters. If these operators cannot be completely
- disabled the password associated with them should at
- least be set to a hard-to-guess value.
-
- (4) 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.
-
- (5) 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.
-
- (6) It is possible to write PostScript that consumes huge
- amounts of various system resources. It is also
- possible to write PostScript programs that loop
- indefinitely. Both types of programs have the
- 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 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.
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 16]
-
-RFC 2046 Media Types November 1996
-
-
- (7) It is possible to include raw binary information inside
- PostScript in various forms. This is not recommended
- for use in Internet mail, both because it is not
- supported by all PostScript interpreters and because it
- significantly complicates the use of a MIME Content-
- Transfer-Encoding. (Without such binary, PostScript
- may typically be viewed as line-oriented data. The
- treatment of CRLF sequences becomes extremely
- problematic if binary and line-oriented data are mixed
- in a single Postscript data stream.)
-
- (8) 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.
-
-4.5.3. Other Application Subtypes
-
- It is expected that many other subtypes of "application" will be
- defined in the future. MIME implementations must at a minimum treat
- any unrecognized subtypes as being equivalent to "application/octet-
- stream".
-
-5. Composite Media Type Values
-
- The remaining two of the seven initial Content-Type values refer to
- composite entities. Composite entities are handled using MIME
- mechanisms -- a MIME processor typically handles the body directly.
-
-5.1. Multipart Media Type
-
- In the case of multipart entities, in which one or more different
- sets of data are combined in a single body, a "multipart" media type
- field must appear in the entity's header. The body must then contain
- one or more body parts, each preceded by a boundary delimiter line,
- and the last one followed by a closing boundary delimiter line.
- After its boundary delimiter line, each body part then consists of a
- 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 an entity and hence 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 usually indicates that the corresponding body has
-
-
-
-Freed & Borenstein Standards Track [Page 17]
-
-RFC 2046 Media Types November 1996
-
-
- a content-type of "text/plain; charset=US-ASCII".
-
- The only header fields that have defined meaning for body parts are
- those the names of which begin with "Content-". All other header
- fields may be ignored in body parts. Although they should generally
- be retained if at all possible, 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.
-
- 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 a JPEG image. In order to represent
- the latter, the body part must have "Content-Type: message/rfc822",
- and its body (after the blank line) must be the encapsulated message,
- with its own "Content-Type: image/jpeg" 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 parts
- actually are messages, a "digest" subtype is also defined.)
-
- As stated previously, each body part is preceded by a boundary
- delimiter line that contains the boundary delimiter. The boundary
- delimiter MUST NOT appear inside any of the encapsulated parts, on a
- line by itself or as the prefix of any line. This implies that it is
- crucial that the composing agent be able to choose and specify a
- unique boundary parameter value that does not contain the boundary
- parameter value of an enclosing multipart as a prefix.
-
- 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 those of an
- unrecognized subtype.
-
- As stated in the definition of the Content-Transfer-Encoding field
- [RFC 2045], no encoding other than "7bit", "8bit", or "binary" is
- permitted for entities of type "multipart". The "multipart" boundary
- delimiters and header fields are always represented as 7bit US-ASCII
- in any case (though the header fields may encode non-US-ASCII header
- text as per RFC 2047) 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.
-
-
-
-Freed & Borenstein Standards Track [Page 18]
-
-RFC 2046 Media Types November 1996
-
-
-5.1.1. Common Syntax
-
- This section defines a common syntax for subtypes of "multipart".
- All subtypes of "multipart" must use this syntax. A simple example
- of a multipart message also appears in this section. An example of a
- more complex multipart message is given in RFC 2049.
-
- The Content-Type field for multipart entities requires one parameter,
- "boundary". The boundary delimiter line is then defined as a line
- consisting entirely of two hyphen characters ("-", decimal value 45)
- followed by the boundary parameter value from the Content-Type header
- field, optional linear whitespace, and a terminating CRLF.
-
- 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 boundary
- parameter values 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 invalid
- Content-type fields. Thus, a typical "multipart" Content-Type header
- field might look like this:
-
- Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p
-
- But the following is not valid:
-
- Content-Type: multipart/mixed; boundary=gc0pJq0M:08jU534c0p
-
- (because of the colon) and must instead be represented as
-
- Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p"
-
- This Content-Type value indicates that the content consists of one or
- more parts, each with a structure that is syntactically identical to
- an RFC 822 message, except that the header area is allowed to be
- completely empty, and that the parts are each preceded by the line
-
-
-
-
-Freed & Borenstein Standards Track [Page 19]
-
-RFC 2046 Media Types November 1996
-
-
- --gc0pJq0M:08jU534c0p
-
- The boundary delimiter MUST occur at the beginning of a line, i.e.,
- following a CRLF, and the initial CRLF is considered to be attached
- to the boundary delimiter line rather than part of the preceding
- part. The boundary may be followed by zero or more characters of
- linear whitespace. It is then terminated by either 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. If no Content-Type
- field is present it is assumed to be "message/rfc822" in a
- "multipart/digest" and "text/plain" otherwise.
-
- NOTE: The CRLF preceding the boundary delimiter 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 boundary delimiter line, the first of which is part of
- the preceding body part, and the second of which is part of the
- encapsulation boundary.
-
- Boundary delimiters must not appear within the encapsulated material,
- and must be no longer than 70 characters, not counting the two
- leading hyphens.
-
- The boundary delimiter line following the last body part is a
- distinguished delimiter that indicates that no further body parts
- will follow. Such a delimiter line is identical to the previous
- delimiter lines, with the addition of two more hyphens after the
- boundary parameter value.
-
- --gc0pJq0M:08jU534c0p--
-
- NOTE TO IMPLEMENTORS: Boundary string comparisons must compare the
- boundary value with the beginning of each candidate line. An exact
- match of the entire candidate line is not required; it is sufficient
- that the boundary appear in its entirety following the CRLF.
-
- There appears to be room for additional information prior to the
- first boundary delimiter line and following the final boundary
- delimiter line. These areas should generally be left blank, and
- implementations must ignore anything that appears before the first
- boundary delimiter line 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
-
-
-
-Freed & Borenstein Standards Track [Page 20]
-
-RFC 2046 Media Types November 1996
-
-
- 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 boundary delimiters must not appear in the body parts
- being encapsulated, a user agent must exercise care to choose a
- unique boundary parameter value. The boundary parameter value in the
- example above could have been the result of an algorithm designed to
- produce boundary delimiters with a very low probability of already
- existing in the data to be encapsulated without having to prescan the
- data. Alternate algorithms might result in more "readable" boundary
- delimiters for a recipient with an old user agent, but would require
- more attention to the possibility that the boundary delimiter might
- appear at the beginning of some line in the encapsulated part. The
- simplest boundary delimiter line possible is something like "---",
- with a closing boundary delimiter line 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 <[email protected]>
- To: Ned Freed <[email protected]>
- Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST)
- 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 composition agents to include an
- explanatory note to non-MIME conformant readers.
-
- --simple boundary
-
- This is implicitly typed plain US-ASCII text.
- It does NOT end with a linebreak.
- --simple boundary
- Content-type: text/plain; charset=us-ascii
-
- This is explicitly typed plain US-ASCII text.
- It DOES end with a linebreak.
-
- --simple boundary--
-
- This is the epilogue. It is also to be ignored.
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 21]
-
-RFC 2046 Media Types November 1996
-
-
- The use of a media 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 uses a different boundary delimiter. See RFC 2049 for an
- example of nested "multipart" entities.
-
- The use of the "multipart" media type with only a single body part
- may be useful in certain contexts, and is explicitly permitted.
-
- NOTE: Experience has shown that a "multipart" media type with a
- single body part is useful for sending non-text media types. It has
- the advantage of providing the preamble as a place to include
- decoding instructions. In addition, a number of SMTP gateways move
- or remove the MIME headers, and a clever MIME decoder can take a good
- guess at multipart boundaries even in the absence of the Content-Type
- header and thereby successfully decode the message.
-
- The only mandatory global parameter for the "multipart" media type is
- the boundary parameter, which consists of 1 to 70 characters from a
- set of characters known to be very robust through mail gateways, and
- NOT ending with white space. (If a boundary delimiter line appears to
- end with white space, the white space must be presumed to have been
- added by a gateway, and must be deleted.) It is formally specified
- by the following BNF:
-
- boundary := 0*69<bchars> bcharsnospace
-
- bchars := bcharsnospace / " "
-
- bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
- "+" / "_" / "," / "-" / "." /
- "/" / ":" / "=" / "?"
-
- Overall, the body of a "multipart" entity may be specified as
- follows:
-
- dash-boundary := "--" boundary
- ; boundary taken from the value of
- ; boundary parameter of the
- ; Content-Type field.
-
- multipart-body := [preamble CRLF]
- dash-boundary transport-padding CRLF
- body-part *encapsulation
- close-delimiter transport-padding
- [CRLF epilogue]
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 22]
-
-RFC 2046 Media Types November 1996
-
-
- transport-padding := *LWSP-char
- ; Composers MUST NOT generate
- ; non-zero length transport
- ; padding, but receivers MUST
- ; be able to handle padding
- ; added by message transports.
-
- encapsulation := delimiter transport-padding
- CRLF body-part
-
- delimiter := CRLF dash-boundary
-
- close-delimiter := delimiter "--"
-
- preamble := discard-text
-
- epilogue := discard-text
-
- discard-text := *(*text CRLF) *text
- ; May be ignored or discarded.
-
- body-part := MIME-part-headers [CRLF *OCTET]
- ; Lines in a body-part must not start
- ; with the specified dash-boundary and
- ; the delimiter must not appear anywhere
- ; in the body part. Note that the
- ; semantics of a body-part differ from
- ; the semantics of a message, as
- ; described in the text.
-
- OCTET := <any 0-255 octet value>
-
- IMPORTANT: The free insertion of linear-white-space and RFC 822
- comments between the elements shown in this BNF is NOT allowed since
- this BNF does not specify a structured header field.
-
- NOTE: In certain transport enclaves, RFC 822 restrictions such as
- the one that limits bodies to printable US-ASCII characters may not
- be in force. (That is, the transport domains may exist that resemble
- standard Internet mail transport as specified in RFC 821 and assumed
- by RFC 822, 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
- US-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
- US-ASCII characters.
-
-
-
-Freed & Borenstein Standards Track [Page 23]
-
-RFC 2046 Media Types November 1996
-
-
- NOTE: Conspicuously missing from the "multipart" type is a notion of
- structured, related body parts. It is recommended that those wishing
- to provide more structured or integrated multipart messaging
- facilities should define subtypes of multipart that are syntactically
- identical but define relationships between the various parts. For
- example, subtypes of multipart could be defined that include a
- distinguished part which in turn is used to specify the relationships
- between the other parts, probably referring to them by their
- Content-ID field. Old implementations will not recognize the new
- subtype if this approach is used, but will treat it as
- multipart/mixed and will thus be able to show the user the parts that
- are recognized.
-
-5.1.2. Handling Nested Messages and Multiparts
-
- The "message/rfc822" subtype defined in a subsequent section of this
- document has no terminating condition other than running out of data.
- Similarly, an improperly truncated "multipart" entity may not have
- any terminating boundary marker, and can turn up operationally due to
- mail system malfunctions.
-
- It is essential that such entities be handled correctly when they are
- themselves imbedded inside of another "multipart" structure. MIME
- implementations are therefore required to recognize outer level
- boundary markers at ANY level of inner nesting. It is not sufficient
- to only check for the next expected marker or other terminating
- condition.
-
-5.1.3. Mixed Subtype
-
- The "mixed" subtype of "multipart" 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".
-
-5.1.4. Alternative Subtype
-
- The "multipart/alternative" type is syntactically identical to
- "multipart/mixed", but the semantics are different. In particular,
- each of the body 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 references, 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
-
-
-
-Freed & Borenstein Standards Track [Page 24]
-
-RFC 2046 Media Types November 1996
-
-
- 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 a message
- in a fancy text format in such a way that it can easily be displayed
- anywhere:
-
- From: Nathaniel Borenstein <[email protected]>
- To: Ned Freed <[email protected]>
- Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
- 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/enriched
-
- ... RFC 1896 text/enriched version of same message
- goes here ...
-
- --boundary42
- Content-Type: application/x-whatever
-
- ... fanciest version of same message goes here ...
-
- --boundary42--
-
- In this example, users whose mail systems understood the
- "application/x-whatever" format would see only the fancy version,
- while other users would see only the enriched 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.
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 25]
-
-RFC 2046 Media Types November 1996
-
-
- 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 viewer. While this approach does impose
- some burden on conformant MIME viewers, 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
- which format to view. This makes sense, for example, if a message
- 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.
-
- 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. And when the information
- content is identical -- for example, where several parts of type
- "message/external-body" specify alternate ways to access the
- identical data -- the same Content-ID field value should be used, to
- optimize any caching mechanisms that might be present on the
- recipient's end. However, 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.
-
-5.1.5. 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.
-
- Note: Though it is possible to specify a Content-Type value for a
- body part in a digest which is other than "message/rfc822", such as a
- "text/plain" part containing a description of the material in the
-
-
-
-Freed & Borenstein Standards Track [Page 26]
-
-RFC 2046 Media Types November 1996
-
-
- digest, actually doing so is undesireble. The "multipart/digest"
- Content-Type is intended to be used to send collections of messages.
- If a "text/plain" part is needed, it should be included as a seperate
- part of a "multipart/mixed" message.
-
- A digest in this format might, then, look something like this:
-
- From: Moderator-Address
- To: Recipient-List
- Date: Mon, 22 Mar 1994 13:34:51 +0000
- Subject: Internet Digest, volume 42
- MIME-Version: 1.0
- Content-Type: multipart/mixed;
- boundary="---- main boundary ----"
-
- ------ main boundary ----
-
- ...Introductory text or table of contents...
-
- ------ main boundary ----
- Content-Type: multipart/digest;
- boundary="---- next message ----"
-
- ------ next message ----
-
- From: someone-else
- Date: Fri, 26 Mar 1993 11:13:32 +0200
- Subject: my opinion
-
- ...body goes here ...
-
- ------ next message ----
-
- From: someone-else-again
- Date: Fri, 26 Mar 1993 10:07:13 -0500
- Subject: my different opinion
-
- ... another body goes here ...
-
- ------ next message ------
-
- ------ main boundary ------
-
-5.1.6. 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,
-
-
-
-Freed & Borenstein Standards Track [Page 27]
-
-RFC 2046 Media Types November 1996
-
-
- 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.
-
-5.1.7. 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".
-
-5.2. Message Media Type
-
- It is frequently desirable, in sending mail, to encapsulate another
- mail message. A special media type, "message", is defined to
- facilitate this. In particular, the "rfc822" subtype of "message" is
- used to encapsulate RFC 822 messages.
-
- 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.
-
- Subtypes of "message" often impose restrictions on what encodings are
- allowed. These restrictions are described in conjunction with each
- specific subtype.
-
- 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.
- These operations are explicitly forbidden for the encapsulated
- headers embedded in the bodies of messages of type "message."
-
-5.2.1. RFC822 Subtype
-
- A media 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, the restriction that each
- "message/rfc822" body must include a "From", "Date", and at least one
- destination header is removed and replaced with the requirement that
- at least one of "From", "Subject", or "Date" must be present.
-
-
-
-Freed & Borenstein Standards Track [Page 28]
-
-RFC 2046 Media Types November 1996
-
-
- It should be noted that, despite the use of the numbers "822", a
- "message/rfc822" entity isn't restricted to material in strict
- conformance to RFC822, nor are the semantics of "message/rfc822"
- objects restricted to the semantics defined in RFC822. More
- specifically, a "message/rfc822" message could well be a News article
- or a MIME message.
-
- No encoding other than "7bit", "8bit", or "binary" is permitted for
- the body of a "message/rfc822" entity. 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-US-ASCII text in the
- headers of an encapsulated message can be specified using the
- mechanisms described in RFC 2047.
-
-5.2.2. Partial Subtype
-
- The "partial" subtype is defined to allow large entities to be
- delivered as several separate pieces of mail and automatically
- reassembled by a receiving user agent. (The concept is similar to IP
- fragmentation and 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. The media type
- "message/partial" thus indicates that the body contains a fragment of
- a larger entity.
-
- 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 8bit
- transport. The problem is that the binary data would be split into
- multiple "message/partial" messages, each of them requiring binary
- transport. If such messages were encountered at a gateway into a
- 7bit transport environment, there would be no way to properly encode
- them for the 7bit world, aside from waiting for all of the fragments,
- reassembling the inner message, and then encoding the reassembled
- data in base64 or quoted-printable. Since it is possible that
- different fragments might go through different gateways, even this is
- not an acceptable solution. For this reason, it is specified that
- entities of type "message/partial" must always have a content-
- transfer-encoding of 7bit (the default). In particular, even in
- environments that support binary or 8bit transport, the use of a
- content- transfer-encoding of "8bit" or "binary" is explicitly
- prohibited for MIME entities of type "message/partial". This in turn
- implies that the inner message must not use "8bit" or "binary"
- encoding.
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 29]
-
-RFC 2046 Media Types November 1996
-
-
- Because some message transfer agents may choose to automatically
- fragment large messages, and because such agents may use very
- 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.
-
- 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
- fragments 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 in RFC 2045.) The
- second, "number", an integer, is the fragment number, which indicates
- where this fragment fits into the sequence of fragments. The third,
- "total", another integer, is the total number of fragments. This
- third subfield is required on the final fragment, and is optional
- (though encouraged) on the earlier fragments. Note also that these
- parameters may be given in any order.
-
- Thus, the second piece of a 3-piece message may have either of the
- following header fields:
-
- Content-Type: Message/Partial; number=2; total=3;
- id="[email protected]"
-
- Content-Type: Message/Partial;
- id="[email protected]";
- number=2
-
- But the third piece MUST specify the total number of fragments:
-
- Content-Type: Message/Partial; number=3; total=3;
- id="[email protected]"
-
- Note that fragment numbering begins with 1, not 0.
-
- When the fragments of an entity broken up in this manner are put
- together, the result is always a complete MIME entity, which may have
- its own Content-Type header field, and thus may contain any other
- data type.
-
-5.2.2.1. 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
-
-
-
-Freed & Borenstein Standards Track [Page 30]
-
-RFC 2046 Media Types November 1996
-
-
- message containing an audio message. That is, the encapsulation of
- the message is considered to be "transparent".
-
- When generating and reassembling the pieces 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) Fragmentation agents must split messages at line
- boundaries only. This restriction is imposed because
- splits at points other than the ends of lines in turn
- depends on message transports being able to preserve
- the semantics of messages that don't end with a CRLF
- sequence. Many transports are incapable of preserving
- such semantics.
-
- (2) All of the header fields from the initial enclosing
- message, except those that start with "Content-" and
- the specific header fields "Subject", "Message-ID",
- "Encrypted", and "MIME-Version", must be copied, in
- order, to the new message.
-
- (3) The header fields in the enclosed message which start
- with "Content-", plus the "Subject", "Message-ID",
- "Encrypted", and "MIME-Version" fields, 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 the
- "Subject", "Message-ID", "Encrypted", and "MIME-
- Version" fields) will be ignored and dropped.
-
- (4) All of the header fields from the second and any
- subsequent enclosing messages are discarded by the
- reassembly process.
-
-5.2.2.2. Fragmentation and Reassembly Example
-
- If an audio message is broken into two pieces, the first piece might
- look something like this:
-
- X-Weird-Header-1: Foo
- From: [email protected]
- To: [email protected]
- Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
- Subject: Audio mail (part 1 of 2)
- Message-ID: <[email protected]>
- MIME-Version: 1.0
- Content-type: message/partial; id="[email protected]";
-
-
-
-Freed & Borenstein Standards Track [Page 31]
-
-RFC 2046 Media Types November 1996
-
-
- number=1; total=2
-
- X-Weird-Header-1: Bar
- X-Weird-Header-2: Hello
- Message-ID: <[email protected]>
- Subject: Audio mail
- 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: [email protected]
- To: [email protected]
- Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
- Subject: Audio mail (part 2 of 2)
- MIME-Version: 1.0
- Message-ID: <[email protected]>
- Content-type: message/partial;
- id="[email protected]"; 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: [email protected]
- To: [email protected]
- Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
- Subject: Audio mail
- Message-ID: <[email protected]>
- 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 ...
-
- 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.
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 32]
-
-RFC 2046 Media Types November 1996
-
-
- Finally, it should be noted that the "Encrypted" header field has
- been made obsolete by Privacy Enhanced Messaging (PEM) [RFC-1421,
- RFC-1422, RFC-1423, RFC-1424], but the rules above are nevertheless
- believed to describe the correct way to treat it if it is encountered
- in the context of conversion to and from "message/partial" fragments.
-
-5.2.3. 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 a MIME 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.jpeg"
-
- Content-type: image/jpeg
- Content-ID: <[email protected]>
- Content-Transfer-Encoding: binary
-
- 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". The only access-type defined
- in this document that uses the phantom body is "mail-server", but
- other access-types may be defined in the future in other
- specifications that use this area.
-
- The encapsulated headers in ALL "message/external-body" entities MUST
- include a Content-ID header field to give a unique identifier by
- which to reference the data. This identifier may be used for caching
- 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.
-
-
-
-
-Freed & Borenstein Standards Track [Page 33]
-
-RFC 2046 Media Types November 1996
-
-
- 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", MIME entities of type "message/external-
- body" MUST have a content-transfer-encoding of 7bit (the default).
- In particular, even in environments that support binary or 8bit
- transport, the use of a content- transfer-encoding of "8bit" or
- "binary" is explicitly prohibited for entities of type
- "message/external-body".
-
-5.2.3.1. General External-Body Parameters
-
- The parameters that may be used with any "message/external- body"
- are:
-
- (1) ACCESS-TYPE -- A word indicating the supported access
- mechanism by which the file or data may be obtained.
- This word is not case sensitive. Values include, but
- are not limited to, "FTP", "ANON-FTP", "TFTP", "LOCAL-
- FILE", and "MAIL-SERVER". Future values, except for
- experimental values beginning with "X-", must be
- registered with IANA, as described in RFC 2048.
- This parameter is unconditionally mandatory and MUST be
- present on EVERY "message/external-body".
-
- (2) 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. This parameter may be
- used with ANY access-type and is ALWAYS optional.
-
- (3) 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. This parameter
- may be used with ANY access-type and is ALWAYS
- optional.
-
- (4) 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",
-
-
-
-Freed & Borenstein Standards Track [Page 34]
-
-RFC 2046 Media Types November 1996
-
-
- 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. This
- parameter may be used with ANY access-type and is
- ALWAYS optional.
-
- The precise semantics of the access-types defined here are described
- in the sections that follow.
-
-5.2.3.2. 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:
-
- (1) NAME -- The name of the file that contains the actual
- body data.
-
- (2) 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.
-
- (3) 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:
-
- (1) DIRECTORY -- A directory from which the data named by
- NAME should be retrieved.
-
- (2) MODE -- A case-insensitive string indicating the mode
- to be used when retrieving the information. The valid
- values for access-type "TFTP" are "NETASCII", "OCTET",
- and "MAIL", as specified by the TFTP protocol [RFC-
- 783]. The valid values for access-type "FTP" are
- "ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a
- decimal integer, typically 8. These correspond to the
- 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 and 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.
-
-
-
-Freed & Borenstein Standards Track [Page 35]
-
-RFC 2046 Media Types November 1996
-
-
-5.2.3.3. 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 mail
- address.
-
-5.2.3.4. The 'local-file' Access-Type
-
- An access-type of "local-file" indicates that the actual body is
- accessible as a file on the local machine. Two additional parameters
- are defined for this access type:
-
- (1) NAME -- The name of the file that contains the actual
- body data. This parameter is mandatory for the
- "local-file" access-type.
-
- (2) SITE -- A domain specifier for a machine or set of
- machines that are known to have access to the data
- file. This optional parameter is 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.
- 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.
-
-5.2.3.5. The 'mail-server' Access-Type
-
- The "mail-server" access-type indicates that the actual body is
- available from a mail server. Two additional parameters are defined
- for this access-type:
-
- (1) SERVER -- The addr-spec of the mail server from which
- the actual body data can be obtained. This parameter
- is mandatory for the "mail-server" access-type.
-
- (2) 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. This is an optional
- parameter.
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 36]
-
-RFC 2046 Media Types November 1996
-
-
- 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 in the content-type header field. Instead,
- it is provided as the "phantom body" when the media type is
- "message/external-body" and the access-type is mail-server.
-
- 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.
-
- 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 mail servers must use the same Content-ID field on the returned
- message that was used in the original "message/external-body"
- entities, to facilitate such matching.
-
-5.2.3.6. External-Body Security Issues
-
- "Message/external-body" entities give rise to two important security
- issues:
-
- (1) Accessing data via a "message/external-body" reference
- effectively results in the message recipient performing
- an operation that was specified by the message
- originator. It is therefore possible for the message
- originator to trick a recipient into doing something
- they would not have done otherwise. For example, an
- originator could specify a action that attempts
- retrieval of material that the recipient is not
- authorized to obtain, causing the recipient to
- unwittingly violate some security policy. For this
- reason, user agents capable of resolving external
- references must always take steps to describe the
- action they are to take to the recipient and ask for
- explicit permisssion prior to performing it.
-
- The 'mail-server' access-type is particularly
- vulnerable, in that it causes the recipient to send a
- new message whose contents are specified by the
- original message's originator. Given the potential for
- abuse, any such request messages that are constructed
- should contain a clear indication that they were
- generated automatically (e.g. in a Comments: header
- field) in an attempt to resolve a MIME
-
-
-
-Freed & Borenstein Standards Track [Page 37]
-
-RFC 2046 Media Types November 1996
-
-
- "message/external-body" reference.
-
- (2) MIME will sometimes be used in environments that
- provide some guarantee of message integrity and
- authenticity. If present, such guarantees may apply
- only to the actual direct content of messages -- they
- may or may not apply to data accessed through MIME's
- "message/external-body" mechanism. In particular, it
- may be possible to subvert certain access mechanisms
- even when the messaging system itself is secure.
-
- It should be noted that this problem exists either with
- or without the availabilty of MIME mechanisms. A
- casual reference to an FTP site containing a document
- in the text of a secure message brings up similar
- issues -- the only difference is that MIME provides for
- automatic retrieval of such material, and users may
- place unwarranted trust is such automatic retrieval
- mechanisms.
-
-5.2.3.7. Examples and Further Explanations
-
- When the external-body mechanism is used in conjunction with the
- "multipart/alternative" media type it extends the functionality of
- "multipart/alternative" to include the case where the same entity is
- provided in the same format but via different accces mechanisms.
- When this is done the originator of the message must order the parts
- first in terms of preferred formats and then by preferred access
- mechanisms. The recipient's viewer should then evaluate the list
- both in terms of format and access mechanisms.
-
- 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 entities of type "message/external-body" within the
- body parts of an enclosing "multipart/alternative" entity.
-
- 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.
-
-
-
-
-Freed & Borenstein Standards Track [Page 38]
-
-RFC 2046 Media Types November 1996
-
-
- The embedded message header fields which appear in the body of the
- "message/external-body" data must be used to declare the media type
- of the external body if it is anything other than plain US-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 an object in PostScript
- format, might look like this:
-
- From: Whomever
- To: Someone
- Date: Whenever
- Subject: whatever
- MIME-Version: 1.0
- Message-ID: <[email protected]>
- Content-Type: multipart/alternative; boundary=42
- Content-ID: <[email protected]>
-
- --42
- Content-Type: message/external-body; name="BodyFormats.ps";
- site="thumper.bellcore.com"; mode="image";
- access-type=ANON-FTP; directory="pub";
- expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
-
- Content-type: application/postscript
- Content-ID: <[email protected]>
-
- --42
- Content-Type: message/external-body; access-type=local-file;
- name="/u/nsb/writing/rfcs/RFC-MIME.ps";
- site="thumper.bellcore.com";
- expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
-
- Content-type: application/postscript
- Content-ID: <[email protected]>
-
- --42
- Content-Type: message/external-body;
- access-type=mail-server
- server="[email protected]";
- expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
-
- Content-type: application/postscript
- Content-ID: <[email protected]>
-
- get RFC-MIME.DOC
-
- --42--
-
-
-
-Freed & Borenstein Standards Track [Page 39]
-
-RFC 2046 Media Types November 1996
-
-
- 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" media
- 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 and Subject fields are overridden,
- but the From field is preserved.
-
- Note that since the external bodies are not transported along with
- the external body reference, they need not conform to transport
- limitations that apply to the reference itself. In particular,
- Internet mail transports may impose 7bit and line length limits, but
- these do not automatically apply to binary external body references.
- 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.
-
-5.2.4. Other Message Subtypes
-
- MIME implementations must in general treat unrecognized subtypes of
- "message" as being equivalent to "application/octet-stream".
-
- Future subtypes of "message" intended for use with email should be
- restricted to "7bit" encoding. A type other than "message" should be
- used if restriction to "7bit" is not possible.
-
-6. Experimental Media Type Values
-
- A media type value beginning with the characters "X-" is a private
- value, to be used by consenting systems by mutual agreement. Any
- format without a rigorous and public definition must be named 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. In many cases, a subtype of "application" will be more
- appropriate than a new top-level type.
-
-
-
-
-Freed & Borenstein Standards Track [Page 40]
-
-RFC 2046 Media Types November 1996
-
-
-7. Summary
-
- The five discrete media types provide provide a standardized
- mechanism for tagging entities as "audio", "image", or several other
- kinds of data. The composite "multipart" and "message" media types
- allow mixing and hierarchical structuring of entities of different
- types in a single message. 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 media
- 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 the context of the
- "application/postscript" type, the "message/external-body" type, and
- in RFC 2048. Implementors should pay special attention to the
- security implications of any media types that can cause the remote
- execution of any actions in the recipient's environment. In such
- cases, the discussion of the "application/postscript" type may serve
- as a model for considering other media types with remote execution
- capabilities.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 41]
-
-RFC 2046 Media Types November 1996
-
-
-9. Authors' Addresses
-
- For more information, the authors of this document are best contacted
- via Internet mail:
-
- Ned Freed
- Innosoft International, Inc.
- 1050 East Garvey Avenue South
- West Covina, CA 91790
- USA
-
- Phone: +1 818 919 3600
- Fax: +1 818 919 3614
- EMail: [email protected]
-
-
- Nathaniel S. Borenstein
- First Virtual Holdings
- 25 Washington Avenue
- Morristown, NJ 07960
- USA
-
- Phone: +1 201 540 8967
- Fax: +1 201 993 3032
- EMail: [email protected]
-
-
- MIME is a result of the work of the Internet Engineering Task Force
- Working Group on RFC 822 Extensions. The chairman of that group,
- Greg Vaudreuil, may be reached at:
-
- Gregory M. Vaudreuil
- Octel Network Services
- 17080 Dallas Parkway
- Dallas, TX 75248-1905
- USA
-
- EMail: [email protected]
-
-
-
-
-
-
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 42]
-
-RFC 2046 Media Types November 1996
-
-
-Appendix A -- 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 by name to
- several syntax rules 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.
-
- boundary := 0*69<bchars> bcharsnospace
-
- bchars := bcharsnospace / " "
-
- bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
- "+" / "_" / "," / "-" / "." /
- "/" / ":" / "=" / "?"
-
- body-part := <"message" as defined in RFC 822, with all
- header fields optional, not starting with the
- specified dash-boundary, and with the
- delimiter not occurring anywhere in the
- body part. Note that the semantics of a
- part differ from the semantics of a message,
- as described in the text.>
-
- close-delimiter := delimiter "--"
-
- dash-boundary := "--" boundary
- ; boundary taken from the value of
- ; boundary parameter of the
- ; Content-Type field.
-
- delimiter := CRLF dash-boundary
-
- discard-text := *(*text CRLF)
- ; May be ignored or discarded.
-
- encapsulation := delimiter transport-padding
- CRLF body-part
-
- epilogue := discard-text
-
- multipart-body := [preamble CRLF]
- dash-boundary transport-padding CRLF
- body-part *encapsulation
-
-
-
-Freed & Borenstein Standards Track [Page 43]
-
-RFC 2046 Media Types November 1996
-
-
- close-delimiter transport-padding
- [CRLF epilogue]
-
- preamble := discard-text
-
- transport-padding := *LWSP-char
- ; Composers MUST NOT generate
- ; non-zero length transport
- ; padding, but receivers MUST
- ; be able to handle padding
- ; added by message transports.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 44]
-
diff --git a/doc/rfc/rfc2047.txt b/doc/rfc/rfc2047.txt
deleted file mode 100644
index ff9a744..0000000
--- a/doc/rfc/rfc2047.txt
+++ /dev/null
@@ -1,843 +0,0 @@
-
-
-
-
-
-
-Network Working Group K. Moore
-Request for Comments: 2047 University of Tennessee
-Obsoletes: 1521, 1522, 1590 November 1996
-Category: Standards Track
-
-
- MIME (Multipurpose Internet Mail Extensions) Part Three:
- Message Header Extensions for Non-ASCII Text
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- STD 11, RFC 822, defines a message representation protocol specifying
- considerable detail about US-ASCII message headers, and leaves the
- message content, or message body, as flat US-ASCII text. This set of
- documents, collectively called the Multipurpose Internet Mail
- Extensions, or MIME, redefines the format of messages to allow for
-
- (1) textual message bodies in character sets other than US-ASCII,
-
- (2) an extensible set of different formats for non-textual message
- bodies,
-
- (3) multi-part message bodies, and
-
- (4) textual header information in character sets other than US-ASCII.
-
- These documents are based on earlier work documented in RFC 934, STD
- 11, and RFC 1049, but extends and revises them. Because RFC 822 said
- so little about message bodies, these documents are largely
- orthogonal to (rather than a revision of) RFC 822.
-
- This particular document is the third document in the series. It
- describes extensions to RFC 822 to allow non-US-ASCII text data in
- Internet mail header fields.
-
-
-
-
-
-
-
-
-
-Moore Standards Track [Page 1]
-
-RFC 2047 Message Header Extensions November 1996
-
-
- Other documents in this series include:
-
- + RFC 2045, which specifies the various headers used to describe
- the structure of MIME messages.
-
- + RFC 2046, which defines the general structure of the MIME media
- typing system and defines an initial set of media types,
-
- + RFC 2048, which specifies various IANA registration procedures
- for MIME-related facilities, and
-
- + RFC 2049, which describes MIME conformance criteria and
- provides some illustrative examples of MIME message formats,
- acknowledgements, and the bibliography.
-
- These documents are revisions of RFCs 1521, 1522, and 1590, which
- themselves were revisions of RFCs 1341 and 1342. An appendix in RFC
- 2049 describes differences and changes from previous versions.
-
-1. Introduction
-
- RFC 2045 describes a mechanism for denoting textual body parts which
- are coded in various character sets, as well as methods for encoding
- such body parts as sequences of printable US-ASCII characters. This
- memo describes similar techniques to allow the encoding of non-ASCII
- text in various portions of a RFC 822 [2] message header, in a manner
- which is unlikely to confuse existing message handling software.
-
- Like the encoding techniques described in RFC 2045, the techniques
- outlined here were designed to allow the use of non-ASCII characters
- in message headers in a way which is unlikely to be disturbed by the
- quirks of existing Internet mail handling programs. In particular,
- some mail relaying programs are known to (a) delete some message
- header fields while retaining others, (b) rearrange the order of
- addresses in To or Cc fields, (c) rearrange the (vertical) order of
- header fields, and/or (d) "wrap" message headers at different places
- than those in the original message. In addition, some mail reading
- programs are known to have difficulty correctly parsing message
- headers which, while legal according to RFC 822, make use of
- backslash-quoting to "hide" special characters such as "<", ",", or
- ":", or which exploit other infrequently-used features of that
- specification.
-
- While it is unfortunate that these programs do not correctly
- interpret RFC 822 headers, to "break" these programs would cause
- severe operational problems for the Internet mail system. The
- extensions described in this memo therefore do not rely on little-
- used features of RFC 822.
-
-
-
-Moore Standards Track [Page 2]
-
-RFC 2047 Message Header Extensions November 1996
-
-
- Instead, certain sequences of "ordinary" printable ASCII characters
- (known as "encoded-words") are reserved for use as encoded data. The
- syntax of encoded-words is such that they are unlikely to
- "accidentally" appear as normal text in message headers.
- Furthermore, the characters used in encoded-words are restricted to
- those which do not have special meanings in the context in which the
- encoded-word appears.
-
- Generally, an "encoded-word" is a sequence of printable ASCII
- characters that begins with "=?", ends with "?=", and has two "?"s in
- between. It specifies a character set and an encoding method, and
- also includes the original text encoded as graphic ASCII characters,
- according to the rules for that encoding method.
-
- A mail composer that implements this specification will provide a
- means of inputting non-ASCII text in header fields, but will
- translate these fields (or appropriate portions of these fields) into
- encoded-words before inserting them into the message header.
-
- A mail reader that implements this specification will recognize
- encoded-words when they appear in certain portions of the message
- header. Instead of displaying the encoded-word "as is", it will
- reverse the encoding and display the original text in the designated
- character set.
-
-NOTES
-
- This memo relies heavily on notation and terms defined RFC 822 and
- RFC 2045. In particular, the syntax for the ABNF used in this memo
- is defined in RFC 822, as well as many of the terminal or nonterminal
- symbols from RFC 822 are used in the grammar for the header
- extensions defined here. Among the symbols defined in RFC 822 and
- referenced in this memo are: 'addr-spec', 'atom', 'CHAR', 'comment',
- 'CTLs', 'ctext', 'linear-white-space', 'phrase', 'quoted-pair'.
- 'quoted-string', 'SPACE', and 'word'. Successful implementation of
- this protocol extension requires careful attention to the RFC 822
- definitions of these terms.
-
- When the term "ASCII" appears in this memo, it refers to the "7-Bit
- American Standard Code for Information Interchange", ANSI X3.4-1986.
- The MIME charset name for this character set is "US-ASCII". When not
- specifically referring to the MIME charset name, this document uses
- the term "ASCII", both for brevity and for consistency with RFC 822.
- However, implementors are warned that the character set name must be
- spelled "US-ASCII" in MIME message and body part headers.
-
-
-
-
-
-
-Moore Standards Track [Page 3]
-
-RFC 2047 Message Header Extensions November 1996
-
-
- This memo specifies a protocol for the representation of non-ASCII
- text in message headers. It specifically DOES NOT define any
- translation between "8-bit headers" and pure ASCII headers, nor is
- any such translation assumed to be possible.
-
-2. Syntax of encoded-words
-
- An 'encoded-word' is defined by the following ABNF grammar. The
- notation of RFC 822 is used, with the exception that white space
- characters MUST NOT appear between components of an 'encoded-word'.
-
- encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
-
- charset = token ; see section 3
-
- encoding = token ; see section 4
-
- token = 1*<Any CHAR except SPACE, CTLs, and especials>
-
- especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
- <"> / "/" / "[" / "]" / "?" / "." / "="
-
- encoded-text = 1*<Any printable ASCII character other than "?"
- or SPACE>
- ; (but see "Use of encoded-words in message
- ; headers", section 5)
-
- Both 'encoding' and 'charset' names are case-independent. Thus the
- charset name "ISO-8859-1" is equivalent to "iso-8859-1", and the
- encoding named "Q" may be spelled either "Q" or "q".
-
- An 'encoded-word' may not be more than 75 characters long, including
- 'charset', 'encoding', 'encoded-text', and delimiters. If it is
- desirable to encode more text than will fit in an 'encoded-word' of
- 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
- be used.
-
- While there is no limit to the length of a multiple-line header
- field, each line of a header field that contains one or more
- 'encoded-word's is limited to 76 characters.
-
- The length restrictions are included both to ease interoperability
- through internetwork mail gateways, and to impose a limit on the
- amount of lookahead a header parser must employ (while looking for a
- final ?= delimiter) before it can decide whether a token is an
- "encoded-word" or something else.
-
-
-
-
-
-Moore Standards Track [Page 4]
-
-RFC 2047 Message Header Extensions November 1996
-
-
- IMPORTANT: 'encoded-word's are designed to be recognized as 'atom's
- by an RFC 822 parser. As a consequence, unencoded white space
- characters (such as SPACE and HTAB) are FORBIDDEN within an
- 'encoded-word'. For example, the character sequence
-
- =?iso-8859-1?q?this is some text?=
-
- would be parsed as four 'atom's, rather than as a single 'atom' (by
- an RFC 822 parser) or 'encoded-word' (by a parser which understands
- 'encoded-words'). The correct way to encode the string "this is some
- text" is to encode the SPACE characters as well, e.g.
-
- =?iso-8859-1?q?this=20is=20some=20text?=
-
- The characters which may appear in 'encoded-text' are further
- restricted by the rules in section 5.
-
-3. Character sets
-
- The 'charset' portion of an 'encoded-word' specifies the character
- set associated with the unencoded text. A 'charset' can be any of
- the character set names allowed in an MIME "charset" parameter of a
- "text/plain" body part, or any character set name registered with
- IANA for use with the MIME text/plain content-type.
-
- Some character sets use code-switching techniques to switch between
- "ASCII mode" and other modes. If unencoded text in an 'encoded-word'
- contains a sequence which causes the charset interpreter to switch
- out of ASCII mode, it MUST contain additional control codes such that
- ASCII mode is again selected at the end of the 'encoded-word'. (This
- rule applies separately to each 'encoded-word', including adjacent
- 'encoded-word's within a single header field.)
-
- When there is a possibility of using more than one character set to
- represent the text in an 'encoded-word', and in the absence of
- private agreements between sender and recipients of a message, it is
- recommended that members of the ISO-8859-* series be used in
- preference to other character sets.
-
-4. Encodings
-
- Initially, the legal values for "encoding" are "Q" and "B". These
- encodings are described below. The "Q" encoding is recommended for
- use when most of the characters to be encoded are in the ASCII
- character set; otherwise, the "B" encoding should be used.
- Nevertheless, a mail reader which claims to recognize 'encoded-word's
- MUST be able to accept either encoding for any character set which it
- supports.
-
-
-
-Moore Standards Track [Page 5]
-
-RFC 2047 Message Header Extensions November 1996
-
-
- Only a subset of the printable ASCII characters may be used in
- 'encoded-text'. Space and tab characters are not allowed, so that
- the beginning and end of an 'encoded-word' are obvious. The "?"
- character is used within an 'encoded-word' to separate the various
- portions of the 'encoded-word' from one another, and thus cannot
- appear in the 'encoded-text' portion. Other characters are also
- illegal in certain contexts. For example, an 'encoded-word' in a
- 'phrase' preceding an address in a From header field may not contain
- any of the "specials" defined in RFC 822. Finally, certain other
- characters are disallowed in some contexts, to ensure reliability for
- messages that pass through internetwork mail gateways.
-
- The "B" encoding automatically meets these requirements. The "Q"
- encoding allows a wide range of printable characters to be used in
- non-critical locations in the message header (e.g., Subject), with
- fewer characters available for use in other locations.
-
-4.1. The "B" encoding
-
- The "B" encoding is identical to the "BASE64" encoding defined by RFC
- 2045.
-
-4.2. The "Q" encoding
-
- The "Q" encoding is similar to the "Quoted-Printable" content-
- transfer-encoding defined in RFC 2045. It is designed to allow text
- containing mostly ASCII characters to be decipherable on an ASCII
- terminal without decoding.
-
- (1) Any 8-bit value may be represented by a "=" followed by two
- hexadecimal digits. For example, if the character set in use
- were ISO-8859-1, the "=" character would thus be encoded as
- "=3D", and a SPACE by "=20". (Upper case should be used for
- hexadecimal digits "A" through "F".)
-
- (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be
- represented as "_" (underscore, ASCII 95.). (This character may
- not pass through some internetwork mail gateways, but its use
- will greatly enhance readability of "Q" encoded data with mail
- readers that do not support this encoding.) Note that the "_"
- always represents hexadecimal 20, even if the SPACE character
- occupies a different code position in the character set in use.
-
- (3) 8-bit values which correspond to printable ASCII characters other
- than "=", "?", and "_" (underscore), MAY be represented as those
- characters. (But see section 5 for restrictions.) In
- particular, SPACE and TAB MUST NOT be represented as themselves
- within encoded words.
-
-
-
-Moore Standards Track [Page 6]
-
-RFC 2047 Message Header Extensions November 1996
-
-
-5. Use of encoded-words in message headers
-
- An 'encoded-word' may appear in a message header or body part header
- according to the following rules:
-
-(1) An 'encoded-word' may replace a 'text' token (as defined by RFC 822)
- in any Subject or Comments header field, any extension message
- header field, or any MIME body part field for which the field body
- is defined as '*text'. An 'encoded-word' may also appear in any
- user-defined ("X-") message or body part header field.
-
- Ordinary ASCII text and 'encoded-word's may appear together in the
- same header field. However, an 'encoded-word' that appears in a
- header field defined as '*text' MUST be separated from any adjacent
- 'encoded-word' or 'text' by 'linear-white-space'.
-
-(2) An 'encoded-word' may appear within a 'comment' delimited by "(" and
- ")", i.e., wherever a 'ctext' is allowed. More precisely, the RFC
- 822 ABNF definition for 'comment' is amended as follows:
-
- comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"
-
- A "Q"-encoded 'encoded-word' which appears in a 'comment' MUST NOT
- contain the characters "(", ")" or "
- 'encoded-word' that appears in a 'comment' MUST be separated from
- any adjacent 'encoded-word' or 'ctext' by 'linear-white-space'.
-
- It is important to note that 'comment's are only recognized inside
- "structured" field bodies. In fields whose bodies are defined as
- '*text', "(" and ")" are treated as ordinary characters rather than
- comment delimiters, and rule (1) of this section applies. (See RFC
- 822, sections 3.1.2 and 3.1.3)
-
-(3) As a replacement for a 'word' entity within a 'phrase', for example,
- one that precedes an address in a From, To, or Cc header. The ABNF
- definition for 'phrase' from RFC 822 thus becomes:
-
- phrase = 1*( encoded-word / word )
-
- In this case the set of characters that may be used in a "Q"-encoded
- 'encoded-word' is restricted to: <upper and lower case ASCII
- letters, decimal digits, "!", "*", "+", "-", "/", "=", and "_"
- (underscore, ASCII 95.)>. An 'encoded-word' that appears within a
- 'phrase' MUST be separated from any adjacent 'word', 'text' or
- 'special' by 'linear-white-space'.
-
-
-
-
-
-
-Moore Standards Track [Page 7]
-
-RFC 2047 Message Header Extensions November 1996
-
-
- These are the ONLY locations where an 'encoded-word' may appear. In
- particular:
-
- + An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec'.
-
- + An 'encoded-word' MUST NOT appear within a 'quoted-string'.
-
- + An 'encoded-word' MUST NOT be used in a Received header field.
-
- + An 'encoded-word' MUST NOT be used in parameter of a MIME
- Content-Type or Content-Disposition field, or in any structured
- field body except within a 'comment' or 'phrase'.
-
- The 'encoded-text' in an 'encoded-word' must be self-contained;
- 'encoded-text' MUST NOT be continued from one 'encoded-word' to
- another. This implies that the 'encoded-text' portion of a "B"
- 'encoded-word' will be a multiple of 4 characters long; for a "Q"
- 'encoded-word', any "=" character that appears in the 'encoded-text'
- portion will be followed by two hexadecimal characters.
-
- Each 'encoded-word' MUST encode an integral number of octets. The
- 'encoded-text' in each 'encoded-word' must be well-formed according
- to the encoding specified; the 'encoded-text' may not be continued in
- the next 'encoded-word'. (For example, "=?charset?Q?=?=
- =?charset?Q?AB?=" would be illegal, because the two hex digits "AB"
- must follow the "=" in the same 'encoded-word'.)
-
- Each 'encoded-word' MUST represent an integral number of characters.
- A multi-octet character may not be split across adjacent 'encoded-
- word's.
-
- Only printable and white space character data should be encoded using
- this scheme. However, since these encoding schemes allow the
- encoding of arbitrary octet values, mail readers that implement this
- decoding should also ensure that display of the decoded data on the
- recipient's terminal will not cause unwanted side-effects.
-
- Use of these methods to encode non-textual data (e.g., pictures or
- sounds) is not defined by this memo. Use of 'encoded-word's to
- represent strings of purely ASCII characters is allowed, but
- discouraged. In rare cases it may be necessary to encode ordinary
- text that looks like an 'encoded-word'.
-
-
-
-
-
-
-
-
-
-Moore Standards Track [Page 8]
-
-RFC 2047 Message Header Extensions November 1996
-
-
-6. Support of 'encoded-word's by mail readers
-
-6.1. Recognition of 'encoded-word's in message headers
-
- A mail reader must parse the message and body part headers according
- to the rules in RFC 822 to correctly recognize 'encoded-word's.
-
- 'encoded-word's are to be recognized as follows:
-
- (1) Any message or body part header field defined as '*text', or any
- user-defined header field, should be parsed as follows: Beginning
- at the start of the field-body and immediately following each
- occurrence of 'linear-white-space', each sequence of up to 75
- printable characters (not containing any 'linear-white-space')
- should be examined to see if it is an 'encoded-word' according to
- the syntax rules in section 2. Any other sequence of printable
- characters should be treated as ordinary ASCII text.
-
- (2) Any header field not defined as '*text' should be parsed
- according to the syntax rules for that header field. However,
- any 'word' that appears within a 'phrase' should be treated as an
- 'encoded-word' if it meets the syntax rules in section 2.
- Otherwise it should be treated as an ordinary 'word'.
-
- (3) Within a 'comment', any sequence of up to 75 printable characters
- (not containing 'linear-white-space'), that meets the syntax
- rules in section 2, should be treated as an 'encoded-word'.
- Otherwise it should be treated as normal comment text.
-
- (4) A MIME-Version header field is NOT required to be present for
- 'encoded-word's to be interpreted according to this
- specification. One reason for this is that the mail reader is
- not expected to parse the entire message header before displaying
- lines that may contain 'encoded-word's.
-
-6.2. Display of 'encoded-word's
-
- Any 'encoded-word's so recognized are decoded, and if possible, the
- resulting unencoded text is displayed in the original character set.
-
- NOTE: Decoding and display of encoded-words occurs *after* a
- structured field body is parsed into tokens. It is therefore
- possible to hide 'special' characters in encoded-words which, when
- displayed, will be indistinguishable from 'special' characters in the
- surrounding text. For this and other reasons, it is NOT generally
- possible to translate a message header containing 'encoded-word's to
- an unencoded form which can be parsed by an RFC 822 mail reader.
-
-
-
-
-Moore Standards Track [Page 9]
-
-RFC 2047 Message Header Extensions November 1996
-
-
- When displaying a particular header field that contains multiple
- 'encoded-word's, any 'linear-white-space' that separates a pair of
- adjacent 'encoded-word's is ignored. (This is to allow the use of
- multiple 'encoded-word's to represent long strings of unencoded text,
- without having to separate 'encoded-word's where spaces occur in the
- unencoded text.)
-
- In the event other encodings are defined in the future, and the mail
- reader does not support the encoding used, it may either (a) display
- the 'encoded-word' as ordinary text, or (b) substitute an appropriate
- message indicating that the text could not be decoded.
-
- If the mail reader does not support the character set used, it may
- (a) display the 'encoded-word' as ordinary text (i.e., as it appears
- in the header), (b) make a "best effort" to display using such
- characters as are available, or (c) substitute an appropriate message
- indicating that the decoded text could not be displayed.
-
- If the character set being used employs code-switching techniques,
- display of the encoded text implicitly begins in "ASCII mode". In
- addition, the mail reader must ensure that the output device is once
- again in "ASCII mode" after the 'encoded-word' is displayed.
-
-6.3. Mail reader handling of incorrectly formed 'encoded-word's
-
- It is possible that an 'encoded-word' that is legal according to the
- syntax defined in section 2, is incorrectly formed according to the
- rules for the encoding being used. For example:
-
- (1) An 'encoded-word' which contains characters which are not legal
- for a particular encoding (for example, a "-" in the "B"
- encoding, or a SPACE or HTAB in either the "B" or "Q" encoding),
- is incorrectly formed.
-
- (2) Any 'encoded-word' which encodes a non-integral number of
- characters or octets is incorrectly formed.
-
- A mail reader need not attempt to display the text associated with an
- 'encoded-word' that is incorrectly formed. However, a mail reader
- MUST NOT prevent the display or handling of a message because an
- 'encoded-word' is incorrectly formed.
-
-7. Conformance
-
- A mail composing program claiming compliance with this specification
- MUST ensure that any string of non-white-space printable ASCII
- characters within a '*text' or '*ctext' that begins with "=?" and
- ends with "?=" be a valid 'encoded-word'. ("begins" means: at the
-
-
-
-Moore Standards Track [Page 10]
-
-RFC 2047 Message Header Extensions November 1996
-
-
- start of the field-body, immediately following 'linear-white-space',
- or immediately following a "(" for an 'encoded-word' within '*ctext';
- "ends" means: at the end of the field-body, immediately preceding
- 'linear-white-space', or immediately preceding a ")" for an
- 'encoded-word' within '*ctext'.) In addition, any 'word' within a
- 'phrase' that begins with "=?" and ends with "?=" must be a valid
- 'encoded-word'.
-
- A mail reading program claiming compliance with this specification
- must be able to distinguish 'encoded-word's from 'text', 'ctext', or
- 'word's, according to the rules in section 6, anytime they appear in
- appropriate places in message headers. It must support both the "B"
- and "Q" encodings for any character set which it supports. The
- program must be able to display the unencoded text if the character
- set is "US-ASCII". For the ISO-8859-* character sets, the mail
- reading program must at least be able to display the characters which
- are also in the ASCII set.
-
-8. Examples
-
- The following are examples of message headers containing 'encoded-
- word's:
-
- From: =?US-ASCII?Q?Keith_Moore?= <[email protected]>
- To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <[email protected]>
- CC: =?ISO-8859-1?Q?Andr=E9?= Pirard <[email protected]>
- Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
- =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=
-
- Note: In the first 'encoded-word' of the Subject field above, the
- last "=" at the end of the 'encoded-text' is necessary because each
- 'encoded-word' must be self-contained (the "=" character completes a
- group of 4 base64 characters representing 2 octets). An additional
- octet could have been encoded in the first 'encoded-word' (so that
- the encoded-word would contain an exact multiple of 3 encoded
- octets), except that the second 'encoded-word' uses a different
- 'charset' than the first one.
-
- From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= <[email protected]>
- To: [email protected], [email protected]
- Subject: Time for ISO 10646?
-
- To: Dave Crocker <[email protected]>
- Cc: [email protected], [email protected]
- From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email protected]>
- Subject: Re: RFC-HDR care and feeding
-
-
-
-
-
-Moore Standards Track [Page 11]
-
-RFC 2047 Message Header Extensions November 1996
-
-
- From: Nathaniel Borenstein <[email protected]>
- (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=)
- To: Greg Vaudreuil <[email protected]>, Ned Freed
- <[email protected]>, Keith Moore <[email protected]>
- Subject: Test of new header generator
- MIME-Version: 1.0
- Content-type: text/plain; charset=ISO-8859-1
-
- The following examples illustrate how text containing 'encoded-word's
- which appear in a structured field body. The rules are slightly
- different for fields defined as '*text' because "(" and ")" are not
- recognized as 'comment' delimiters. [Section 5, paragraph (1)].
-
- In each of the following examples, if the same sequence were to occur
- in a '*text' field, the "displayed as" form would NOT be treated as
- encoded words, but be identical to the "encoded form". This is
- because each of the encoded-words in the following examples is
- adjacent to a "(" or ")" character.
-
- encoded form displayed as
- ---------------------------------------------------------------------
- (=?ISO-8859-1?Q?a?=) (a)
-
- (=?ISO-8859-1?Q?a?= b) (a b)
-
- Within a 'comment', white space MUST appear between an
- 'encoded-word' and surrounding text. [Section 5,
- paragraph (2)]. However, white space is not needed between
- the initial "(" that begins the 'comment', and the
- 'encoded-word'.
-
-
- (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab)
-
- White space between adjacent 'encoded-word's is not
- displayed.
-
- (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab)
-
- Even multiple SPACEs between 'encoded-word's are ignored
- for the purpose of display.
-
- (=?ISO-8859-1?Q?a?= (ab)
- =?ISO-8859-1?Q?b?=)
-
- Any amount of linear-space-white between 'encoded-word's,
- even if it includes a CRLF followed by one or more SPACEs,
- is ignored for the purposes of display.
-
-
-
-Moore Standards Track [Page 12]
-
-RFC 2047 Message Header Extensions November 1996
-
-
- (=?ISO-8859-1?Q?a_b?=) (a b)
-
- In order to cause a SPACE to be displayed within a portion
- of encoded text, the SPACE MUST be encoded as part of the
- 'encoded-word'.
-
- (=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=) (a b)
-
- In order to cause a SPACE to be displayed between two strings
- of encoded text, the SPACE MAY be encoded as part of one of
- the 'encoded-word's.
-
-9. References
-
- [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text
- Messages", STD 11, RFC 822, UDEL, August 1982.
-
- [RFC 2049] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
- Extensions (MIME) Part Five: Conformance Criteria and Examples",
- RFC 2049, November 1996.
-
- [RFC 2045] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message Bodies",
- RFC 2045, November 1996.
-
- [RFC 2046] Borenstein N., and N. Freed, "Multipurpose Internet Mail
- Extensions (MIME) Part Two: Media Types", RFC 2046,
- November 1996.
-
- [RFC 2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
- Internet Mail Extensions (MIME) Part Four: Registration
- Procedures", RFC 2048, November 1996.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Moore Standards Track [Page 13]
-
-RFC 2047 Message Header Extensions November 1996
-
-
-10. Security Considerations
-
- Security issues are not discussed in this memo.
-
-11. Acknowledgements
-
- The author wishes to thank Nathaniel Borenstein, Issac Chan, Lutz
- Donnerhacke, Paul Eggert, Ned Freed, Andreas M. Kirchwitz, Olle
- Jarnefors, Mike Rosin, Yutaka Sato, Bart Schaefer, and Kazuhiko
- Yamamoto, for their helpful advice, insightful comments, and
- illuminating questions in response to earlier versions of this
- specification.
-
-12. Author's Address
-
- Keith Moore
- University of Tennessee
- 107 Ayres Hall
- Knoxville TN 37996-1301
-
- EMail: [email protected]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Moore Standards Track [Page 14]
-
-RFC 2047 Message Header Extensions November 1996
-
-
-Appendix - changes since RFC 1522 (in no particular order)
-
- + explicitly state that the MIME-Version is not requried to use
- 'encoded-word's.
-
- + add explicit note that SPACEs and TABs are not allowed within
- 'encoded-word's, explaining that an 'encoded-word' must look like an
- 'atom' to an RFC822 parser.values, to be precise).
-
- + add examples from Olle Jarnefors (thanks!) which illustrate how
- encoded-words with adjacent linear-white-space are displayed.
-
- + explicitly list terms defined in RFC822 and referenced in this memo
-
- + fix transcription typos that caused one or two lines and a couple of
- characters to disappear in the resulting text, due to nroff quirks.
-
- + clarify that encoded-words are allowed in '*text' fields in both
- RFC822 headers and MIME body part headers, but NOT as parameter
- values.
-
- + clarify the requirement to switch back to ASCII within the encoded
- portion of an 'encoded-word', for any charset that uses code switching
- sequences.
-
- + add a note about 'encoded-word's being delimited by "(" and ")"
- within a comment, but not in a *text (how bizarre!).
-
- + fix the Andre Pirard example to get rid of the trailing "_" after
- the =E9. (no longer needed post-1342).
-
- + clarification: an 'encoded-word' may appear immediately following
- the initial "(" or immediately before the final ")" that delimits a
- comment, not just adjacent to "(" and ")" *within* *ctext.
-
- + add a note to explain that a "B" 'encoded-word' will always have a
- multiple of 4 characters in the 'encoded-text' portion.
-
- + add note about the "=" in the examples
-
- + note that processing of 'encoded-word's occurs *after* parsing, and
- some of the implications thereof.
-
- + explicitly state that you can't expect to translate between
- 1522 and either vanilla 822 or so-called "8-bit headers".
-
- + explicitly state that 'encoded-word's are not valid within a
- 'quoted-string'.
-
-
-
-Moore Standards Track [Page 15]
-
diff --git a/doc/rfc/rfc2049.txt b/doc/rfc/rfc2049.txt
deleted file mode 100644
index 99f174b..0000000
--- a/doc/rfc/rfc2049.txt
+++ /dev/null
@@ -1,1347 +0,0 @@
-
-
-
-
-
-
-Network Working Group N. Freed
-Request for Comments: 2049 Innosoft
-Obsoletes: 1521, 1522, 1590 N. Borenstein
-Category: Standards Track First Virtual
- November 1996
-
-
- Multipurpose Internet Mail Extensions
- (MIME) Part Five:
- Conformance Criteria and Examples
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- STD 11, RFC 822, defines a message representation protocol specifying
- considerable detail about US-ASCII message headers, and leaves the
- message content, or message body, as flat US-ASCII text. This set of
- documents, collectively called the Multipurpose Internet Mail
- Extensions, or MIME, redefines the format of messages to allow for
-
- (1) textual message bodies in character sets other than
- US-ASCII,
-
- (2) an extensible set of different formats for non-textual
- message bodies,
-
- (3) multi-part message bodies, and
-
- (4) textual header information in character sets other than
- US-ASCII.
-
- These documents are based on earlier work documented in RFC 934, STD
- 11, and RFC 1049, but extends and revises them. Because RFC 822 said
- so little about message bodies, these documents are largely
- orthogonal to (rather than a revision of) RFC 822.
-
- The initial document in this set, RFC 2045, specifies the various
- headers used to describe the structure of MIME messages. The second
- document defines the general structure of the MIME media typing
- system and defines an initial set of media types. The third
- document, RFC 2047, describes extensions to RFC 822 to allow non-US-
-
-
-
-Freed & Borenstein Standards Track [Page 1]
-
-RFC 2049 MIME Conformance November 1996
-
-
- ASCII text data in Internet mail header fields. The fourth document,
- RFC 2048, specifies various IANA registration procedures for MIME-
- related facilities. This fifth and final document describes MIME
- conformance criteria as well as providing some illustrative examples
- of MIME message formats, acknowledgements, and the bibliography.
-
- These documents are revisions of RFCs 1521, 1522, and 1590, which
- themselves were revisions of RFCs 1341 and 1342. Appendix B of this
- document describes differences and changes from previous versions.
-
-Table of Contents
-
- 1. Introduction .......................................... 2
- 2. MIME Conformance ...................................... 2
- 3. Guidelines for Sending Email Data ..................... 6
- 4. Canonical Encoding Model .............................. 9
- 5. Summary ............................................... 12
- 6. Security Considerations ............................... 12
- 7. Authors' Addresses .................................... 12
- 8. Acknowledgements ...................................... 13
- A. A Complex Multipart Example ........................... 15
- B. Changes from RFC 1521, 1522, and 1590 ................. 16
- C. References ............................................ 20
-
-1. Introduction
-
- The first and second documents in this set define MIME header fields
- and the initial set of MIME media types. The third document
- describes extensions to RFC822 formats to allow for character sets
- other than US-ASCII. This document describes what portions of MIME
- must be supported by a conformant MIME implementation. It also
- describes various pitfalls of contemporary messaging systems as well
- as the canonical encoding model MIME is based on.
-
-2. MIME Conformance
-
- The mechanisms described in these documents are open-ended. It is
- definitely not expected that all implementations will support all
- available media types, 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.
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 2]
-
-RFC 2049 MIME Conformance November 1996
-
-
- A mail user agent that is MIME-conformant MUST:
-
- (1) Always generate a "MIME-Version: 1.0" header field in
- any message it creates.
-
- (2) Recognize the Content-Transfer-Encoding header field
- and decode all received data encoded by either quoted-
- printable or base64 implementations. The identity
- transformations 7bit, 8bit, and binary must also be
- recognized.
-
- Any non-7bit data that is sent without encoding must be
- properly labelled with a content-transfer-encoding of
- 8bit or binary, as appropriate. If the underlying
- transport does not support 8bit or binary (as SMTP
- [RFC-821] does not), the sender is required to both
- encode and label data using an appropriate Content-
- Transfer-Encoding such as quoted-printable or base64.
-
- (3) Must treat any unrecognized Content-Transfer-Encoding
- as if it had a Content-Type of "application/octet-
- stream", regardless of whether or not the actual
- Content-Type is recognized.
-
- (4) Recognize and interpret the Content-Type header field,
- and avoid showing users raw data with a Content-Type
- field other than text. Implementations must be able
- to send at least text/plain messages, with the
- character set specified with the charset parameter if
- it is not US-ASCII.
-
- (5) Ignore any content type parameters whose names they do
- not recognize.
-
- (6) Explicitly handle the following media 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.
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 3]
-
-RFC 2049 MIME Conformance November 1996
-
-
- -- 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 1-127.
-
- -- For unrecognized subtypes in a known character
- set, show or offer to show the user the "raw" version
- of the data after conversion of the content from
- canonical form to local form.
-
- -- Treat material in an unknown character set as if
- it were "application/octet-stream".
-
- Image, audio, and video:
-
- -- At a minumum provide facilities to treat any
- unrecognized subtypes as if they were
- "application/octet-stream".
-
- Application:
-
- -- Offer the ability to remove either of the quoted-
- printable or base64 encodings defined in this
- document if they were used and put the resulting
- information in a user file.
-
- Multipart:
-
- -- Recognize the 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.
-
- -- Recognize the "multipart/digest" subtype,
- specifically using "message/rfc822" rather than
- "text/plain" as the default media type for body parts
- inside "multipart/digest" entities.
-
- -- Treat any unrecognized subtypes as if they were
- "mixed".
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 4]
-
-RFC 2049 MIME Conformance November 1996
-
-
- Message:
-
- -- Recognize and display at least the RFC822 message
- encapsulation (message/rfc822) in such a way as to
- preserve any recursive structure, that is, displaying
- or offering to display the encapsulated data in
- accordance with its media type.
-
- -- Treat any unrecognized subtypes as if they were
- "application/octet-stream".
-
- (7) Upon encountering any unrecognized Content-Type field,
- an implementation must treat it as if it had a media
- 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.
-
- (8) Conformant user agents are required, if they provide
- non-standard support for non-MIME messages employing
- character sets other than US-ASCII, to do so on
- received messages only. Conforming user agents must not
- send non-MIME messages containing anything other than
- US-ASCII text.
-
- In particular, the use of non-US-ASCII text in mail
- messages without a MIME-Version field is strongly
- discouraged as it impedes interoperability when sending
- messages between regions with different localization
- conventions. Conforming user agents MUST include proper
- MIME labelling when sending anything other than plain
- text in the US-ASCII character set.
-
- In addition, non-MIME user agents should be upgraded if
- at all possible to include appropriate MIME header
- information in the messages they send even if nothing
- else in MIME is supported. This upgrade will have
- little, if any, effect on non-MIME recipients and will
- aid MIME in correctly displaying such messages. It
- also provides a smooth transition path to eventual
- adoption of other MIME capabilities.
-
- (9) Conforming user agents must ensure that any string of
- non-white-space printable US-ASCII characters within a
- "*text" or "*ctext" that begins with "=?" and ends with
-
-
-
-Freed & Borenstein Standards Track [Page 5]
-
-RFC 2049 MIME Conformance November 1996
-
-
- "?=" be a valid encoded-word. ("begins" means: At the
- start of the field-body or immediately following
- linear-white-space; "ends" means: At the end of the
- field-body or immediately preceding linear-white-
- space.) In addition, any "word" within a "phrase" that
- begins with "=?" and ends with "?=" must be a valid
- encoded-word.
-
- (10) Conforming user agents must be able to distinguish
- encoded-words from "text", "ctext", or "word"s,
- according to the rules in section 4, anytime they
- appear in appropriate places in message headers. It
- must support both the "B" and "Q" encodings for any
- character set which it supports. The program must be
- able to display the unencoded text if the character set
- is "US-ASCII". For the ISO-8859-* character sets, the
- mail reading program must at least be able to display
- the characters which are also in the US-ASCII set.
-
- A user agent that meets the above conditions is said to be MIME-
- 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.
-
-3. 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 order 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.
-
-
-
-
-Freed & Borenstein Standards Track [Page 6]
-
-RFC 2049 MIME Conformance November 1996
-
-
- The following guidelines may be useful to anyone devising a data
- format (media type) that is supposed to 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) The transmission of NULs (US-ASCII value 0) is
- problematic in Internet mail. (This is largely the
- result of NULs being used as a termination character by
- many of the standard runtime library routines in the C
- programming language.) The practice of using NULs as
- termination characters is so entrenched now that
- messages should not rely on them being preserved.
-
- (4) 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 US-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.
-
- (5) Lines longer than 76 characters may be wrapped or
- truncated in some environments. Line wrapping or line
- truncation imposed by mail transports is STRONGLY
- DISCOURAGED, but unavoidable in some cases.
- Applications which require long lines must somehow
-
-
-
-Freed & Borenstein Standards Track [Page 7]
-
-RFC 2049 MIME Conformance November 1996
-
-
- differentiate between soft and hard line breaks. (A
- simple way to do this is to use the quoted-printable
- encoding.)
-
- (6) 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.
-
- (7) Many mail domains use variations on the US-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 US-
- 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:
-
- "'" (US-ASCII decimal value 39)
- "(" (US-ASCII decimal value 40)
- ")" (US-ASCII decimal value 41)
- "+" (US-ASCII decimal value 43)
- "," (US-ASCII decimal value 44)
- "-" (US-ASCII decimal value 45)
- "." (US-ASCII decimal value 46)
- "/" (US-ASCII decimal value 47)
- ":" (US-ASCII decimal value 58)
- "=" (US-ASCII decimal value 61)
- "?" (US-ASCII decimal value 63)
-
- A maximally portable mail representation will confine
- itself to relatively short lines of text in which the
- only meaningful characters are taken from this set of
- 73 characters. The base64 encoding follows this rule.
-
- (8) Some mail transport agents will corrupt data that
- includes certain literal strings. In particular, a
-
-
-
-Freed & Borenstein Standards Track [Page 8]
-
-RFC 2049 MIME Conformance November 1996
-
-
- 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 well.
- A careful composition agent can prevent these
- corruptions by encoding the data (e.g., in the quoted-
- printable encoding using "=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
- invalid practices are known to occur on established networks, and
- implementations should be robust in dealing with the bad effects they
- can cause.
-
-4. Canonical Encoding Model
-
- There was some confusion, in earlier versions of these documents,
- 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 PEM [RFC-1421] and are performed for each
- "innermost level" body:
-
- (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 that corresponds to the type specified by
- the media type.
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 9]
-
-RFC 2049 MIME Conformance November 1996
-
-
- (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 media 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 media types.
- If character set conversion is involved, however, care
- must be taken to understand the semantics of the media
- 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 RFC 822. Note that the restriction on
- line lengths implied by RFC 822 is eliminated if the
- next step employs either quoted-printable or base64
- encoding.
-
- (3) Apply transfer encoding.
-
- A Content-Transfer-Encoding appropriate for this body
- is applied. Note that there is no fixed relationship
- between the media 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.
-
- (4) Insertion into entity.
-
- The encoded body 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) as needed.
-
- Conversion from entity form to local form is accomplished by
- reversing these steps. Note that reversal of these steps may produce
- differing results since there is no guarantee that the original and
- final local forms are the same.
-
-
-
-
-Freed & Borenstein Standards Track [Page 10]
-
-RFC 2049 MIME Conformance November 1996
-
-
- 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 RFC 822.
- 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 RFC 822 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.
-
- NOTE: Some confusion has been caused by systems that represent
- messages in a format which uses local newline conventions which
- differ from the RFC822 CRLF convention. It is important to note that
- these formats are not canonical RFC822/MIME. These formats are
- instead *encodings* of RFC822, where CRLF sequences in the canonical
- representation of the message are encoded as the local newline
- convention. Note that formats which encode CRLF sequences as, for
- example, LF are not capable of representing MIME messages containing
- binary data which contains LF octets not part of CRLF line separation
- sequences.
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 11]
-
-RFC 2049 MIME Conformance November 1996
-
-
-5. Summary
-
- This document defines what is meant by MIME Conformance. It also
- details various problems known to exist in the Internet email system
- and how to use MIME to overcome them. Finally, it describes MIME's
- canonical encoding model.
-
-6. Security Considerations
-
- Security issues are discussed in the second document in this set, RFC
- 2046.
-
-7. Authors' Addresses
-
- For more information, the authors of this document are best contacted
- via Internet mail:
-
- Ned Freed
- Innosoft International, Inc.
- 1050 East Garvey Avenue South
- West Covina, CA 91790
- USA
-
- Phone: +1 818 919 3600
- Fax: +1 818 919 3614
- EMail: [email protected]
-
- Nathaniel S. Borenstein
- First Virtual Holdings
- 25 Washington Avenue
- Morristown, NJ 07960
- USA
-
- Phone: +1 201 540 8967
- Fax: +1 201 993 3032
- EMail: [email protected]
-
- MIME is a result of the work of the Internet Engineering Task Force
- Working Group on RFC 822 Extensions. The chairman of that group,
- Greg Vaudreuil, may be reached at:
-
- Gregory M. Vaudreuil
- Octel Network Services
- 17080 Dallas Parkway
- Dallas, TX 75248-1905
- USA
-
- EMail: [email protected]
-
-
-
-Freed & Borenstein Standards Track [Page 12]
-
-RFC 2049 MIME Conformance November 1996
-
-
-8. 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 Marc Andreessen
- Randall Atkinson Bob Braden
- Philippe Brandon Brian Capouch
- Kevin Carosso Uhhyung Choi
- Peter Clitherow Dave Collier-Brown
- Cristian Constantinof John Coonrod
- Mark Crispin Dave Crocker
- Stephen Crocker Terry Crowley
- Walt Daniels Jim Davis
- Frank Dawson Axel Deininger
- Hitoshi Doi Kevin Donnelly
- Steve Dorner Keith Edwards
- Chris Eich Dana S. Emery
- Johnny Eriksson Craig Everhart
- Patrik Faltstrom Erik E. Fair
- Roger Fajman Alain Fontaine
- Martin Forssen James M. Galvin
- Stephen Gildea Philip Gladstone
- Thomas Gordon Keld Simonsen
- Terry Gray Phill Gross
- James Hamilton David Herron
- Mark Horton Bruce Howard
- Bill Janssen Olle Jarnefors
- Risto Kankkunen Phil Karn
- Alan Katz Tim Kehres
- Neil Katin Steve Kille
- Kyuho Kim Anders Klemets
- John Klensin Valdis Kletniek
- Jim Knowles Stev Knowles
- Bob Kummerfeld Pekka Kytolaakso
- Stellan Lagerstrom Vincent Lau
- Timo Lehtinen Donald Lindsay
- Warner Losh Carlyn Lowery
- Laurence Lundblade Charles Lynn
- John R. MacMillan Larry Masinter
- Rick McGowan Michael J. McInerny
- Leo Mclaughlin Goli Montaser-Kohsari
- Tom Moore John Gardiner Myers
- Erik Naggum Mark Needleman
- Chris Newman John Noerenberg
-
-
-
-Freed & Borenstein Standards Track [Page 13]
-
-RFC 2049 MIME Conformance November 1996
-
-
- Mats Ohrman Julian Onions
- Michael Patton David J. Pepper
- Erik van der Poel Blake C. Ramsdell
- Christer Romson Luc Rooijakkers
- Marshall T. Rose Jonathan Rosenberg
- Guido van Rossum Jan Rynning
- Harri Salminen Michael Sanderson
- Yutaka Sato Markku Savela
- Richard Alan Schafer Masahiro Sekiguchi
- Mark Sherman Bob Smart
- Peter Speck Henry Spencer
- Einar Stefferud Michael Stein
- Klaus Steinberger Peter Svanberg
- James Thompson Steve Uhler
- Stuart Vance Peter Vanderbilt
- Greg Vaudreuil Ed Vielmetti
- Larry W. Virden Ryan Waldron
- Rhys Weatherly Jay Weber
- Dave Wecker Wally Wedel
- Sven-Ove Westberg Brian Wideen
- John Wobus Glenn Wright
- Rayan Zachariassen David Zimmerman
-
- The authors apologize for any omissions from this list, which are
- certainly unintentional.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 14]
-
-RFC 2049 MIME Conformance November 1996
-
-
-Appendix A -- A Complex Multipart Example
-
- What follows is the outline of a complex multipart message. This
- message contains five parts that are to be displayed serially: two
- introductory plain text objects, an embedded multipart message, a
- text/enriched object, and a closing encapsulated text message in a
- non-ASCII character set. The embedded multipart message itself
- contains two objects to be displayed in parallel, a picture and an
- audio fragment.
-
- MIME-Version: 1.0
- From: Nathaniel Borenstein <[email protected]>
- To: Ned Freed <[email protected]>
- Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)
- 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 blank between the boundary and the start
- of the text in this part means no header fields were
- given and this is text in the US-ASCII character set.
- 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
-
-
-
-Freed & Borenstein Standards Track [Page 15]
-
-RFC 2049 MIME Conformance November 1996
-
-
- Content-Transfer-Encoding: base64
-
- ... base64-encoded 8000 Hz single-channel
- mu-law-format audio data goes here ...
-
- --unique-boundary-2
- Content-Type: image/jpeg
- Content-Transfer-Encoding: base64
-
- ... base64-encoded image data goes here ...
-
- --unique-boundary-2--
-
- --unique-boundary-1
- Content-type: text/enriched
-
- This is <bold><italic>enriched.</italic></bold>
- <smaller>as defined in RFC 1896</smaller>
-
- Isn't it
- <bigger><bigger>cool?</bigger></bigger>
-
- --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--
-
-Appendix B -- Changes from RFC 1521, 1522, and 1590
-
- These documents are a revision of RFC 1521, 1522, and 1590. For the
- convenience of those familiar with the earlier documents, the changes
- from those documents are summarized in this appendix. For further
- history, note that Appendix H in RFC 1521 specified how that document
- differed from its predecessor, RFC 1341.
-
- (1) This document has been completely reformatted and split
- into multiple documents. This was done to improve the
- quality of the plain text version of this document,
- which is required to be the reference copy.
-
-
-
-
-Freed & Borenstein Standards Track [Page 16]
-
-RFC 2049 MIME Conformance November 1996
-
-
- (2) BNF describing the overall structure of MIME object
- headers has been added. This is a documentation change
- only -- the underlying syntax has not changed in any
- way.
-
- (3) The specific BNF for the seven media types in MIME has
- been removed. This BNF was incorrect, incomplete, amd
- inconsistent with the type-indendependent BNF. And
- since the type-independent BNF already fully specifies
- the syntax of the various MIME headers, the type-
- specific BNF was, in the final analysis, completely
- unnecessary and caused more problems than it solved.
-
- (4) The more specific "US-ASCII" character set name has
- replaced the use of the informal term ASCII in many
- parts of these documents.
-
- (5) The informal concept of a primary subtype has been
- removed.
-
- (6) The term "object" was being used inconsistently. The
- definition of this term has been clarified, along with
- the related terms "body", "body part", and "entity",
- and usage has been corrected where appropriate.
-
- (7) The BNF for the multipart media type has been
- rearranged to make it clear that the CRLF preceeding
- the boundary marker is actually part of the marker
- itself rather than the preceeding body part.
-
- (8) The prose and BNF describing the multipart media type
- have been changed to make it clear that the body parts
- within a multipart object MUST NOT contain any lines
- beginning with the boundary parameter string.
-
- (9) In the rules on reassembling "message/partial" MIME
- entities, "Subject" is added to the list of headers to
- take from the inner message, and the example is
- modified to clarify this point.
-
- (10) "Message/partial" fragmenters are restricted to
- splitting MIME objects only at line boundaries.
-
- (11) In the discussion of the application/postscript type,
- an additional paragraph has been added warning about
- possible interoperability problems caused by embedding
- of binary data inside a PostScript MIME entity.
-
-
-
-
-Freed & Borenstein Standards Track [Page 17]
-
-RFC 2049 MIME Conformance November 1996
-
-
- (12) Added a clarifying note to the basic syntax rules for
- the Content-Type header field to make it clear that the
- following two forms:
-
- Content-type: text/plain; charset=us-ascii (comment)
-
- Content-type: text/plain; charset="us-ascii"
-
- are completely equivalent.
-
- (13) The following sentence has been removed from the
- discussion of the MIME-Version header: "However,
- conformant software is encouraged to check the version
- number and at least warn the user if an unrecognized
- MIME-version is encountered."
-
- (14) A typo was fixed that said "application/external-body"
- instead of "message/external-body".
-
- (15) The definition of a character set has been reorganized
- to make the requirements clearer.
-
- (16) The definition of the "image/gif" media type has been
- moved to a separate document. This change was made
- because of potential conflicts with IETF rules
- governing the standardization of patented technology.
-
- (17) The definitions of "7bit" and "8bit" have been
- tightened so that use of bare CR, LF can only be used
- as end-of-line sequences. The document also no longer
- requires that NUL characters be preserved, which brings
- MIME into alignment with real-world implementations.
-
- (18) The definition of canonical text in MIME has been
- tightened so that line breaks must be represented by a
- CRLF sequence. CR and LF characters are not allowed
- outside of this usage. The definition of quoted-
- printable encoding has been altered accordingly.
-
- (19) The definition of the quoted-printable encoding now
- includes a number of suggestions for how quoted-
- printable encoders might best handle improperly encoded
- material.
-
- (20) Prose was added to clarify the use of the "7bit",
- "8bit", and "binary" transfer-encodings on multipart or
- message entities encapsulating "8bit" or "binary" data.
-
-
-
-
-Freed & Borenstein Standards Track [Page 18]
-
-RFC 2049 MIME Conformance November 1996
-
-
- (21) In the section on MIME Conformance, "multipart/digest"
- support was added to the list of requirements for
- minimal MIME conformance. Also, the requirement for
- "message/rfc822" support were strengthened to clarify
- the importance of recognizing recursive structure.
-
- (22) The various restrictions on subtypes of "message" are
- now specified entirely on a subtype by subtype basis.
-
- (23) The definition of "message/rfc822" was changed to
- indicate that at least one of the "From", "Subject", or
- "Date" headers must be present.
-
- (24) The required handling of unrecognized subtypes as
- "application/octet-stream" has been made more explicit
- in both the type definitions sections and the
- conformance guidelines.
-
- (25) Examples using text/richtext were changed to
- text/enriched.
-
- (26) The BNF definition of subtype has been changed to make
- it clear that either an IANA registered subtype or a
- nonstandard "X-" subtype must be used in a Content-Type
- header field.
-
- (27) MIME media types that are simply registered for use and
- those that are standardized by the IETF are now
- distinguished in the MIME BNF.
-
- (28) All of the various MIME registration procedures have
- been extensively revised. IANA registration procedures
- for character sets have been moved to a separate
- document that is no included in this set of documents.
-
- (29) The use of escape and shift mechanisms in the US-ASCII
- and ISO-8859-X character sets these documents define
- have been clarified: Such mechanisms should never be
- used in conjunction with these character sets and their
- effect if they are used is undefined.
-
- (30) The definition of the AFS access-type for
- message/external-body has been removed.
-
- (31) The handling of the combination of
- multipart/alternative and message/external-body is now
- specifically addressed.
-
-
-
-
-Freed & Borenstein Standards Track [Page 19]
-
-RFC 2049 MIME Conformance November 1996
-
-
- (32) Security issues specific to message/external-body are
- now discussed in some detail.
-
-Appendix C -- References
-
- [ATK]
- Borenstein, Nathaniel S., Multimedia Applications
- Development with the Andrew Toolkit, Prentice-Hall, 1990.
-
- [ISO-2022]
- International Standard -- Information Processing --
- Character Code Structure and Extension Techniques,
- ISO/IEC 2022:1994, 4th ed.
-
- [ISO-8859]
- International Standard -- Information Processing -- 8-bit
- Single-Byte Coded Graphic Character Sets
- - Part 1: Latin Alphabet No. 1, ISO 8859-1:1987, 1st ed.
- - Part 2: Latin Alphabet No. 2, ISO 8859-2:1987, 1st ed.
- - Part 3: Latin Alphabet No. 3, ISO 8859-3:1988, 1st ed.
- - Part 4: Latin Alphabet No. 4, ISO 8859-4:1988, 1st ed.
- - Part 5: Latin/Cyrillic Alphabet, ISO 8859-5:1988, 1st
- ed.
- - Part 6: Latin/Arabic Alphabet, ISO 8859-6:1987, 1st ed.
- - Part 7: Latin/Greek Alphabet, ISO 8859-7:1987, 1st ed.
- - Part 8: Latin/Hebrew Alphabet, ISO 8859-8:1988, 1st ed.
- - Part 9: Latin Alphabet No. 5, ISO/IEC 8859-9:1989, 1st
- ed.
- International Standard -- Information Technology -- 8-bit
- Single-Byte Coded Graphic Character Sets
- - Part 10: Latin Alphabet No. 6, ISO/IEC 8859-10:1992,
- 1st ed.
-
- [ISO-646]
- International Standard -- Information Technology -- ISO
- 7-bit Coded Character Set for Information Interchange,
- ISO 646:1991, 3rd ed..
-
- [JPEG]
- JPEG Draft Standard ISO 10918-1 CD.
-
- [MPEG]
- Video Coding Draft Standard ISO 11172 CD, ISO
- IEC/JTC1/SC2/WG11 (Motion Picture Experts Group), May,
- 1991.
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 20]
-
-RFC 2049 MIME Conformance November 1996
-
-
- [PCM]
- CCITT, Fascicle III.4 - Recommendation G.711, "Pulse Code
- Modulation (PCM) of Voice Frequencies", Geneva, 1972.
-
- [POSTSCRIPT]
- Adobe Systems, Inc., PostScript Language Reference
- Manual, Addison-Wesley, 1985.
-
- [POSTSCRIPT2]
- Adobe Systems, Inc., PostScript Language Reference
- Manual, Addison-Wesley, Second Ed., 1990.
-
- [RFC-783]
- Sollins, K.R., "TFTP Protocol (revision 2)", RFC-783,
- MIT, June 1981.
-
- [RFC-821]
- Postel, J.B., "Simple Mail Transfer Protocol", STD 10,
- RFC 821, USC/Information Sciences Institute, August 1982.
-
- [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", RFC 1049, CMU, March 1988.
-
- [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.
-
-
-
-
-Freed & Borenstein Standards Track [Page 21]
-
-RFC 2049 MIME Conformance November 1996
-
-
- [RFC-1342]
- Moore, K., "Representation of Non-Ascii Text in Internet
- Message Headers", RFC 1342, University of Tennessee, 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-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-1422]
- Kent, S., "Privacy Enhancement for Internet Electronic
- Mail: Part II -- Certificate-Based Key Management", RFC
- 1422, IAB IRTF PSRG, IETF PEM WG, February 1993.
-
- [RFC-1423]
- Balenson, D., "Privacy Enhancement for Internet
- Electronic Mail: Part III -- Algorithms, Modes, and
- Identifiers", IAB IRTF PSRG, IETF PEM WG, February 1993.
-
- [RFC-1424]
- Kaliski, B., "Privacy Enhancement for Internet Electronic
- Mail: Part IV -- Key Certification and Related
- Services", IAB IRTF PSRG, IETF PEM WG, February 1993.
-
- [RFC-1521]
- Borenstein, N., and Freed, N., "MIME (Multipurpose
- Internet Mail Extensions): Mechanisms for Specifying and
- Describing the Format of Internet Message Bodies", RFC
- 1521, Bellcore, Innosoft, September, 1993.
-
- [RFC-1522]
- Moore, K., "Representation of Non-ASCII Text in Internet
- Message Headers", RFC 1522, University of Tennessee,
- September 1993.
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 22]
-
-RFC 2049 MIME Conformance November 1996
-
-
- [RFC-1524]
- Borenstein, N., "A User Agent Configuration Mechanism for
- Multimedia Mail Format Information", RFC 1524, Bellcore,
- September 1993.
-
- [RFC-1543]
- Postel, J., "Instructions to RFC Authors", RFC 1543,
- USC/Information Sciences Institute, October 1993.
-
- [RFC-1556]
- Nussbacher, H., "Handling of Bi-directional Texts in
- MIME", RFC 1556, Israeli Inter-University Computer
- Center, December 1993.
-
- [RFC-1590]
- Postel, J., "Media Type Registration Procedure", RFC
- 1590, USC/Information Sciences Institute, March 1994.
-
- [RFC-1602]
- Internet Architecture Board, Internet Engineering
- Steering Group, Huitema, C., Gross, P., "The Internet
- Standards Process -- Revision 2", March 1994.
-
- [RFC-1652]
- Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M.,
- Stefferud, E., and Crocker, D., "SMTP Service Extension
- for 8bit-MIME transport", RFC 1652, United Nations
- University, Innosoft, Dover Beach Consulting, Inc.,
- Network Management Associates, Inc., The Branch Office,
- March 1994.
-
- [RFC-1700]
- Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
- RFC 1700, USC/Information Sciences Institute, October
- 1994.
-
- [RFC-1741]
- Faltstrom, P., Crocker, D., and Fair, E., "MIME Content
- Type for BinHex Encoded Files", December 1994.
-
- [RFC-1896]
- Resnick, P., and A. Walker, "The text/enriched MIME
- Content-type", RFC 1896, February, 1996.
-
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 23]
-
-RFC 2049 MIME Conformance November 1996
-
-
- [RFC-2045]
- Freed, N., and and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message
- Bodies", RFC 2045, Innosoft, First Virtual Holdings,
- November 1996.
-
- [RFC-2046]
- Freed, N., and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part Two: Media Types", RFC 2046,
- Innosoft, First Virtual Holdings, November 1996.
-
- [RFC-2047]
- Moore, K., "Multipurpose Internet Mail Extensions (MIME)
- Part Three: Representation of Non-ASCII Text in Internet
- Message Headers", RFC 2047, University of
- Tennessee, November 1996.
-
- [RFC-2048]
- Freed, N., Klensin, J., and J. Postel, "Multipurpose
- Internet Mail Extensions (MIME) Part Four: MIME
- Registration Procedures", RFC 2048, Innosoft, MCI,
- ISI, November 1996.
-
- [RFC-2049]
- Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part Five: Conformance Criteria and
- Examples", RFC 2049 (this document), Innosoft, First
- Virtual Holdings, November 1996.
-
- [US-ASCII]
- Coded Character Set -- 7-Bit American Standard Code for
- Information Interchange, ANSI X3.4-1986.
-
- [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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 24]
-
diff --git a/doc/rfc/rfc2060-errata b/doc/rfc/rfc2060-errata
deleted file mode 100644
index 2e422b9..0000000
--- a/doc/rfc/rfc2060-errata
+++ /dev/null
@@ -1,45 +0,0 @@
-Known errors in RFC 2060 as of 13 September 1998:
-
-1) The SELECT and EXAMINE response list does not mention UIDVALIDITY.
-
-2) In the definition of store_att_flags, #flag should be 1#flag; in other
- words, at least one flag must be given. To do an empty list of flags,
- you must use the parenthesized form: "()".
-
-3) The example in 6.4.6 is missing parenthesis around the FETCH attributes.
- It should read:
-
- 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
-
-4) Section 7.4.2 has an example of "a two part message consisting of a
- text and a BASE645-encoded text attachment". "BASE645" should be
- BASE64.
-
-5) In the example in 7.4.2 discussed above, there is a spurious close
- parenthesis at the end of the example.
-
-6) Spurious obsolete response "MAILBOX" is listed in mailbox_data and
- should be removed.
-
-7) There is a spurious "<" in the mailbox_data rule that should be removed.
-
-8) CRLF is missing from the continue_req rule.
-
-9) The atom in resp_text_code should specifically exclude "]".
-
-10) The example in 6.3.11 does not show the command continuation request.
-
-11) NEWNAME is missing from resp_text_code.
-
-12) There is a missing open parenthesis in the media_basic grammar rule.
-
-13) Status attributes are incorrectly defined in mailbox_data rule.
-
-14) The UID FETCH example is missing an "OK" in the response.
-
-15) Multipart extension data incorrectly specifies that language must be
- given along with disposition.
diff --git a/doc/rfc/rfc2060.txt b/doc/rfc/rfc2060.txt
deleted file mode 100644
index 030c6b3..0000000
--- a/doc/rfc/rfc2060.txt
+++ /dev/null
@@ -1,4595 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Crispin
-Request for Comments: 2060 University of Washington
-Obsoletes: 1730 December 1996
-Category: Standards Track
-
-
- INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
-
-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 4rev1 (IMAP4rev1)
- allows a client to access and manipulate electronic mail messages on
- a server. IMAP4rev1 permits manipulation of remote message folders,
- called "mailboxes", in a way that is functionally equivalent to local
- mailboxes. IMAP4rev1 also provides the capability for an offline
- client to resynchronize with the server (see also [IMAP-DISC]).
-
- IMAP4rev1 includes operations for creating, deleting, and renaming
- mailboxes; checking for new messages; permanently removing messages;
- setting and clearing flags; [RFC-822] and [MIME-IMB] parsing;
- searching; and selective fetching of message attributes, texts, and
- portions thereof. Messages in IMAP4rev1 are accessed by the use of
- numbers. These numbers are either message sequence numbers or unique
- identifiers.
-
- IMAP4rev1 supports a single server. A mechanism for accessing
- configuration information to support multiple IMAP4rev1 servers is
- discussed in [ACAP].
-
- IMAP4rev1 does not specify a means of posting mail; this function is
- handled by a mail transfer protocol such as [SMTP].
-
- IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
- unpublished IMAP2bis protocols. In the course of the evolution of
- IMAP4rev1, some aspects in the earlier protocol have become obsolete.
- Obsolete commands, responses, and data formats which an IMAP4rev1
- implementation may encounter when used with an earlier implementation
- are described in [IMAP-OBSOLETE].
-
-
-
-
-
-Crispin Standards Track [Page 1]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- Other compatibility issues with IMAP2bis, the most common variant of
- the earlier protocol, are discussed in [IMAP-COMPAT]. A full
- discussion of compatibility issues with rare (and presumed extinct)
- variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
- primarily of historical interest.
-
-Table of Contents
-
-IMAP4rev1 Protocol Specification .................................. 4
-1. How to Read This Document ................................. 4
-1.1. Organization of This Document ............................. 4
-1.2. Conventions Used in This Document ......................... 4
-2. Protocol Overview ......................................... 5
-2.1. Link Level ................................................ 5
-2.2. Commands and Responses .................................... 6
-2.2.1. Client Protocol Sender and Server Protocol Receiver ....... 6
-2.2.2. Server Protocol Sender and Client Protocol Receiver ....... 7
-2.3. Message Attributes ........................................ 7
-2.3.1. Message Numbers ........................................... 7
-2.3.1.1. Unique Identifier (UID) Message Attribute ......... 7
-2.3.1.2. Message Sequence Number Message Attribute ......... 9
-2.3.2. Flags Message Attribute .................................... 9
-2.3.3. Internal Date Message Attribute ........................... 10
-2.3.4. [RFC-822] Size Message Attribute .......................... 11
-2.3.5. Envelope Structure Message Attribute ...................... 11
-2.3.6. Body Structure Message Attribute .......................... 11
-2.4. Message Texts ............................................. 11
-3. State and Flow Diagram .................................... 11
-3.1. Non-Authenticated State ................................... 11
-3.2. Authenticated State ....................................... 11
-3.3. Selected State ............................................ 12
-3.4. Logout State .............................................. 12
-4. Data Formats .............................................. 12
-4.1. Atom ...................................................... 13
-4.2. Number .................................................... 13
-4.3. String ..................................................... 13
-4.3.1. 8-bit and Binary Strings .................................. 13
-4.4. Parenthesized List ........................................ 14
-4.5. NIL ....................................................... 14
-5. Operational Considerations ................................ 14
-5.1. Mailbox Naming ............................................ 14
-5.1.1. Mailbox Hierarchy Naming .................................. 14
-5.1.2. Mailbox Namespace Naming Convention ....................... 14
-5.1.3. Mailbox International Naming Convention ................... 15
-5.2. Mailbox Size and Message Status Updates ................... 16
-5.3. Response when no Command in Progress ...................... 16
-5.4. Autologout Timer .......................................... 16
-5.5. Multiple Commands in Progress ............................. 17
-
-
-
-Crispin Standards Track [Page 2]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-6. Client Commands ........................................... 17
-6.1. Client Commands - Any State ............................... 18
-6.1.1. CAPABILITY Command ........................................ 18
-6.1.2. NOOP Command .............................................. 19
-6.1.3. LOGOUT Command ............................................ 20
-6.2. Client Commands - Non-Authenticated State ................. 20
-6.2.1. AUTHENTICATE Command ...................................... 21
-6.2.2. LOGIN Command ............................................. 22
-6.3. Client Commands - Authenticated State ..................... 22
-6.3.1. SELECT Command ............................................ 23
-6.3.2. EXAMINE Command ........................................... 24
-6.3.3. CREATE Command ............................................ 25
-6.3.4. DELETE Command ............................................ 26
-6.3.5. RENAME Command ............................................ 27
-6.3.6. SUBSCRIBE Command ......................................... 29
-6.3.7. UNSUBSCRIBE Command ....................................... 30
-6.3.8. LIST Command .............................................. 30
-6.3.9. LSUB Command .............................................. 32
-6.3.10. STATUS Command ............................................ 33
-6.3.11. APPEND Command ............................................ 34
-6.4. Client Commands - Selected State .......................... 35
-6.4.1. CHECK Command ............................................. 36
-6.4.2. CLOSE Command ............................................. 36
-6.4.3. EXPUNGE Command ........................................... 37
-6.4.4. SEARCH Command ............................................ 37
-6.4.5. FETCH Command ............................................. 41
-6.4.6. STORE Command ............................................. 45
-6.4.7. COPY Command .............................................. 46
-6.4.8. UID Command ............................................... 47
-6.5. Client Commands - Experimental/Expansion .................. 48
-6.5.1. X<atom> Command ........................................... 48
-7. Server Responses .......................................... 48
-7.1. Server Responses - Status Responses ....................... 49
-7.1.1. OK Response ............................................... 51
-7.1.2. NO Response ............................................... 51
-7.1.3. BAD Response .............................................. 52
-7.1.4. PREAUTH Response .......................................... 52
-7.1.5. BYE Response .............................................. 52
-7.2. Server Responses - Server and Mailbox Status .............. 53
-7.2.1. CAPABILITY Response ....................................... 53
-7.2.2. LIST Response .............................................. 54
-7.2.3. LSUB Response ............................................. 55
-7.2.4 STATUS Response ........................................... 55
-7.2.5. SEARCH Response ........................................... 55
-7.2.6. FLAGS Response ............................................ 56
-7.3. Server Responses - Mailbox Size ........................... 56
-7.3.1. EXISTS Response ........................................... 56
-7.3.2. RECENT Response ........................................... 57
-
-
-
-Crispin Standards Track [Page 3]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-7.4. Server Responses - Message Status ......................... 57
-7.4.1. EXPUNGE Response .......................................... 57
-7.4.2. FETCH Response ............................................ 58
-7.5. Server Responses - Command Continuation Request ........... 63
-8. Sample IMAP4rev1 connection ............................... 63
-9. Formal Syntax ............................................. 64
-10. Author's Note ............................................. 74
-11. Security Considerations ................................... 74
-12. Author's Address .......................................... 75
-Appendices ........................................................ 76
-A. References ................................................ 76
-B. Changes from RFC 1730 ..................................... 77
-C. Key Word Index ............................................ 79
-
-
-IMAP4rev1 Protocol Specification
-
-1. How to Read This Document
-
-1.1. Organization of This Document
-
- This document is written from the point of view of the implementor of
- an IMAP4rev1 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 IMAP4rev1
- 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, do not attempt to deduce command syntax from the command
- section alone; 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.
-
- The following terms are used in this document to signify the
- requirements of this specification.
-
- 1) MUST, or the adjective REQUIRED, means that the definition is
- an absolute requirement of the specification.
-
- 2) MUST NOT that the definition is an absolute prohibition of the
- specification.
-
-
-
-
-Crispin Standards Track [Page 4]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- 3) SHOULD means that there may exist valid reasons in particular
- circumstances to ignore a particular item, but the full
- implications MUST be understood and carefully weighed before
- choosing a different course.
-
- 4) SHOULD NOT means that there may exist valid reasons in
- particular circumstances when the particular behavior is
- acceptable or even useful, but the full implications SHOULD be
- understood and the case carefully weighed before implementing
- any behavior described with this label.
-
- 5) MAY, or the adjective OPTIONAL, means that an item is truly
- optional. One vendor may choose to include the item because a
- particular marketplace requires it or because the vendor feels
- that it enhances the product while another vendor may omit the
- same item. An implementation which does not include a
- particular option MUST be prepared to interoperate with another
- implementation which does include the option.
-
- "Can" is used instead of "may" when referring to a possible
- circumstance or situation, as opposed to an optional facility of
- the protocol.
-
- "User" is used to refer to a human user, whereas "client" refers
- to the software being run by the user.
-
- "Connection" refers to the entire sequence of client/server
- interaction from the initial establishment of the network
- connection until its termination. "Session" refers to the
- sequence of client/server interaction from the time that a mailbox
- is selected (SELECT or EXAMINE command) until the time that
- selection ends (SELECT or EXAMINE of another mailbox, CLOSE
- command, or connection termination).
-
- Characters are 7-bit US-ASCII unless otherwise specified. Other
- character sets are indicated using a "CHARSET", as described in
- [MIME-IMT] and defined in [CHARSET]. CHARSETs have important
- additional semantics in addition to defining character set; refer
- to these documents for more detail.
-
-2. Protocol Overview
-
-2.1. Link Level
-
- The IMAP4rev1 protocol assumes a reliable data stream such as
- provided by TCP. When TCP is used, an IMAP4rev1 server listens on
- port 143.
-
-
-
-
-Crispin Standards Track [Page 5]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-2.2. Commands and Responses
-
- An IMAP4rev1 connection consists of the establishment of a
- client/server network 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 IMAP4rev1 client or server is either reading a line, or is
- reading a sequence of octets with a known count followed by a line.
-
-2.2.1. Client Protocol Sender and Server Protocol Receiver
-
- The client command begins an operation. Each client command is
- prefixed with an 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. In all
- cases, the client MUST send a complete command (including
- receiving all command continuation request responses and command
- continuations for the command) before initiating a new command.
-
- The protocol receiver of an IMAP4rev1 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.
-
-
-
-
-
-Crispin Standards Track [Page 6]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-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
- 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 IMAP4rev1 client reads a response line
- from the server. It then takes action on the response based upon the
- first token of the response, which can be a tag, a "*", or a "+".
-
- A client MUST be prepared to accept any server response at all times.
- This includes server data that was not 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, the data MUST be recorded.
-
- This topic is discussed in greater detail in the Server Responses
- section.
-
-2.3. Message Attributes
-
- In addition to message text, each message has several attributes
- associated with it. These attributes may be retrieved individually
- or in conjunction with other attributes or message texts.
-
-2.3.1. Message Numbers
-
- Messages in IMAP4rev1 are accessed by one of two numbers; the unique
- identifier and the message sequence number.
-
-2.3.1.1. Unique Identifier (UID) Message Attribute
-
- A 32-bit value assigned to each message, which when used with the
- unique identifier validity value (see below) forms a 64-bit value
-
-
-
-Crispin Standards Track [Page 7]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- that is permanently guaranteed not to refer to any other message in
- the mailbox. Unique identifiers are assigned in a strictly ascending
- fashion in the mailbox; as each message is added to the mailbox it is
- assigned a higher UID than the message(s) which were added
- previously.
-
- Unlike message sequence numbers, unique identifiers are not
- necessarily contiguous. Unique identifiers also 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 mailbox selection time. If unique identifiers from an
- earlier session fail to persist to this session, the unique
- identifier validity value MUST be greater than the one used in the
- earlier session.
-
- Note: Unique identifiers MUST be strictly ascending in the mailbox
- at all times. If the physical message store is re-ordered by a
- non-IMAP agent, this requires that the unique identifiers in the
- mailbox be regenerated, since the former unique identifers are no
- longer strictly ascending as a result of the re-ordering. Another
- instance in which unique identifiers are regenerated is if the
- message store has no mechanism to store unique identifiers.
- Although this specification recognizes that this may be
- unavoidable in certain server environments, it STRONGLY ENCOURAGES
- message store implementation techniques that avoid this problem.
-
- Another cause of non-persistance is if the mailbox is deleted and
- a new mailbox with the same name is created at a later date, Since
- the name is the same, a client may not know that this is a new
- mailbox unless the unique identifier validity is different. A
- good value to use for the unique identifier validity value is 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 identifiers will never be reused, even in
- the case of a mailbox being deleted (or renamed) and a new mailbox
- by the same name created at some future time.
-
- The unique identifier of a message MUST NOT change during the
- session, and SHOULD NOT change between sessions. However, if it is
- not possible to preserve the unique identifier of a message in a
- subsequent session, each subsequent session MUST have a new unique
- identifier validity value that is larger than any that was used
- previously.
-
-
-
-
-Crispin Standards Track [Page 8]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-2.3.1.2. Message Sequence Number Message Attribute
-
- A relative position from 1 to the number of messages in the mailbox.
- This position MUST be ordered by ascending unique identifier. As
- each new message is added, it is assigned a message sequence number
- that is 1 higher than the number of messages in the mailbox before
- that new message was added.
-
- Message sequence numbers can be reassigned during the session. For
- example, when a message is permanently removed (expunged) from the
- mailbox, the message sequence number for all subsequent messages is
- decremented. Similarly, a new message can be assigned a message
- sequence number that was once held by some other message prior to an
- expunge.
-
- In addition to accessing messages by relative position in the
- mailbox, message sequence numbers can be used in mathematical
- calculations. For example, if an untagged "EXISTS 11" is received,
- and previously an untagged "8 EXISTS" was received, three new
- messages have arrived with message sequence numbers of 9, 10, and 11.
- Another example; if message 287 in a 523 message mailbox has UID
- 12345, there are exactly 286 messages which have lesser UIDs and 236
- messages which have greater UIDs.
-
-2.3.2. Flags Message Attribute
-
- A list of zero or more named tokens associated with the message. A
- flag is set by its addition to this list, and is cleared by its
- removal. There are two types of flags in IMAP4rev1. A flag of
- either type may be permanent or session-only.
-
- A system flag is a flag name that is pre-defined in this
- specification. All system flags begin with "\". Certain system
- flags (\Deleted and \Seen) have special semantics described
- elsewhere. The currently-defined system flags are:
-
- \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).
-
-
-
-
-
-Crispin Standards Track [Page 9]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- \Recent Message is "recently" arrived in this mailbox. This
- session is the first session to have been notified
- about this message; subsequent sessions will not see
- \Recent set for this message. This flag can not be
- altered by the client.
-
- If it is not possible to determine whether or not
- this session is the first session to be notified
- about a message, then that message SHOULD be
- considered recent.
-
- If multiple connections have the same mailbox
- selected simultaneously, it is undefined which of
- these connections will see newly-arrives messages
- with \Recent set and which will see it without
- \Recent set.
-
- A keyword is defined by the server implementation. Keywords do
- not begin with "\". Servers MAY permit the client to define new
- keywords in the mailbox (see the description of the
- PERMANENTFLAGS response code for more information).
-
- A flag may be permanent or session-only on a per-flag basis.
- Permanent flags are those which the client can add or remove
- from the message flags permanently; that is, subsequent sessions
- will see any change in permanent flags. Changes to session
- flags are valid only in that session.
-
- Note: The \Recent system flag is a special case of a
- session flag. \Recent can not be used as an argument in a
- STORE command, and thus can not be changed at all.
-
-2.3.3. Internal Date Message Attribute
-
- The internal date and time of the message on the server. This is not
- the date and time in the [RFC-822] header, but rather a date and time
- which reflects when the message was received. In the case of
- messages delivered via [SMTP], this SHOULD be the date and time of
- final delivery of the message as defined by [SMTP]. In the case of
- messages delivered by the IMAP4rev1 COPY command, this SHOULD be the
- internal date and time of the source message. In the case of
- messages delivered by the IMAP4rev1 APPEND command, this SHOULD be
- the date and time as specified in the APPEND command description.
- All other cases are implementation defined.
-
-
-
-
-
-
-
-Crispin Standards Track [Page 10]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-2.3.4. [RFC-822] Size Message Attribute
-
- The number of octets in the message, as expressed in [RFC-822]
- format.
-
-2.3.5. Envelope Structure Message Attribute
-
- A parsed representation of the [RFC-822] envelope information (not to
- be confused with an [SMTP] envelope) of the message.
-
-2.3.6. Body Structure Message Attribute
-
- A parsed representation of the [MIME-IMB] body structure information
- of the message.
-
-2.4. Message Texts
-
- In addition to being able to fetch the full [RFC-822] text of a
- message, IMAP4rev1 permits the fetching of portions of the full
- message text. Specifically, it is possible to fetch the [RFC-822]
- message header, [RFC-822] message body, a [MIME-IMB] body part, or a
- [MIME-IMB] header.
-
-3. State and Flow Diagram
-
- An IMAP4rev1 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 client 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 client 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.
-
-
-
-
-
-
-Crispin Standards Track [Page 11]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-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 connection 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.
-
- +--------------------------------------+
- |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
-
-4. Data Formats
-
- IMAP4rev1 uses textual commands and responses. Data in IMAP4rev1 can
- be in one of several forms: atom, number, string, parenthesized list,
- or NIL.
-
-
-
-Crispin Standards Track [Page 12]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-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 limitations of characters that can be used 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 represented 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.
-
-4.3.1. 8-bit and Binary Strings
-
- 8-bit textual and binary mail is supported through the use of a
- [MIME-IMB] content transfer encoding. IMAP4rev1 implementations MAY
- transmit 8-bit or multi-octet characters in literals, but SHOULD do
- so only when the [CHARSET] is identified.
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 13]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- 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.
-
-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 can 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 ().
-
-5. Operational Considerations
-
-5.1. Mailbox Naming
-
- The interpretation of mailbox names is implementation-dependent.
- However, the case-insensitive mailbox name INBOX is a special name
- reserved to mean "the primary mailbox for this user on this server".
-
-5.1.1. Mailbox Hierarchy Naming
-
- 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.1.2. Mailbox Namespace Naming Convention
-
- By convention, the first hierarchical element of any mailbox name
- which begins with "#" identifies the "namespace" of the remainder of
- the name. This makes it possible to disambiguate between different
- types of mailbox stores, each of which have their own namespaces.
-
-
-
-
-
-
-
-Crispin Standards Track [Page 14]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- For example, implementations which offer access to USENET
- newsgroups MAY use the "#news" namespace to partition the USENET
- newsgroup namespace from that of other mailboxes. Thus, the
- comp.mail.misc newsgroup would have an mailbox name of
- "#news.comp.mail.misc", and the name "comp.mail.misc" could refer
- to a different object (e.g. a user's private mailbox).
-
-5.1.3. Mailbox International Naming Convention
-
- By convention, international mailbox names are specified using a
- modified version of the UTF-7 encoding described in [UTF-7]. The
- purpose of these modifications is to correct the following problems
- with UTF-7:
-
- 1) UTF-7 uses the "+" character for shifting; this conflicts with
- the common use of "+" in mailbox names, in particular USENET
- newsgroup names.
-
- 2) UTF-7's encoding is BASE64 which uses the "/" character; this
- conflicts with the use of "/" as a popular hierarchy delimiter.
-
- 3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with
- the use of "\" as a popular hierarchy delimiter.
-
- 4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with
- the use of "~" in some servers as a home directory indicator.
-
- 5) UTF-7 permits multiple alternate forms to represent the same
- string; in particular, printable US-ASCII chararacters can be
- represented in encoded form.
-
- In modified UTF-7, printable US-ASCII characters except for "&"
- represent themselves; that is, characters with octet values 0x20-0x25
- and 0x27-0x7e. The character "&" (0x26) is represented by the two-
- octet sequence "&-".
-
- All other characters (octet values 0x00-0x1f, 0x7f-0xff, and all
- Unicode 16-bit octets) are represented in modified BASE64, with a
- further modification from [UTF-7] that "," is used instead of "/".
- Modified BASE64 MUST NOT be used to represent any printing US-ASCII
- character which can represent itself.
-
- "&" is used to shift to modified BASE64 and "-" to shift back to US-
- ASCII. All names start in US-ASCII, and MUST end in US-ASCII (that
- is, a name that ends with a Unicode 16-bit octet MUST end with a "-
- ").
-
-
-
-
-
-Crispin Standards Track [Page 15]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- For example, here is a mailbox name which mixes English, Japanese,
- and Chinese text: ~peter/mail/&ZeVnLIqe-/&U,BTFw-
-
-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 detail.
-
- Regardless of what implementation decisions a client makes 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.
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 16]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-5.5. Multiple Commands in Progress
-
- The client MAY send another command without waiting for the
- completion result response of a command, subject to ambiguity rules
- (see below) and flow control constraints on the underlying data
- stream. Similarly, a server MAY begin processing another command
- before processing the current command to completion, subject to
- ambiguity rules. However, any command continuation request responses
- and command continuations MUST be negotiated before any subsequent
- command is initiated.
-
- The exception is if an ambiguity would result because of a command
- that would affect the results of other commands. Clients MUST NOT
- send multiple commands without waiting if an ambiguity would result.
- If the server detects a possible ambiguity, it MUST execute commands
- to completion in the order given by the client.
-
- The most obvious example of ambiguity is when a command would affect
- the results of another command; for example, a FETCH of a message's
- flags and a STORE of that same message's flags.
-
- A non-obvious ambiguity occurs with commands that permit an untagged
- EXPUNGE response (commands other than FETCH, STORE, and SEARCH),
- since an untagged EXPUNGE response can invalidate sequence numbers in
- a subsequent command. This is not a problem for FETCH, STORE, or
- SEARCH commands because servers are prohibited from sending EXPUNGE
- responses while any of those commands are in progress. Therefore, if
- the client sends any command other than FETCH, STORE, or SEARCH, it
- MUST wait for a response before sending a command with message
- sequence numbers.
-
- For example, the following non-waiting command sequences are invalid:
-
- FETCH + NOOP + STORE
- STORE + COPY + FETCH
- COPY + COPY
- CHECK + FETCH
-
- The following are examples of valid non-waiting command sequences:
-
- FETCH + STORE + SEARCH + CHECK
- STORE + COPY + EXPUNGE
-
-6. Client Commands
-
- IMAP4rev1 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
-
-
-
-Crispin Standards Track [Page 17]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- 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 responses to be returned; these
- are identified by "Responses:" 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 responses 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
-
- Responses: REQUIRED 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 "IMAP4rev1" as one of the listed
- capabilities 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 connection.
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 18]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- A capability name which begins with "AUTH=" indicates that the
- server supports that particular authentication mechanism. All
- such names are, by definition, part of this specification. For
- example, the authorization capability for an experimental
- "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not
- "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP".
-
- Other capability names refer to extensions, revisions, or
- amendments to this specification. See the documentation of the
- CAPABILITY response for additional information. No capabilities,
- beyond the base IMAP4rev1 set defined in this specification, 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 IMAP4rev1 AUTH=KERBEROS_V4
- S: abcd OK CAPABILITY completed
-
-6.1.2. NOOP Command
-
- Arguments: none
-
- Responses: no specific responses 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 Standards Track [Page 19]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-6.1.3. LOGOUT Command
-
- Arguments: none
-
- Responses: REQUIRED 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 connection. 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 IMAP4rev1 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 Standards Track [Page 20]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-6.2.1. AUTHENTICATE Command
-
- Arguments: authentication mechanism name
-
- Responses: continuation data can 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
- client. It MAY also negotiate an OPTIONAL 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 issues 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 connection. 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.
-
- Authentication mechanisms are OPTIONAL. Protection mechanisms are
- also OPTIONAL; an authentication mechanism MAY be implemented
- without any protection mechanism. If an AUTHENTICATE command
- fails with a NO response, the client MAY try another
-
-
-
-Crispin Standards Track [Page 21]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- 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 IMAP4rev1 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
-
- Responses: no specific responses 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 client 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.
-
- 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,
- STATUS, and APPEND.
-
-
-
-
-
-Crispin Standards Track [Page 22]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-6.3.1. SELECT Command
-
- Arguments: mailbox name
-
- Responses: REQUIRED 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. See the description
- of the FLAGS response for more detail.
-
- <n> EXISTS The number of messages in the mailbox. See the
- description of the EXISTS response for more detail.
-
- <n> RECENT The number of messages with the \Recent flag set.
- See the description of the RECENT response for more
- detail.
-
- OK [UIDVALIDITY <n>]
- 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.
-
- 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 can change permanently.
-
- Only one mailbox can be selected at a time in a connection;
- simultaneous access to multiple mailboxes requires multiple
- connections. 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.
-
-
-
-
-Crispin Standards Track [Page 23]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- If the client 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 client 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 server-based .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
-
- Responses: REQUIRED 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 Standards Track [Page 24]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- 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
-
- Responses: no specific responses 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 intends to create
- mailbox names under this name in the hierarchy. Server
- implementations that do not require this declaration MUST ignore
- it.
-
- If the server's hierarchy separator character appears elsewhere in
- the name, the server SHOULD create any superior hierarchical names
- that are needed for the CREATE command to complete successfully.
- In other words, an attempt to create "foo/bar/zap" on a server in
- which "/" is the hierarchy separator character SHOULD create foo/
- and foo/bar/ if they do not already exist.
-
- 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.
-
-
-
-Crispin Standards Track [Page 25]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- Example: C: A003 CREATE owatagusiam/
- S: A003 OK CREATE completed
- C: A004 CREATE owatagusiam/blurdybloop
- S: A004 OK CREATE completed
-
- 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
-
- Responses: no specific responses 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.
-
- The DELETE command MUST NOT remove inferior hierarchical names.
- For example, if a mailbox "foo" has an inferior "foo.bar"
- (assuming "." is the hierarchy delimiter character), removing
- "foo" MUST NOT remove "foo.bar". It is an error to attempt to
- delete a name that has inferior hierarchical names and also has
- the \Noselect mailbox name attribute (see the description of the
- LIST response for more details).
-
- It is permitted to delete a name that has inferior hierarchical
- names and does not have the \Noselect mailbox name attribute. In
- this case, all messages in that mailbox are removed, and the name
- will acquire the \Noselect mailbox name attribute.
-
- The value of the highest-used unique identifier 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.
-
-
-
-
-
-
-Crispin Standards Track [Page 26]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- Examples: C: A682 LIST "" *
- S: * LIST () "/" blurdybloop
- S: * LIST (\Noselect) "/" foo
- S: * LIST () "/" foo/bar
- S: A682 OK LIST completed
- C: A683 DELETE blurdybloop
- S: A683 OK DELETE completed
- C: A684 DELETE foo
- S: A684 NO Name "foo" has inferior hierarchical names
- C: A685 DELETE foo/bar
- S: A685 OK DELETE Completed
- C: A686 LIST "" *
- S: * LIST (\Noselect) "/" foo
- S: A686 OK LIST completed
- C: A687 DELETE foo
- S: A687 OK DELETE Completed
-
-
- C: A82 LIST "" *
- S: * LIST () "." blurdybloop
- S: * LIST () "." foo
- S: * LIST () "." foo.bar
- S: A82 OK LIST completed
- C: A83 DELETE blurdybloop
- S: A83 OK DELETE completed
- C: A84 DELETE foo
- S: A84 OK DELETE Completed
- C: A85 LIST "" *
- S: * LIST () "." foo.bar
- S: A85 OK LIST completed
- C: A86 LIST "" %
- S: * LIST (\Noselect) "." foo
- S: A86 OK LIST completed
-
-6.3.5. RENAME Command
-
- Arguments: existing mailbox name
- new mailbox name
-
- Responses: no specific responses 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
-
- The RENAME command changes the name of a mailbox. A tagged OK
- response is returned only if the mailbox has been renamed. It is
-
-
-
-Crispin Standards Track [Page 27]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- 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.
-
- If the name has inferior hierarchical names, then the inferior
- hierarchical names MUST also be renamed. For example, a rename of
- "foo" to "zap" will rename "foo/bar" (assuming "/" is the
- hierarchy delimiter character) to "zap/bar".
-
- The value of the highest-used unique identifier of the old mailbox
- name 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.
-
- Renaming INBOX is permitted, and has special behavior. It moves
- all messages in INBOX to a new mailbox with the given name,
- leaving INBOX empty. If the server implementation supports
- inferior hierarchical names of INBOX, these are unaffected by a
- rename of INBOX.
-
- Examples: C: A682 LIST "" *
- S: * LIST () "/" blurdybloop
- S: * LIST (\Noselect) "/" foo
- S: * LIST () "/" foo/bar
- S: A682 OK LIST completed
- C: A683 RENAME blurdybloop sarasoop
- S: A683 OK RENAME completed
- C: A684 RENAME foo zowie
- S: A684 OK RENAME Completed
- C: A685 LIST "" *
- S: * LIST () "/" sarasoop
- S: * LIST (\Noselect) "/" zowie
- S: * LIST () "/" zowie/bar
- S: A685 OK LIST completed
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 28]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- C: Z432 LIST "" *
- S: * LIST () "." INBOX
- S: * LIST () "." INBOX.bar
- S: Z432 OK LIST completed
- C: Z433 RENAME INBOX old-mail
- S: Z433 OK RENAME completed
- C: Z434 LIST "" *
- S: * LIST () "." INBOX
- S: * LIST () "." INBOX.bar
- S: * LIST () "." old-mail
- S: Z434 OK LIST completed
-
-6.3.6. SUBSCRIBE Command
-
- Arguments: mailbox
-
- Responses: no specific responses 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.
-
- A server MAY validate the mailbox argument to SUBSCRIBE to verify
- that it exists. However, it MUST NOT unilaterally remove an
- existing mailbox name from the subscription list even if a mailbox
- by that name no longer exists.
-
- Note: this requirement is because some server sites may routinely
- remove a mailbox with a well-known name (e.g. "system-alerts")
- after its contents expire, with the intention of recreating it
- when new contents are appropriate.
-
- Example: C: A002 SUBSCRIBE #news.comp.mail.mime
- S: A002 OK SUBSCRIBE completed
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 29]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-6.3.7. UNSUBSCRIBE Command
-
- Arguments: mailbox name
-
- Responses: no specific responses 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.
-
- 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
-
- Responses: 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 client. 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.
-
- The LIST command SHOULD return its data quickly, without undue
- delay. For example, it SHOULD NOT go to excess trouble to
- calculate \Marked or \Unmarked status or perform other processing;
- if each name requires 1 second of processing, then a list of 1200
- names would take 20 minutes!
-
- 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.
-
-
-
-
-Crispin Standards Track [Page 30]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- An empty ("" string) mailbox name argument is a special request to
- return the hierarchy delimiter and the root name of the name given
- in the reference. The value returned as the root MAY be null if
- the reference is non-rooted or is null. In all cases, the
- hierarchy delimiter is returned. This permits a client to get the
- hierarchy delimiter even when no mailboxes by that name currently
- exist.
-
- 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.
-
- 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 details).
-
-
-
-Crispin Standards Track [Page 31]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- 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
- INBOX is supported by this server for this user and if the
- uppercase string "INBOX" matches the interpreted reference and
- mailbox name arguments with wildcards as described above. 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: A101 LIST "" ""
- S: * LIST (\Noselect) "/" ""
- S: A101 OK LIST Completed
- C: A102 LIST #news.comp.mail.misc ""
- S: * LIST (\Noselect) "." #news.
- S: A102 OK LIST Completed
- C: A103 LIST /usr/staff/jones ""
- S: * LIST (\Noselect) "/" /
- S: A103 OK LIST Completed
- C: A202 LIST ~/Mail/ %
- S: * LIST (\Noselect) "/" ~/Mail/foo
- S: * LIST () "/" ~/Mail/meetings
- S: A202 OK LIST completed
-
-6.3.9. LSUB Command
-
- Arguments: reference name
- mailbox name with possible wildcards
-
- Responses: 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.
-
- A server MAY validate the subscribed names to see if they still
- exist. If a name does not exist, it SHOULD be flagged with the
- \Noselect attribute in the LSUB response. The server MUST NOT
-
-
-
-Crispin Standards Track [Page 32]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- unilaterally remove an existing mailbox name from the subscription
- list even if a mailbox by that name no longer exists.
-
- 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. STATUS Command
-
- Arguments: mailbox name
- status data item names
-
- Responses: untagged responses: STATUS
-
- Result: OK - status completed
- NO - status failure: no status for that name
- BAD - command unknown or arguments invalid
-
- The STATUS command requests the status of the indicated mailbox.
- It does not change the currently selected mailbox, nor does it
- affect the state of any messages in the queried mailbox (in
- particular, STATUS MUST NOT cause messages to lose the \Recent
- flag).
-
- The STATUS command provides an alternative to opening a second
- IMAP4rev1 connection and doing an EXAMINE command on a mailbox to
- query that mailbox's status without deselecting the current
- mailbox in the first IMAP4rev1 connection.
-
- Unlike the LIST command, the STATUS command is not guaranteed to
- be fast in its response. In some implementations, the server is
- obliged to open the mailbox read-only internally to obtain certain
- status information. Also unlike the LIST command, the STATUS
- command does not accept wildcards.
-
- The currently defined status data items that can be requested are:
-
- MESSAGES The number of messages in the mailbox.
-
- RECENT The number of messages with the \Recent flag set.
-
- UIDNEXT The next UID value that will be assigned to a new
- message in the mailbox. It is guaranteed that this
- value will not change unless new messages are added
- to the mailbox; and that it will change when new
- messages are added even if those new messages are
- subsequently expunged.
-
-
-
-Crispin Standards Track [Page 33]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- UIDVALIDITY The unique identifier validity value of the
- mailbox.
-
- UNSEEN The number of messages which do not have the \Seen
- flag set.
-
-
- Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
- S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
- S: A042 OK STATUS completed
-
-6.3.11. APPEND Command
-
- Arguments: mailbox name
- OPTIONAL flag parenthesized list
- OPTIONAL date/time string
- message literal
-
- Responses: no specific responses 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
- to the end of the specified destination mailbox. This argument
- SHOULD be 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 a [MIME-IMB] content
- transfer encoding.
-
- Note: There MAY be exceptions, e.g. draft messages, in which
- required [RFC-822] header lines are omitted in the message literal
- argument to APPEND. The full implications of doing so MUST be
- understood and carefully weighed.
-
- If a flag parenthesized list is specified, the flags SHOULD be set in
- the resulting message; otherwise, the flag list of the resulting
- message is set empty by default.
-
- If a date_time is specified, the internal date SHOULD be set in the
- resulting message; otherwise, the internal date of the resulting
- message is set to the current date and time by default.
-
-
-
-
-
-
-Crispin Standards Track [Page 34]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- 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 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.
-
- If the mailbox is currently selected, the normal new mail actions
- SHOULD occur. Specifically, the server SHOULD notify the client
- immediately via an untagged EXISTS response. If the server does not
- do so, the client MAY issue a NOOP command (or failing that, a CHECK
- command) after one or more APPEND commands.
-
- Example: C: A003 APPEND saved-messages (\Seen) {310}
- C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
- C: From: Fred Foobar <[email protected]>
- C: Subject: afternoon meeting
- C: To: [email protected]
- C: Message-Id: <[email protected]>
- 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, STATUS, and
- APPEND), the following commands are valid in the selected state:
- CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID.
-
-
-
-
-
-
-Crispin Standards Track [Page 35]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-6.4.1. CHECK Command
-
- Arguments: none
-
- Responses: no specific responses 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
-
- Responses: no specific responses 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 if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT
- command MAY be issued without previously issuing a CLOSE command.
- The SELECT, EXAMINE, and LOGOUT commands implicitly close the
- currently selected mailbox without doing an expunge. However,
- when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
-
-
-
-Crispin Standards Track [Page 36]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- 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
-
- Responses: 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.
-
-6.4.4. SEARCH Command
-
- Arguments: OPTIONAL [CHARSET] specification
- searching criteria (one or more)
-
- Responses: REQUIRED untagged response: SEARCH
-
- Result: OK - search completed
- NO - search error: can't search that [CHARSET] or
- criteria
- BAD - command unknown or arguments invalid
-
-
-
-
-
-
-Crispin Standards Track [Page 37]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- 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 can 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-IMB] body parts with
- terminal content media types other than TEXT and MESSAGE from
- consideration in SEARCH matching.
-
- The OPTIONAL [CHARSET] specification consists of the word
- "CHARSET" followed by a registered [CHARSET]. It indicates the
- [CHARSET] of the strings that appear in the search criteria.
- [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
- [RFC-822]/[MIME-IMB] headers, MUST be decoded before comparing
- text in a [CHARSET] other than US-ASCII. US-ASCII MUST be
- supported; other [CHARSET]s MAY be supported. If the server does
- not support the specified [CHARSET], 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.
-
- The defined search keys are as follows. Refer to the Formal
- Syntax section for the precise syntactic definitions of the
- arguments.
-
- <message set> 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 <string> Messages that contain the specified string in the
- envelope structure's BCC field.
-
-
-
-
-Crispin Standards Track [Page 38]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- BEFORE <date> Messages whose internal date is earlier than the
- specified date.
-
- BODY <string> Messages that contain the specified string in the
- body of the message.
-
- CC <string> 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 <string> Messages that contain the specified string in the
- envelope structure's FROM field.
-
- HEADER <field-name> <string>
- 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 <flag> Messages with the specified keyword set.
-
- LARGER <n> Messages with an [RFC-822] 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)".
-
- NOT <search-key>
- 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 <date> Messages whose internal date is within the
- specified date.
-
- OR <search-key1> <search-key2>
- Messages that match either search key.
-
- RECENT Messages that have the \Recent flag set.
-
-
-
-Crispin Standards Track [Page 39]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- SEEN Messages that have the \Seen flag set.
-
- SENTBEFORE <date>
- Messages whose [RFC-822] Date: header is earlier
- than the specified date.
-
- SENTON <date> Messages whose [RFC-822] Date: header is within the
- specified date.
-
- SENTSINCE <date>
- Messages whose [RFC-822] Date: header is within or
- later than the specified date.
-
- SINCE <date> Messages whose internal date is within or later
- than the specified date.
-
- SMALLER <n> Messages with an [RFC-822] size smaller than the
- specified number of octets.
-
- SUBJECT <string>
- Messages that contain the specified string in the
- envelope structure's SUBJECT field.
-
- TEXT <string> Messages that contain the specified string in the
- header or body of the message.
-
- TO <string> Messages that contain the specified string in the
- envelope structure's TO field.
-
- UID <message set>
- Messages with unique identifiers corresponding to
- the specified unique identifier set.
-
- 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 <flag>
- Messages that do not have the specified keyword
- set.
-
- UNSEEN Messages that do not have the \Seen flag set.
-
-
-
-
-
-Crispin Standards Track [Page 40]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- 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
-
- Responses: 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 can 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[<section>]<<partial>>
- 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[<section>]<<partial>>
- An alternate form of BODY[<section>] 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 <flag list>
- 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 <flag list>
- Equivalent to FLAGS, but without returning a new
- value.
-
- +FLAGS <flag list>
- 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 <flag list>
- Equivalent to +FLAGS, but without returning a new
- value.
-
- -FLAGS <flag list>
- 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 <flag list>
- 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<atom> 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