[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[SCM] GNU Mailutils branch, master, updated. rel-2_1-26-gc29efb8
|
From: |
Sergey Poznyakoff |
|
Subject: |
[SCM] GNU Mailutils branch, master, updated. rel-2_1-26-gc29efb8 |
|
Date: |
Tue, 05 Jan 2010 12:56:08 +0000 |
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 <address@hidden>
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 <address@hidden>
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 <address@hidden>
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 <address@hidden>
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 <address@hidden>.
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 <address@hidden> and
dnl Sergey Poznyakoff <address@hidden>
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), address@hidden&*()_=+.,<>/?"'~`{}[]; >
- ; 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: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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
-
- !"address@hidden|}~
-
- 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 <address@hidden>
- To: Ned Freed <address@hidden>
- 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 <address@hidden>
- To: Ned Freed <address@hidden>
- 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="address@hidden"
-
- Content-Type: Message/Partial;
- id="address@hidden";
- number=2
-
- But part 3 MUST specify the total number of parts:
-
- Content-Type: Message/Partial;
- number=3; total=3;
- id="address@hidden"
-
- 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: address@hidden
- To: address@hidden
- Subject: Audio mail
- Message-ID: <address@hidden>
- MIME-Version: 1.0
- Content-type: message/partial;
- id="address@hidden";
- 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: <address@hidden>
- 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: address@hidden
- To: address@hidden
- Subject: Audio mail
- MIME-Version: 1.0
- Message-ID: <address@hidden>
- Content-type: message/partial;
- id="address@hidden"; 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: address@hidden
- To: address@hidden
- Subject: Audio mail
- Message-ID: <address@hidden>
- 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: <address@hidden>
- 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: <address@hidden>
- Content-Type: multipart/alternative; boundary=42
- Content-ID: <address@hidden>
-
- --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: <address@hidden>
-
- --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: <address@hidden>
-
- --42
- Content-Type: message/external-body;
- access-type=mail-server
-
-
-
-Borenstein & Freed [Page 47]
-
-RFC 1521 MIME September 1993
-
-
- server="address@hidden";
- expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
-
- Content-type: application/postscript
- Content-ID: <address@hidden>
-
- 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: address@hidden
-
-
- 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: address@hidden
-
- 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: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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 <address@hidden>
- To: Ned Freed <address@hidden>
- 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: address@hidden
- 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: address@hidden
- 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
- "address@hidden", 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:address@hidden" 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: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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 <address@hidden>. 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://address@hidden/%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://address@hidden/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://address@hidden//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: address@hidden
-
-
-Larry Masinter
-Xerox PARC
-3333 Coyote Hill Road
-Palo Alto, CA 94034
-
-Phone: (415) 812-4365
-Fax: (415) 812-4333
-EMail: address@hidden
-
-
-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: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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:<address@hidden> SIZE=500000
- S: 250 Address Ok.
- C: RCPT TO:<address@hidden>
- S: 250 address@hidden OK; can accomodate 500000 byte message
- C: RCPT TO:<address@hidden>
- S: 552 Channel size limit exceeded: address@hidden
- C: RCPT TO:<address@hidden>
- S: 452 Insufficient channel storage: address@hidden
- 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: address@hidden
-
-
- 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: address@hidden
-
-
- Keith Moore
- Computer Science Dept.
- University of Tennessee
- 107 Ayres Hall
- Knoxville, TN 37996-1301
- USA
-
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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
- <address@hidden>. Requests to subscribe to the mailing
- list should be addressed to <address@hidden>.
- 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 address@hidden and later forwarded to address@hidden, after such
forwarding has
- taken place, the RCPT command will specify a mailbox of address@hidden
- However, the original recipient address remains address@hidden
-
- Also, if the message originated from an environment which does not
- use Internet-style address@hidden 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 address@hidden
- 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 address@hidden to
- address@hidden, address@hidden, address@hidden,
- address@hidden, address@hidden, and address@hidden, 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:<address@hidden> RET=HDRS ENVID=QQ314159
-<<< 250 <address@hidden> sender ok
->>> RCPT TO:<address@hidden> NOTIFY=SUCCESS \
- ORCPT=rfc822;address@hidden
-<<< 250 <address@hidden> recipient ok
->>> RCPT TO:<address@hidden> NOTIFY=FAILURE \
- ORCPT=rfc822;address@hidden
-<<< 250 <address@hidden> recipient ok
->>> RCPT TO:<address@hidden> NOTIFY=SUCCESS,FAILURE \
- ORCPT=rfc822;address@hidden
-<<< 250 <address@hidden> recipient ok
-
-
-
-Moore Standards Track [Page 23]
-
-RFC 1891 SMTP Delivery Status Notifications January 1996
-
-
->>> RCPT TO:<address@hidden> NOTIFY=FAILURE \
- ORCPT=rfc822;address@hidden
-<<< 250 <address@hidden> recipient ok
->>> RCPT TO:<address@hidden> NOTIFY=NEVER
-<<< 250 <address@hidden> recipient ok
->>> RCPT TO:<address@hidden> NOTIFY=FAILURE \
- ORCPT=rfc822;address@hidden
-<<< 250 <address@hidden> 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:<address@hidden> RET=HDRS ENVID=QQ314159
-<<< 250 sender okay
->>> RCPT TO:<address@hidden> NOTIFY=SUCCESS \
- ORCPT=rfc822;address@hidden
-<<< 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:<address@hidden> RET=HDRS ENVID=QQ314159
-<<< 250 ok
->>> RCPT TO:<address@hidden> NOTIFY=FAILURE \
- ORCPT=rfc822;address@hidden
-<<< 550 error - no such recipient
->>> RCPT TO:<address@hidden> NOTIFY=SUCCESS,FAILURE \
- ORCPT=rfc822;address@hidden
-<<< 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
- address@hidden, 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 address@hidden, 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:<address@hidden>
-<<< 250 ok
->>> RCPT TO:<address@hidden>
-<<< 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:<address@hidden>
-<<< 250 ok
->>> DATA
-<<< 354 send message
->>> (message goes here)
->>> .
-<<< 250 message accepted
->>> QUIT
-<<< 221 Bombs.AF.MIL closing connection
-
-10.5 Forward from address@hidden to address@hidden
-
- 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
- address@hidden (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:<address@hidden> RET=HDRS ENVID=QQ314159
-<<< 250 sender okay
->>> RCPT TO:<address@hidden> NOTIFY=SUCCESS \
- ORCPT=rfc822;address@hidden
-<<< 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 address@hidden
-
- MTA mail.Big-Bucks.COM successfully delivers the message to address@hidden
- Bucks.COM. Because the sender specified NOTIFY=SUCCESS, mail.Big-
- Bucks.COM issues the following DSN, and sends it to address@hidden
- Heart.ORG.
-
-To: address@hidden
-From: address@hidden
-Subject: Delivery Notification (success) for address@hidden
-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
address@hidden
-
---abcde
-Content-type: message/delivery-status
-
-Reporting-MTA: dns; mail.Big-Bucks.COM
-Original-Envelope-ID: QQ314159
-
-Original-Recipient: rfc822;address@hidden
-Final-Recipient: rfc822;address@hidden
-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 address@hidden
-
- Because delivery to Carol failed and the sender specified
- NOTIFY=FAILURE for address@hidden, MTA Pure-Heart.ORG (the SMTP
- client to which the failure was reported via SMTP) issues the
- following DSN.
-
-To: address@hidden
-From: address@hidden
-Subject: Delivery Notification (failure) for address@hidden
-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
address@hidden
-
-A transcript of the session follows:
-
-(while talking to Ivory.EDU)
->>> RCPT TO:<address@hidden> 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;address@hidden
-Final-Recipient: rfc822;address@hidden
-SMTP-Remote-Recipient: address@hidden
-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 address@hidden
-
- 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: address@hidden
-From: address@hidden
-Subject: mail relayed for address@hidden
-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 address@hidden) 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;address@hidden
-Final-Recipient: rfc822;address@hidden
-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 address@hidden
-
- The message originally addressed to address@hidden was forwarded
- to address@hidden, 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: address@hidden
-From: address@hidden
-Subject: Delivery failure for address@hidden
-Content-Type: multipart/report; report-type=delivery-status;
- boundary=defgh
-MIME-Version: 1.0
-
---defgh
-Your message, originally addressed to address@hidden, and forwarded
-from there to address@hidden 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;address@hidden
-Final-Recipient: rfc822;address@hidden
-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: address@hidden
-
-
-
-
-
-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: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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
- <address@hidden>. Requests to subscribe to the mailing
- list should be addressed to <address@hidden>.
- 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 <address@hidden>.
-
-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 <address@hidden>
- Message-Id: <address@hidden>
- Subject: Returned mail: Cannot send message for 5 days
- To: <address@hidden>
- 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 address@hidden
-
- ----- The following addresses had delivery problems -----
- <address@hidden> (unrecoverable error)
-
- ----- Transcript of session follows -----
- <address@hidden>... 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;address@hidden
- Final-Recipient: rfc822;address@hidden
- 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 <address@hidden>
- Subject: Returned mail: User unknown
- To: <address@hidden>
- 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 -----
- <address@hidden> (unrecoverable error)
- <address@hidden> (unrecoverable error)
-
- --JAA13167.773673707/CS.UTK.EDU
- content-type: message/delivery-status
-
- Reporting-MTA: dns; cs.utk.edu
-
- Original-Recipient: rfc822;address@hidden
- Final-Recipient: rfc822;address@hidden
- Action: failed
- Status: 5.0.0 (permanent failure)
- Diagnostic-Code: smtp;
- 550 'address@hidden' is not a registered gateway user
- Remote-MTA: dns; vnet.ibm.com
-
- Original-Recipient: rfc822;address@hidden
- Final-Recipient: rfc822;address@hidden
- Action: delayed
- Status: 4.0.0 (hpnjld.njd.jp.com: host name lookup failure)
-
- Original-Recipient: rfc822;address@hidden
- Final-Recipient: rfc822;address@hidden
- 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 <address@hidden>
- Subject: Status of : Re: Battery current sense
- To: address@hidden
- Message-id: <address@hidden>
- 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: <address@hidden>
- Message-Id: <address@hidden>
- Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
- id <address@hidden>;
- Sun, 10 Jul 1994 00:36:51 +0100
- To: address@hidden
- 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:
-
- address@hidden
-
- 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;address@hidden
- 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: address@hidden
- 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: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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:
-
- <address@hidden>
-
- 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 <address@hidden>
- 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
-
- <address@hidden>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 <address@hidden>
- 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: address@hidden
-
-
- Marshall T. Rose
- Dover Beach Consulting, Inc.
- 420 Whisman Court
- Mountain View, CA 94043-2186
-
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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
-
- !"address@hidden|}~
-
- 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: address@hidden
-
-
- Nathaniel S. Borenstein
- First Virtual Holdings
- 25 Washington Avenue
- Morristown, NJ 07960
- USA
-
- Phone: +1 201 540 8967
- Fax: +1 201 993 3032
- EMail: address@hidden
-
-
- 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: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-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 <address@hidden>
- To: Ned Freed <address@hidden>
- 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 <address@hidden>
- To: Ned Freed <address@hidden>
- 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="address@hidden"
-
- Content-Type: Message/Partial;
- id="address@hidden";
- number=2
-
- But the third piece MUST specify the total number of fragments:
-
- Content-Type: Message/Partial; number=3; total=3;
- id="address@hidden"
-
- 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: address@hidden
- To: address@hidden
- Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
- Subject: Audio mail (part 1 of 2)
- Message-ID: <address@hidden>
- MIME-Version: 1.0
- Content-type: message/partial; id="address@hidden";
-
-
-
-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: <address@hidden>
- 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: address@hidden
- To: address@hidden
- Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
- Subject: Audio mail (part 2 of 2)
- MIME-Version: 1.0
- Message-ID: <address@hidden>
- Content-type: message/partial;
- id="address@hidden"; 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: address@hidden
- To: address@hidden
- Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
- Subject: Audio mail
- Message-ID: <address@hidden>
- 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: <address@hidden>
- 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: <address@hidden>
- Content-Type: multipart/alternative; boundary=42
- Content-ID: <address@hidden>
-
- --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: <address@hidden>
-
- --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: <address@hidden>
-
- --42
- Content-Type: message/external-body;
- access-type=mail-server
- server="address@hidden";
- expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
-
- Content-type: application/postscript
- Content-ID: <address@hidden>
-
- 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: address@hidden
-
-
- Nathaniel S. Borenstein
- First Virtual Holdings
- 25 Washington Avenue
- Morristown, NJ 07960
- USA
-
- Phone: +1 201 540 8967
- Fax: +1 201 993 3032
- EMail: address@hidden
-
-
- 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: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-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?= <address@hidden>
- To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <address@hidden>
- CC: =?ISO-8859-1?Q?Andr=E9?= Pirard <address@hidden>
- 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?= <address@hidden>
- To: address@hidden, address@hidden
- Subject: Time for ISO 10646?
-
- To: Dave Crocker <address@hidden>
- Cc: address@hidden, address@hidden
- From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <address@hidden>
- Subject: Re: RFC-HDR care and feeding
-
-
-
-
-
-Moore Standards Track [Page 11]
-
-RFC 2047 Message Header Extensions November 1996
-
-
- From: Nathaniel Borenstein <address@hidden>
- (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=)
- To: Greg Vaudreuil <address@hidden>, Ned Freed
- <address@hidden>, Keith Moore <address@hidden>
- 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: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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: address@hidden
-
- Nathaniel S. Borenstein
- First Virtual Holdings
- 25 Washington Avenue
- Morristown, NJ 07960
- USA
-
- Phone: +1 201 540 8967
- Fax: +1 201 993 3032
- EMail: address@hidden
-
- 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: address@hidden
-
-
-
-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 <address@hidden>
- To: Ned Freed <address@hidden>
- 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 <address@hidden>
- C: Subject: afternoon meeting
- C: To: address@hidden
- C: Message-Id: <address@hidden>
- 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
- indicated by a response code.
-
- The untagged form is also used as one of three possible greetings
- at connection startup. It indicates that the connection is not
- yet authenticated and that a LOGIN command is needed.
-
- Example: S: * OK IMAP4rev1 server ready
- C: A001 LOGIN fred blurdybloop
- S: * OK [ALERT] System shutdown in 10 minutes
- S: A001 OK LOGIN Completed
-
-7.1.2. NO Response
-
- Contents: OPTIONAL response code
- human-readable text
-
- The NO response indicates an operational error message from the
- server. When tagged, it indicates unsuccessful completion of the
- associated command. The untagged form indicates a warning; the
- command can still complete successfully. The human-readable text
- describes the condition.
-
-
-
-Crispin Standards Track [Page 51]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- Example: C: A222 COPY 1:2 owatagusiam
- S: * NO Disk is 98% full, please delete unnecessary data
- S: A222 OK COPY completed
- C: A223 COPY 3:200 blurdybloop
- S: * NO Disk is 98% full, please delete unnecessary data
- S: * NO Disk is 99% full, please delete unnecessary data
- S: A223 NO COPY failed: disk is full
-
-7.1.3. BAD Response
-
- Contents: OPTIONAL response code
- human-readable text
-
- The BAD response indicates an error message from the server. When
- tagged, it reports a protocol-level error in the client's command;
- the tag indicates the command that caused the error. The untagged
- form indicates a protocol-level error for which the associated
- command can not be determined; it can also indicate an internal
- server failure. The human-readable text describes the condition.
-
- Example: C: ...very long command line...
- S: * BAD Command line too long
- C: ...empty line...
- S: * BAD Empty command line
- C: A443 EXPUNGE
- S: * BAD Disk crash, attempting salvage to a new disk!
- S: * OK Salvage successful, no data lost
- S: A443 OK Expunge completed
-
-7.1.4. PREAUTH Response
-
- Contents: OPTIONAL response code
- human-readable text
-
- The PREAUTH response is always untagged, and is one of three
- possible greetings at connection startup. It indicates that the
- connection has already been authenticated by external means and
- thus no LOGIN command is needed.
-
- Example: S: * PREAUTH IMAP4rev1 server logged in as Smith
-
-7.1.5. BYE Response
-
- Contents: OPTIONAL response code
- human-readable text
-
-
-
-
-
-
-Crispin Standards Track [Page 52]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- The BYE response is always untagged, and indicates that the server
- is about to close the connection. The human-readable text MAY be
- displayed to the user in a status report by the client. The BYE
- response is sent under one of four conditions:
-
- 1) as part of a normal logout sequence. The server will close
- the connection after sending the tagged OK response to the
- LOGOUT command.
-
- 2) as a panic shutdown announcement. The server closes the
- connection immediately.
-
- 3) as an announcement of an inactivity autologout. The server
- closes the connection immediately.
-
- 4) as one of three possible greetings at connection startup,
- indicating that the server is not willing to accept a
- connection from this client. The server closes the
- connection immediately.
-
- The difference between a BYE that occurs as part of a normal
- LOGOUT sequence (the first case) and a BYE that occurs because of
- a failure (the other three cases) is that the connection closes
- immediately in the failure case.
-
- Example: S: * BYE Autologout; idle for too long
-
-7.2. Server Responses - Server and Mailbox Status
-
- These responses are always untagged. This is how server and mailbox
- status data are transmitted from the server to the client. Many of
- these responses typically result from a command with the same name.
-
-7.2.1. CAPABILITY Response
-
- Contents: capability listing
-
- The CAPABILITY response occurs as a result of a CAPABILITY
- command. The capability listing contains a space-separated
- listing of capability names that the server supports. The
- capability listing MUST include the atom "IMAP4rev1".
-
- A capability name which begins with "AUTH=" indicates that the
- server supports that particular authentication mechanism.
-
-
-
-
-
-
-
-Crispin Standards Track [Page 53]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- Other capability names indicate that the server supports an
- extension, revision, or amendment to the IMAP4rev1 protocol.
- Server responses MUST conform to this document until the client
- issues a command that uses the associated capability.
-
- Capability names MUST either begin with "X" or be standard or
- standards-track IMAP4rev1 extensions, revisions, or amendments
- registered with IANA. A server MUST NOT offer unregistered or
- non-standard capability names, unless such names are prefixed with
- an "X".
-
- Client implementations SHOULD NOT require any capability name
- other than "IMAP4rev1", and MUST ignore any unknown capability
- names.
-
- Example: S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN
-
-7.2.2. LIST Response
-
- Contents: name attributes
- hierarchy delimiter
- name
-
- The LIST response occurs as a result of a LIST command. It
- returns a single name that matches the LIST specification. There
- can be multiple LIST responses for a single LIST command.
-
- Four name attributes are defined:
-
- \Noinferiors It is not possible for any child levels of
- hierarchy to exist under this name; no child levels
- exist now and none can be created in the future.
-
- \Noselect It is not possible to use this name as a selectable
- mailbox.
-
- \Marked The mailbox has been marked "interesting" by the
- server; the mailbox probably contains messages that
- have been added since the last time the mailbox was
- selected.
-
- \Unmarked The mailbox does not contain any additional
- messages since the last time the mailbox was
- selected.
-
- If it is not feasible for the server to determine whether the
- mailbox is "interesting" or not, or if the name is a \Noselect
- name, the server SHOULD NOT send either \Marked or \Unmarked.
-
-
-
-Crispin Standards Track [Page 54]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- The hierarchy delimiter is a character used to delimit levels of
- hierarchy in a mailbox name. A client can use it to create child
- mailboxes, and to search higher or lower levels of naming
- hierarchy. All children of a top-level hierarchy node MUST use
- the same separator character. A NIL hierarchy delimiter means
- that no hierarchy exists; the name is a "flat" name.
-
- The name represents an unambiguous left-to-right hierarchy, and
- MUST be valid for use as a reference in LIST and LSUB commands.
- Unless \Noselect is indicated, the name MUST also be valid as an
- argument for commands, such as SELECT, that accept mailbox
- names.
-
- Example: S: * LIST (\Noselect) "/" ~/Mail/foo
-
-7.2.3. LSUB Response
-
- Contents: name attributes
- hierarchy delimiter
- name
-
- The LSUB response occurs as a result of an LSUB command. It
- returns a single name that matches the LSUB specification. There
- can be multiple LSUB responses for a single LSUB command. The
- data is identical in format to the LIST response.
-
- Example: S: * LSUB () "." #news.comp.mail.misc
-
-7.2.4 STATUS Response
-
- Contents: name
- status parenthesized list
-
- The STATUS response occurs as a result of an STATUS command. It
- returns the mailbox name that matches the STATUS specification and
- the requested mailbox status information.
-
- Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
-
-7.2.5. SEARCH Response
-
- Contents: zero or more numbers
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 55]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- The SEARCH response occurs as a result of a SEARCH or UID SEARCH
- command. The number(s) refer to those messages that match the
- search criteria. For SEARCH, these are message sequence numbers;
- for UID SEARCH, these are unique identifiers. Each number is
- delimited by a space.
-
- Example: S: * SEARCH 2 3 6
-
-7.2.6. FLAGS Response
-
- Contents: flag parenthesized list
-
- The FLAGS response occurs as a result of a SELECT or EXAMINE
- command. The flag parenthesized list identifies the flags (at a
- minimum, the system-defined flags) that are applicable for this
- mailbox. Flags other than the system flags can also exist,
- depending on server implementation.
-
- The update from the FLAGS response MUST be recorded by the client.
-
- Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
-
-7.3. Server Responses - Mailbox Size
-
- These responses are always untagged. This is how changes in the size
- of the mailbox are trasnmitted from the server to the client.
- Immediately following the "*" token is a number that represents a
- message count.
-
-7.3.1. EXISTS Response
-
- Contents: none
-
- The EXISTS response reports the number of messages in the mailbox.
- This response occurs as a result of a SELECT or EXAMINE command,
- and if the size of the mailbox changes (e.g. new mail).
-
- The update from the EXISTS response MUST be recorded by the
- client.
-
- Example: S: * 23 EXISTS
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 56]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-7.3.2. RECENT Response
-
- Contents: none
-
- The RECENT response reports the number of messages with the
- \Recent flag set. This response occurs as a result of a SELECT or
- EXAMINE command, and if the size of the mailbox changes (e.g. new
- mail).
-
- Note: It is not guaranteed that the message sequence numbers of
- recent messages will be a contiguous range of the highest n
- messages in the mailbox (where n is the value reported by the
- RECENT response). Examples of situations in which this is not
- the case are: multiple clients having the same mailbox open
- (the first session to be notified will see it as recent, others
- will probably see it as non-recent), and when the mailbox is
- re-ordered by a non-IMAP agent.
-
- The only reliable way to identify recent messages is to look at
- message flags to see which have the \Recent flag set, or to do
- a SEARCH RECENT.
-
- The update from the RECENT response MUST be recorded by the
- client.
-
- Example: S: * 5 RECENT
-
-7.4. Server Responses - Message Status
-
- These responses are always untagged. This is how message data are
- transmitted from the server to the client, often as a result of a
- command with the same name. Immediately following the "*" token is a
- number that represents a message sequence number.
-
-7.4.1. EXPUNGE Response
-
- Contents: none
-
- The EXPUNGE response reports that the specified message sequence
- number has been permanently removed from the mailbox. The message
- sequence number for each successive message in the mailbox is
- immediately decremented by 1, and this decrement is reflected in
- message sequence numbers in subsequent responses (including other
- untagged EXPUNGE responses).
-
- As a result of the immediate decrement rule, message sequence
- numbers that appear in a set of successive EXPUNGE responses
- depend upon whether the messages are removed starting from lower
-
-
-
-Crispin Standards Track [Page 57]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- numbers to higher numbers, or from higher numbers to lower
- numbers. For example, if the last 5 messages in a 9-message
- mailbox are expunged; a "lower to higher" server will send five
- untagged EXPUNGE responses for message sequence number 5, whereas
- a "higher to lower server" will send successive untagged EXPUNGE
- responses for message sequence numbers 9, 8, 7, 6, and 5.
-
- An EXPUNGE response MUST NOT be sent when no command is in
- progress; nor while responding to a FETCH, STORE, or SEARCH
- command. This rule is necessary to prevent a loss of
- synchronization of message sequence numbers between client and
- server.
-
- The update from the EXPUNGE response MUST be recorded by the
- client.
-
- Example: S: * 44 EXPUNGE
-
-7.4.2. FETCH Response
-
- Contents: message data
-
- The FETCH response returns data about a message to the client.
- The data are pairs of data item names and their values in
- parentheses. This response occurs as the result of a FETCH or
- STORE command, as well as by unilateral server decision (e.g. flag
- updates).
-
- The current data items are:
-
- BODY A form of BODYSTRUCTURE without extension data.
-
- BODY[<section>]<<origin_octet>>
- A string expressing the body contents of the
- specified section. The string SHOULD be
- interpreted by the client according to the content
- transfer encoding, body type, and subtype.
-
- If the origin octet is specified, this string is a
- substring of the entire body contents, starting at
- that origin octet. This means that BODY[]<0> MAY
- be truncated, but BODY[] is NEVER truncated.
-
- 8-bit textual data is permitted if a [CHARSET]
- identifier is part of the body parameter
- parenthesized list for this section. Note that
- headers (part specifiers HEADER or MIME, or the
- header portion of a MESSAGE/RFC822 part), MUST be
-
-
-
-Crispin Standards Track [Page 58]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- 7-bit; 8-bit characters are not permitted in
- headers. Note also that the blank line at the end
- of the header is always included in header data.
-
- Non-textual data such as binary data MUST be
- transfer encoded into a textual form such as BASE64
- prior to being sent to the client. To derive the
- original binary data, the client MUST decode the
- transfer encoded string.
-
- BODYSTRUCTURE A parenthesized list that describes the [MIME-IMB]
- body structure of a message. This is computed by
- the server by parsing the [MIME-IMB] header fields,
- defaulting various fields as necessary.
-
- For example, a simple text message of 48 lines and
- 2279 octets can have a body structure of: ("TEXT"
- "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279
- 48)
-
- Multiple parts are indicated by parenthesis
- nesting. Instead of a body type as the first
- element of the parenthesized list there is a nested
- body. The second element of the parenthesized list
- is the multipart subtype (mixed, digest, parallel,
- alternative, etc.).
-
- For example, a two part message consisting of a
- text and a BASE645-encoded text attachment can have
- a body structure of: (("TEXT" "PLAIN" ("CHARSET"
- "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN"
- ("CHARSET" "US-ASCII" "NAME" "cc.diff")
- "<address@hidden>"
- "Compiler diff" "BASE64" 4554 73) "MIXED"))
-
- Extension data follows the multipart subtype.
- Extension data is never returned with the BODY
- fetch, but can be returned with a BODYSTRUCTURE
- fetch. Extension data, if present, MUST be in the
- defined order.
-
- The extension data of a multipart body part are in
- the following order:
-
- body parameter parenthesized list
- A parenthesized list of attribute/value pairs
- [e.g. ("foo" "bar" "baz" "rag") where "bar" is
- the value of "foo" and "rag" is the value of
-
-
-
-Crispin Standards Track [Page 59]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- "baz"] as defined in [MIME-IMB].
-
- body disposition
- A parenthesized list, consisting of a
- disposition type string followed by a
- parenthesized list of disposition
- attribute/value pairs. The disposition type and
- attribute names will be defined in a future
- standards-track revision to [DISPOSITION].
-
- body language
- A string or parenthesized list giving the body
- language value as defined in [LANGUAGE-TAGS].
-
- Any following extension data are not yet defined in
- this version of the protocol. Such extension data
- can consist of zero or more NILs, strings, numbers,
- or potentially nested parenthesized lists of such
- data. Client implementations that do a
- BODYSTRUCTURE fetch MUST be prepared to accept such
- extension data. Server implementations MUST NOT
- send such extension data until it has been defined
- by a revision of this protocol.
-
- The basic fields of a non-multipart body part are
- in the following order:
-
- body type
- A string giving the content media type name as
- defined in [MIME-IMB].
-
- body subtype
- A string giving the content subtype name as
- defined in [MIME-IMB].
-
- body parameter parenthesized list
- A parenthesized list of attribute/value pairs
- [e.g. ("foo" "bar" "baz" "rag") where "bar" is
- the value of "foo" and "rag" is the value of
- "baz"] as defined in [MIME-IMB].
-
- body id
- A string giving the content id as defined in
- [MIME-IMB].
-
- body description
- A string giving the content description as
- defined in [MIME-IMB].
-
-
-
-Crispin Standards Track [Page 60]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- body encoding
- A string giving the content transfer encoding as
- defined in [MIME-IMB].
-
- body size
- A number giving the size of the body in octets.
- Note that this size is the size in its transfer
- encoding and not the resulting size after any
- decoding.
-
- A body type of type MESSAGE and subtype RFC822
- contains, immediately after the basic fields, the
- envelope structure, body structure, and size in
- text lines of the encapsulated message.
-
- A body type of type TEXT contains, immediately
- after the basic fields, the size of the body in
- text lines. Note that this size is the size in its
- content transfer encoding and not the resulting
- size after any decoding.
-
- Extension data follows the basic fields and the
- type-specific fields listed above. Extension data
- is never returned with the BODY fetch, but can be
- returned with a BODYSTRUCTURE fetch. Extension
- data, if present, MUST be in the defined order.
-
- The extension data of a non-multipart body part are
- in the following order:
-
- body MD5
- A string giving the body MD5 value as defined in
- [MD5].
-
- body disposition
- A parenthesized list with the same content and
- function as the body disposition for a multipart
- body part.
-
- body language
- A string or parenthesized list giving the body
- language value as defined in [LANGUAGE-TAGS].
-
- Any following extension data are not yet defined in
- this version of the protocol, and would be as
- described above under multipart extension data.
-
-
-
-
-
-Crispin Standards Track [Page 61]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- ENVELOPE A parenthesized list that describes the envelope
- structure of a message. This is computed by the
- server by parsing the [RFC-822] header into the
- component parts, defaulting various fields as
- necessary.
-
- The fields of the envelope structure are in the
- following order: date, subject, from, sender,
- reply-to, to, cc, bcc, in-reply-to, and message-id.
- The date, subject, in-reply-to, and message-id
- fields are strings. The from, sender, reply-to,
- to, cc, and bcc fields are parenthesized lists of
- address structures.
-
- An address structure is a parenthesized list that
- describes an electronic mail address. The fields
- of an address structure are in the following order:
- personal name, [SMTP] at-domain-list (source
- route), mailbox name, and host name.
-
- [RFC-822] group syntax is indicated by a special
- form of address structure in which the host name
- field is NIL. If the mailbox name field is also
- NIL, this is an end of group marker (semi-colon in
- RFC 822 syntax). If the mailbox name field is
- non-NIL, this is a start of group marker, and the
- mailbox name field holds the group name phrase.
-
- Any field of an envelope or address structure that
- is not applicable is presented as NIL. Note that
- the server MUST default the reply-to and sender
- fields from the from field; a client is not
- expected to know to do this.
-
- FLAGS A parenthesized list of flags that are set for this
- message.
-
- INTERNALDATE A string representing the internal date of the
- message.
-
- RFC822 Equivalent to BODY[].
-
- RFC822.HEADER Equivalent to BODY.PEEK[HEADER].
-
- RFC822.SIZE A number expressing the [RFC-822] size of the
- message.
-
- RFC822.TEXT Equivalent to BODY[TEXT].
-
-
-
-Crispin Standards Track [Page 62]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- UID A number expressing the unique identifier of the
- message.
-
-
- Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
-
-7.5. Server Responses - Command Continuation Request
-
- The command continuation request response is indicated by a "+" token
- instead of a tag. This form of response indicates that the server is
- ready to accept the continuation of a command from the client. The
- remainder of this response is a line of text.
-
- This response is used in the AUTHORIZATION command to transmit server
- data to the client, and request additional client data. This
- response is also used if an argument to any command is a literal.
-
- The client is not permitted to send the octets of the literal unless
- the server indicates that it expects it. This permits the server to
- process commands and reject errors on a line-by-line basis. The
- remainder of the command, including the CRLF that terminates a
- command, follows the octets of the literal. If there are any
- additional command arguments the literal octets are followed by a
- space and those arguments.
-
- Example: C: A001 LOGIN {11}
- S: + Ready for additional command text
- C: FRED FOOBAR {7}
- S: + Ready for additional command text
- C: fat man
- S: A001 OK LOGIN completed
- C: A044 BLURDYBLOOP {102856}
- S: A044 BAD No such command as "BLURDYBLOOP"
-
-8. Sample IMAP4rev1 connection
-
- The following is a transcript of an IMAP4rev1 connection. A long
- line in this sample is broken for editorial clarity.
-
-S: * OK IMAP4rev1 Service Ready
-C: a001 login mrc secret
-S: a001 OK LOGIN completed
-C: a002 select inbox
-S: * 18 EXISTS
-S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
-S: * 2 RECENT
-S: * OK [UNSEEN 17] Message 17 is the first unseen message
-S: * OK [UIDVALIDITY 3857529045] UIDs valid
-
-
-
-Crispin Standards Track [Page 63]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-S: a002 OK [READ-WRITE] SELECT completed
-C: a003 fetch 12 full
-S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
- RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
- "IMAP4rev1 WG mtg summary and minutes"
- (("Terry Gray" NIL "gray" "cac.washington.edu"))
- (("Terry Gray" NIL "gray" "cac.washington.edu"))
- (("Terry Gray" NIL "gray" "cac.washington.edu"))
- ((NIL NIL "imap" "cac.washington.edu"))
- ((NIL NIL "minutes" "CNRI.Reston.VA.US")
- ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL
- "<address@hidden>")
- BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))
-S: a003 OK FETCH completed
-C: a004 fetch 12 body[header]
-S: * 12 FETCH (BODY[HEADER] {350}
-S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
-S: From: Terry Gray <address@hidden>
-S: Subject: IMAP4rev1 WG mtg summary and minutes
-S: To: address@hidden
-S: cc: address@hidden, John Klensin <address@hidden>
-S: Message-Id: <address@hidden>
-S: MIME-Version: 1.0
-S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
-S:
-S: )
-S: a004 OK FETCH completed
-C: a005 store 12 +flags \deleted
-S: * 12 FETCH (FLAGS (\Seen \Deleted))
-S: a005 OK +FLAGS completed
-C: a006 logout
-S: * BYE IMAP4rev1 server terminating connection
-S: a006 OK LOGOUT completed
-
-9. Formal Syntax
-
- The following syntax specification uses the augmented Backus-Naur
- Form (BNF) notation as specified in [RFC-822] with one exception; the
- delimiter used with the "#" construct is a single space (SPACE) and
- not one or more commas.
-
- In the case of alternative or optional rules in which a later rule
- overlaps an earlier rule, the rule which is listed earlier MUST take
- priority. For example, "\Seen" when parsed as a flag is the \Seen
- flag name and not a flag_extension, even though "\Seen" could be
- parsed as a flag_extension. Some, but not all, instances of this
- rule are noted below.
-
-
-
-
-Crispin Standards Track [Page 64]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- Except as noted otherwise, all alphabetic characters are case-
- insensitive. The use of upper or lower case characters to define
- token strings is for editorial clarity only. Implementations MUST
- accept these strings in a case-insensitive fashion.
-
-address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox
- SPACE addr_host ")"
-
-addr_adl ::= nstring
- ;; Holds route from [RFC-822] route-addr if
- ;; non-NIL
-
-addr_host ::= nstring
- ;; NIL indicates [RFC-822] group syntax.
- ;; Otherwise, holds [RFC-822] domain name
-
-addr_mailbox ::= nstring
- ;; NIL indicates end of [RFC-822] group; if
- ;; non-NIL and addr_host is NIL, holds
- ;; [RFC-822] group name.
- ;; Otherwise, holds [RFC-822] local-part
-
-addr_name ::= nstring
- ;; Holds phrase from [RFC-822] mailbox if
- ;; non-NIL
-
-alpha ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
- "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
- "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
- "Y" / "Z" /
- "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
- "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
- "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
- "y" / "z"
- ;; Case-sensitive
-
-append ::= "APPEND" SPACE mailbox [SPACE flag_list]
- [SPACE date_time] SPACE literal
-
-astring ::= atom / string
-
-atom ::= 1*ATOM_CHAR
-
-ATOM_CHAR ::= <any CHAR except atom_specials>
-
-atom_specials ::= "(" / ")" / "{" / SPACE / CTL / list_wildcards /
- quoted_specials
-
-
-
-
-Crispin Standards Track [Page 65]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64)
-
-auth_type ::= atom
- ;; Defined by [IMAP-AUTH]
-
-base64 ::= *(4base64_char) [base64_terminal]
-
-base64_char ::= alpha / digit / "+" / "/"
-
-base64_terminal ::= (2base64_char "==") / (3base64_char "=")
-
-body ::= "(" body_type_1part / body_type_mpart ")"
-
-body_extension ::= nstring / number / "(" 1#body_extension ")"
- ;; Future expansion. Client implementations
- ;; MUST accept body_extension fields. Server
- ;; implementations MUST NOT generate
- ;; body_extension fields except as defined by
- ;; future standard or standards-track
- ;; revisions of this specification.
-
-body_ext_1part ::= body_fld_md5 [SPACE body_fld_dsp
- [SPACE body_fld_lang
- [SPACE 1#body_extension]]]
- ;; MUST NOT be returned on non-extensible
- ;; "BODY" fetch
-
-body_ext_mpart ::= body_fld_param
- [SPACE body_fld_dsp SPACE body_fld_lang
- [SPACE 1#body_extension]]
- ;; MUST NOT be returned on non-extensible
- ;; "BODY" fetch
-
-body_fields ::= body_fld_param SPACE body_fld_id SPACE
- body_fld_desc SPACE body_fld_enc SPACE
- body_fld_octets
-
-body_fld_desc ::= nstring
-
-body_fld_dsp ::= "(" string SPACE body_fld_param ")" / nil
-
-body_fld_enc ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
- "QUOTED-PRINTABLE") <">) / string
-
-body_fld_id ::= nstring
-
-body_fld_lang ::= nstring / "(" 1#string ")"
-
-
-
-
-Crispin Standards Track [Page 66]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-body_fld_lines ::= number
-
-body_fld_md5 ::= nstring
-
-body_fld_octets ::= number
-
-body_fld_param ::= "(" 1#(string SPACE string) ")" / nil
-
-body_type_1part ::= (body_type_basic / body_type_msg / body_type_text)
- [SPACE body_ext_1part]
-
-body_type_basic ::= media_basic SPACE body_fields
- ;; MESSAGE subtype MUST NOT be "RFC822"
-
-body_type_mpart ::= 1*body SPACE media_subtype
- [SPACE body_ext_mpart]
-
-body_type_msg ::= media_message SPACE body_fields SPACE envelope
- SPACE body SPACE body_fld_lines
-
-body_type_text ::= media_text SPACE body_fields SPACE body_fld_lines
-
-capability ::= "AUTH=" auth_type / atom
- ;; New capabilities MUST begin with "X" or be
- ;; registered with IANA as standard or
- ;; standards-track
-
-capability_data ::= "CAPABILITY" SPACE [1#capability SPACE] "IMAP4rev1"
- [SPACE 1#capability]
- ;; IMAP4rev1 servers which offer RFC 1730
- ;; compatibility MUST list "IMAP4" as the first
- ;; capability.
-
-CHAR ::= <any 7-bit US-ASCII character except NUL,
- 0x01 - 0x7f>
-
-CHAR8 ::= <any 8-bit octet except NUL, 0x01 - 0xff>
-
-command ::= tag SPACE (command_any / command_auth /
- command_nonauth / command_select) CRLF
- ;; Modal based on state
-
-command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command
- ;; Valid in all states
-
-command_auth ::= append / create / delete / examine / list / lsub /
- rename / select / status / subscribe / unsubscribe
- ;; Valid only in Authenticated or Selected state
-
-
-
-Crispin Standards Track [Page 67]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-command_nonauth ::= login / authenticate
- ;; Valid only when in Non-Authenticated state
-
-command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" /
- copy / fetch / store / uid / search
- ;; Valid only when in Selected state
-
-continue_req ::= "+" SPACE (resp_text / base64)
-
-copy ::= "COPY" SPACE set SPACE mailbox
-
-CR ::= <ASCII CR, carriage return, 0x0D>
-
-create ::= "CREATE" SPACE mailbox
- ;; Use of INBOX gives a NO error
-
-CRLF ::= CR LF
-
-CTL ::= <any ASCII control character and DEL,
- 0x00 - 0x1f, 0x7f>
-
-date ::= date_text / <"> date_text <">
-
-date_day ::= 1*2digit
- ;; Day of month
-
-date_day_fixed ::= (SPACE digit) / 2digit
- ;; Fixed-format version of date_day
-
-date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
- "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
-
-date_text ::= date_day "-" date_month "-" date_year
-
-date_year ::= 4digit
-
-date_time ::= <"> date_day_fixed "-" date_month "-" date_year
- SPACE time SPACE zone <">
-
-delete ::= "DELETE" SPACE mailbox
- ;; Use of INBOX gives a NO error
-
-digit ::= "0" / digit_nz
-
-digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" /
- "9"
-
-
-
-
-
-Crispin Standards Track [Page 68]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-envelope ::= "(" env_date SPACE env_subject SPACE env_from
- SPACE env_sender SPACE env_reply_to SPACE env_to
- SPACE env_cc SPACE env_bcc SPACE env_in_reply_to
- SPACE env_message_id ")"
-
-env_bcc ::= "(" 1*address ")" / nil
-
-env_cc ::= "(" 1*address ")" / nil
-
-env_date ::= nstring
-
-env_from ::= "(" 1*address ")" / nil
-
-env_in_reply_to ::= nstring
-
-env_message_id ::= nstring
-
-env_reply_to ::= "(" 1*address ")" / nil
-
-env_sender ::= "(" 1*address ")" / nil
-
-env_subject ::= nstring
-
-env_to ::= "(" 1*address ")" / nil
-
-examine ::= "EXAMINE" SPACE mailbox
-
-fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" /
- "FAST" / fetch_att / "(" 1#fetch_att ")")
-
-fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
- "RFC822" [".HEADER" / ".SIZE" / ".TEXT"] /
- "BODY" ["STRUCTURE"] / "UID" /
- "BODY" [".PEEK"] section
- ["<" number "." nz_number ">"]
-
-flag ::= "\Answered" / "\Flagged" / "\Deleted" /
- "\Seen" / "\Draft" / flag_keyword / flag_extension
-
-flag_extension ::= "\" atom
- ;; Future expansion. Client implementations
- ;; MUST accept flag_extension flags. Server
- ;; implementations MUST NOT generate
- ;; flag_extension flags except as defined by
- ;; future standard or standards-track
- ;; revisions of this specification.
-
-flag_keyword ::= atom
-
-
-
-Crispin Standards Track [Page 69]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-flag_list ::= "(" #flag ")"
-
-greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF
-
-header_fld_name ::= astring
-
-header_list ::= "(" 1#header_fld_name ")"
-
-LF ::= <ASCII LF, line feed, 0x0A>
-
-list ::= "LIST" SPACE mailbox SPACE list_mailbox
-
-list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string
-
-list_wildcards ::= "%" / "*"
-
-literal ::= "{" number "}" CRLF *CHAR8
- ;; Number represents the number of CHAR8 octets
-
-login ::= "LOGIN" SPACE userid SPACE password
-
-lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox
-
-mailbox ::= "INBOX" / astring
- ;; INBOX is case-insensitive. All case variants of
- ;; INBOX (e.g. "iNbOx") MUST be interpreted as INBOX
- ;; not as an astring. Refer to section 5.1 for
- ;; further semantic details of mailbox names.
-
-mailbox_data ::= "FLAGS" SPACE flag_list /
- "LIST" SPACE mailbox_list /
- "LSUB" SPACE mailbox_list /
- "MAILBOX" SPACE text /
- "SEARCH" [SPACE 1#nz_number] /
- "STATUS" SPACE mailbox SPACE
- "(" #<status_att number ")" /
- number SPACE "EXISTS" / number SPACE "RECENT"
-
-mailbox_list ::= "(" #("\Marked" / "\Noinferiors" /
- "\Noselect" / "\Unmarked" / flag_extension) ")"
- SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox
-
-media_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" /
- "MESSAGE" / "VIDEO") <">) / string)
- SPACE media_subtype
- ;; Defined in [MIME-IMT]
-
-media_message ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <">
-
-
-
-Crispin Standards Track [Page 70]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- ;; Defined in [MIME-IMT]
-
-media_subtype ::= string
- ;; Defined in [MIME-IMT]
-
-media_text ::= <"> "TEXT" <"> SPACE media_subtype
- ;; Defined in [MIME-IMT]
-
-message_data ::= nz_number SPACE ("EXPUNGE" /
- ("FETCH" SPACE msg_att))
-
-msg_att ::= "(" 1#("ENVELOPE" SPACE envelope /
- "FLAGS" SPACE "(" #(flag / "\Recent") ")" /
- "INTERNALDATE" SPACE date_time /
- "RFC822" [".HEADER" / ".TEXT"] SPACE nstring /
- "RFC822.SIZE" SPACE number /
- "BODY" ["STRUCTURE"] SPACE body /
- "BODY" section ["<" number ">"] SPACE nstring /
- "UID" SPACE uniqueid) ")"
-
-nil ::= "NIL"
-
-nstring ::= string / nil
-
-number ::= 1*digit
- ;; Unsigned 32-bit integer
- ;; (0 <= n < 4,294,967,296)
-
-nz_number ::= digit_nz *digit
- ;; Non-zero unsigned 32-bit integer
- ;; (0 < n < 4,294,967,296)
-
-password ::= astring
-
-quoted ::= <"> *QUOTED_CHAR <">
-
-QUOTED_CHAR ::= <any TEXT_CHAR except quoted_specials> /
- "\" quoted_specials
-
-quoted_specials ::= <"> / "\"
-
-rename ::= "RENAME" SPACE mailbox SPACE mailbox
- ;; Use of INBOX as a destination gives a NO error
-
-response ::= *(continue_req / response_data) response_done
-
-response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /
- mailbox_data / message_data / capability_data)
-
-
-
-Crispin Standards Track [Page 71]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- CRLF
-
-response_done ::= response_tagged / response_fatal
-
-response_fatal ::= "*" SPACE resp_cond_bye CRLF
- ;; Server closes connection immediately
-
-response_tagged ::= tag SPACE resp_cond_state CRLF
-
-resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text
- ;; Authentication condition
-
-resp_cond_bye ::= "BYE" SPACE resp_text
-
-resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text
- ;; Status condition
-
-resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text)
- ;; text SHOULD NOT begin with "[" or "="
-
-resp_text_code ::= "ALERT" / "PARSE" /
- "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" /
- "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
- "UIDVALIDITY" SPACE nz_number /
- "UNSEEN" SPACE nz_number /
- atom [SPACE 1*<any TEXT_CHAR except "]">]
-
-search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE]
- 1#search_key
- ;; [CHARSET] MUST be registered with IANA
-
-search_key ::= "ALL" / "ANSWERED" / "BCC" SPACE astring /
- "BEFORE" SPACE date / "BODY" SPACE astring /
- "CC" SPACE astring / "DELETED" / "FLAGGED" /
- "FROM" SPACE astring /
- "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" /
- "ON" SPACE date / "RECENT" / "SEEN" /
- "SINCE" SPACE date / "SUBJECT" SPACE astring /
- "TEXT" SPACE astring / "TO" SPACE astring /
- "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
- "UNKEYWORD" SPACE flag_keyword / "UNSEEN" /
- ;; Above this line were in [IMAP2]
- "DRAFT" /
- "HEADER" SPACE header_fld_name SPACE astring /
- "LARGER" SPACE number / "NOT" SPACE search_key /
- "OR" SPACE search_key SPACE search_key /
- "SENTBEFORE" SPACE date / "SENTON" SPACE date /
- "SENTSINCE" SPACE date / "SMALLER" SPACE number /
-
-
-
-Crispin Standards Track [Page 72]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- "UID" SPACE set / "UNDRAFT" / set /
- "(" 1#search_key ")"
-
-section ::= "[" [section_text / (nz_number *["." nz_number]
- ["." (section_text / "MIME")])] "]"
-
-section_text ::= "HEADER" / "HEADER.FIELDS" [".NOT"]
- SPACE header_list / "TEXT"
-
-select ::= "SELECT" SPACE mailbox
-
-sequence_num ::= nz_number / "*"
- ;; * is the largest number in use. For message
- ;; sequence numbers, it is the number of messages
- ;; in the mailbox. For unique identifiers, it is
- ;; the unique identifier of the last message in
- ;; the mailbox.
-
-set ::= sequence_num / (sequence_num ":" sequence_num) /
- (set "," set)
- ;; Identifies a set of messages. For message
- ;; sequence numbers, these are consecutive
- ;; numbers from 1 to the number of messages in
- ;; the mailbox
- ;; Comma delimits individual numbers, colon
- ;; delimits between two numbers inclusive.
- ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13,
- ;; 14,15 for a mailbox with 15 messages.
-
-SPACE ::= <ASCII SP, space, 0x20>
-
-status ::= "STATUS" SPACE mailbox SPACE "(" 1#status_att ")"
-
-status_att ::= "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" /
- "UNSEEN"
-
-store ::= "STORE" SPACE set SPACE store_att_flags
-
-store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE
- (flag_list / #flag)
-
-string ::= quoted / literal
-
-subscribe ::= "SUBSCRIBE" SPACE mailbox
-
-tag ::= 1*<any ATOM_CHAR except "+">
-
-text ::= 1*TEXT_CHAR
-
-
-
-Crispin Standards Track [Page 73]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-text_mime2 ::= "=?" <charset> "?" <encoding> "?"
- <encoded-text> "?="
- ;; Syntax defined in [MIME-HDRS]
-
-TEXT_CHAR ::= <any CHAR except CR and LF>
-
-time ::= 2digit ":" 2digit ":" 2digit
- ;; Hours minutes seconds
-
-uid ::= "UID" SPACE (copy / fetch / search / store)
- ;; Unique identifiers used instead of message
- ;; sequence numbers
-
-uniqueid ::= nz_number
- ;; Strictly ascending
-
-unsubscribe ::= "UNSUBSCRIBE" SPACE mailbox
-
-userid ::= astring
-
-x_command ::= "X" atom <experimental command arguments>
-
-zone ::= ("+" / "-") 4digit
- ;; Signed four-digit value of hhmm representing
- ;; hours and minutes west of Greenwich (that is,
- ;; (the amount that the given time differs from
- ;; Universal Time). Subtracting the timezone
- ;; from the given time will give the UT form.
- ;; The Universal Time zone is "+0000".
-
-10. Author's Note
-
- This document is a revision or rewrite of earlier documents, and
- supercedes the protocol specification in those documents: RFC 1730,
- unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064.
-
-11. Security Considerations
-
- IMAP4rev1 protocol transactions, including electronic mail data, are
- sent in the clear over the network unless privacy protection is
- negotiated in the AUTHENTICATE command.
-
- A server error message for an AUTHENTICATE command which fails due to
- invalid credentials SHOULD NOT detail why the credentials are
- invalid.
-
- Use of the LOGIN command sends passwords in the clear. This can be
- avoided by using the AUTHENTICATE command instead.
-
-
-
-Crispin Standards Track [Page 74]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- A server error message for a failing LOGIN command SHOULD NOT specify
- that the user name, as opposed to the password, is invalid.
-
- Additional security considerations are discussed in the section
- discussing the AUTHENTICATE and LOGIN commands.
-
-12. Author's Address
-
- Mark R. Crispin
- Networks and Distributed Computing
- University of Washington
- 4545 15th Aveneue NE
- Seattle, WA 98105-4527
-
- Phone: (206) 543-5762
-
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 75]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-Appendices
-
-A. References
-
-[ACAP] Myers, J. "ACAP -- Application Configuration Access Protocol",
-Work in Progress.
-
-[CHARSET] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
-RFC 1700, USC/Information Sciences Institute, October 1994.
-
-[DISPOSITION] Troost, R., and Dorner, S., "Communicating Presentation
-Information in Internet Messages: The Content-Disposition Header",
-RFC 1806, June 1995.
-
-[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731.
-Carnegie-Mellon University, December 1994.
-
-[IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with IMAP2bis", RFC
-2061, University of Washington, November 1996.
-
-[IMAP-DISC] Austein, R., "Synchronization Operations for Disconnected
-IMAP4 Clients", Work in Progress.
-
-[IMAP-HISTORICAL] Crispin, M. "IMAP4 Compatibility with IMAP2 and
-IMAP2bis", RFC 1732, University of Washington, December 1994.
-
-[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in
-IMAP4", RFC 1733, University of Washington, December 1994.
-
-[IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol -
-Obsolete Syntax", RFC 2062, University of Washington, November 1996.
-
-[IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2",
-RFC 1176, University of Washington, August 1990.
-
-[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of
-Languages", RFC 1766, March 1995.
-
-[MD5] Myers, J., and M. Rose, "The Content-MD5 Header Field", RFC
-1864, October 1995.
-
-[MIME-IMB] Freed, N., and N. Borenstein, "MIME (Multipurpose Internet
-Mail Extensions) Part One: Format of Internet Message Bodies", RFC
-2045, November 1996.
-
-[MIME-IMT] Freed, N., and N. Borenstein, "MIME (Multipurpose
-Internet Mail Extensions) Part Two: Media Types", RFC 2046,
-November 1996.
-
-
-
-Crispin Standards Track [Page 76]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-[MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
-Part Three: Message Header Extensions for Non-ASCII Text", RFC
-2047, November 1996.
-
-[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
-Messages", STD 11, RFC 822, University of Delaware, August 1982.
-
-[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10,
-RFC 821, USC/Information Sciences Institute, August 1982.
-
-[UTF-7] Goldsmith, D., and Davis, M., "UTF-7: A Mail-Safe
-Transformation Format of Unicode", RFC 1642, July 1994.
-
-B. Changes from RFC 1730
-
-1) The STATUS command has been added.
-
-2) Clarify in the formal syntax that the "#" construct can never
-refer to multiple spaces.
-
-3) Obsolete syntax has been moved to a separate document.
-
-4) The PARTIAL command has been obsoleted.
-
-5) The RFC822.HEADER.LINES, RFC822.HEADER.LINES.NOT, RFC822.PEEK, and
-RFC822.TEXT.PEEK fetch attributes have been obsoleted.
-
-6) The "<" origin "." size ">" suffix for BODY text attributes has
-been added.
-
-7) The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and TEXT part
-specifiers have been added.
-
-8) Support for Content-Disposition and Content-Language has been
-added.
-
-9) The restriction on fetching nested MULTIPART parts has been
-removed.
-
-10) Body part number 0 has been obsoleted.
-
-11) Server-supported authenticators are now identified by
-capabilities.
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 77]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-12) The capability that identifies this protocol is now called
-"IMAP4rev1". A server that provides backwards support for RFC 1730
-SHOULD emit the "IMAP4" capability in addition to "IMAP4rev1" in its
-CAPABILITY response. Because RFC-1730 required "IMAP4" to appear as
-the first capability, it MUST listed first in the response.
-
-13) A description of the mailbox name namespace convention has been
-added.
-
-14) A description of the international mailbox name convention has
-been added.
-
-15) The UID-NEXT and UID-VALIDITY status items are now called UIDNEXT
-and UIDVALIDITY. This is a change from the IMAP STATUS
-Work in Progress and not from RFC-1730
-
-16) Add a clarification that a null mailbox name argument to the LIST
-command returns an untagged LIST response with the hierarchy
-delimiter and root of the reference argument.
-
-17) Define terms such as "MUST", "SHOULD", and "MUST NOT".
-
-18) Add a section which defines message attributes and more
-thoroughly details the semantics of message sequence numbers, UIDs,
-and flags.
-
-19) Add a clarification detailing the circumstances when a client may
-send multiple commands without waiting for a response, and the
-circumstances in which ambiguities may result.
-
-20) Add a recommendation on server behavior for DELETE and RENAME
-when inferior hierarchical names of the given name exist.
-
-21) Add a clarification that a mailbox name may not be unilaterally
-unsubscribed by the server, even if that mailbox name no longer
-exists.
-
-22) Add a clarification that LIST should return its results quickly
-without undue delay.
-
-23) Add a clarification that the date_time argument to APPEND sets
-the internal date of the message.
-
-24) Add a clarification on APPEND behavior when the target mailbox is
-the currently selected mailbox.
-
-
-
-
-
-
-Crispin Standards Track [Page 78]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
-25) Add a clarification that external changes to flags should be
-always announced via an untagged FETCH even if the current command is
-a STORE with the ".SILENT" suffix.
-
-26) Add a clarification that COPY appends to the target mailbox.
-
-27) Add the NEWNAME response code.
-
-28) Rewrite the description of the untagged BYE response to clarify
-its semantics.
-
-29) Change the reference for the body MD5 to refer to the proper RFC.
-
-30) Clarify that the formal syntax contains rules which may overlap,
-and that in the event of such an overlap the rule which occurs first
-takes precedence.
-
-31) Correct the definition of body_fld_param.
-
-32) More formal syntax for capability_data.
-
-33) Clarify that any case variant of "INBOX" must be interpreted as
-INBOX.
-
-34) Clarify that the human-readable text in resp_text should not
-begin with "[" or "=".
-
-35) Change MIME references to Draft Standard documents.
-
-36) Clarify \Recent semantics.
-
-37) Additional examples.
-
-C. Key Word Index
-
- +FLAGS <flag list> (store command data item) ............... 45
- +FLAGS.SILENT <flag list> (store command data item) ........ 46
- -FLAGS <flag list> (store command data item) ............... 46
- -FLAGS.SILENT <flag list> (store command data item) ........ 46
- ALERT (response code) ...................................... 50
- ALL (fetch item) ........................................... 41
- ALL (search key) ........................................... 38
- ANSWERED (search key) ...................................... 38
- APPEND (command) ........................................... 34
- AUTHENTICATE (command) ..................................... 20
- BAD (response) ............................................. 52
- BCC <string> (search key) .................................. 38
- BEFORE <date> (search key) ................................. 39
-
-
-
-Crispin Standards Track [Page 79]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- BODY (fetch item) .......................................... 41
- BODY (fetch result) ........................................ 58
- BODY <string> (search key) ................................. 39
- BODY.PEEK[<section>]<<partial>> (fetch item) ............... 44
- BODYSTRUCTURE (fetch item) ................................. 44
- BODYSTRUCTURE (fetch result) ............................... 59
- BODY[<section>]<<origin_octet>> (fetch result) ............. 58
- BODY[<section>]<<partial>> (fetch item) .................... 41
- BYE (response) ............................................. 52
- Body Structure (message attribute) ......................... 11
- CAPABILITY (command) ....................................... 18
- CAPABILITY (response) ...................................... 53
- CC <string> (search key) ................................... 39
- CHECK (command) ............................................ 36
- CLOSE (command) ............................................ 36
- COPY (command) ............................................. 46
- CREATE (command) ........................................... 25
- DELETE (command) ........................................... 26
- DELETED (search key) ....................................... 39
- DRAFT (search key) ......................................... 39
- ENVELOPE (fetch item) ...................................... 44
- ENVELOPE (fetch result) .................................... 62
- EXAMINE (command) .......................................... 24
- EXISTS (response) .......................................... 56
- EXPUNGE (command) .......................................... 37
- EXPUNGE (response) ......................................... 57
- Envelope Structure (message attribute) ..................... 11
- FAST (fetch item) .......................................... 44
- FETCH (command) ............................................ 41
- FETCH (response) ........................................... 58
- FLAGGED (search key) ....................................... 39
- FLAGS (fetch item) ......................................... 44
- FLAGS (fetch result) ....................................... 62
- FLAGS (response) ........................................... 56
- FLAGS <flag list> (store command data item) ................ 45
- FLAGS.SILENT <flag list> (store command data item) ......... 45
- FROM <string> (search key) ................................. 39
- FULL (fetch item) .......................................... 44
- Flags (message attribute) .................................. 9
- HEADER (part specifier) .................................... 41
- HEADER <field-name> <string> (search key) .................. 39
- HEADER.FIELDS <header_list> (part specifier) ............... 41
- HEADER.FIELDS.NOT <header_list> (part specifier) ........... 41
- INTERNALDATE (fetch item) .................................. 44
- INTERNALDATE (fetch result) ................................ 62
- Internal Date (message attribute) .......................... 10
- KEYWORD <flag> (search key) ................................ 39
- Keyword (type of flag) ..................................... 10
-
-
-
-Crispin Standards Track [Page 80]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- LARGER <n> (search key) .................................... 39
- LIST (command) ............................................. 30
- LIST (response) ............................................ 54
- LOGIN (command) ............................................ 22
- LOGOUT (command) ........................................... 20
- LSUB (command) ............................................. 32
- LSUB (response) ............................................ 55
- MAY (specification requirement term) ....................... 5
- MESSAGES (status item) ..................................... 33
- MIME (part specifier) ...................................... 42
- MUST (specification requirement term) ...................... 4
- MUST NOT (specification requirement term) .................. 4
- Message Sequence Number (message attribute) ................ 9
- NEW (search key) ........................................... 39
- NEWNAME (response code) .................................... 50
- NO (response) .............................................. 51
- NOOP (command) ............................................. 19
- NOT <search-key> (search key) .............................. 39
- OK (response) .............................................. 51
- OLD (search key) ........................................... 39
- ON <date> (search key) ..................................... 39
- OPTIONAL (specification requirement term) .................. 5
- OR <search-key1> <search-key2> (search key) ................ 39
- PARSE (response code) ...................................... 50
- PERMANENTFLAGS (response code) ............................. 50
- PREAUTH (response) ......................................... 52
- Permanent Flag (class of flag) ............................. 10
- READ-ONLY (response code) .................................. 50
- READ-WRITE (response code) ................................. 50
- RECENT (response) .......................................... 57
- RECENT (search key) ........................................ 39
- RECENT (status item) ....................................... 33
- RENAME (command) ........................................... 27
- REQUIRED (specification requirement term) .................. 4
- RFC822 (fetch item) ........................................ 44
- RFC822 (fetch result) ...................................... 63
- RFC822.HEADER (fetch item) ................................. 44
- RFC822.HEADER (fetch result) ............................... 62
- RFC822.SIZE (fetch item) ................................... 44
- RFC822.SIZE (fetch result) ................................. 62
- RFC822.TEXT (fetch item) ................................... 44
- RFC822.TEXT (fetch result) ................................. 62
- SEARCH (command) ........................................... 37
- SEARCH (response) .......................................... 55
- SEEN (search key) .......................................... 40
- SELECT (command) ........................................... 23
- SENTBEFORE <date> (search key) ............................. 40
- SENTON <date> (search key) ................................. 40
-
-
-
-Crispin Standards Track [Page 81]
-
-RFC 2060 IMAP4rev1 December 1996
-
-
- SENTSINCE <date> (search key) .............................. 40
- SHOULD (specification requirement term) .................... 5
- SHOULD NOT (specification requirement term) ................ 5
- SINCE <date> (search key) .................................. 40
- SMALLER <n> (search key) ................................... 40
- STATUS (command) ........................................... 33
- STATUS (response) .......................................... 55
- STORE (command) ............................................ 45
- SUBJECT <string> (search key) .............................. 40
- SUBSCRIBE (command) ........................................ 29
- Session Flag (class of flag) ............................... 10
- System Flag (type of flag) ................................. 9
- TEXT (part specifier) ...................................... 42
- TEXT <string> (search key) ................................. 40
- TO <string> (search key) ................................... 40
- TRYCREATE (response code) .................................. 51
- UID (command) .............................................. 47
- UID (fetch item) ........................................... 44
- UID (fetch result) ......................................... 63
- UID <message set> (search key) ............................. 40
- UIDNEXT (status item) ...................................... 33
- UIDVALIDITY (response code) ................................ 51
- UIDVALIDITY (status item) .................................. 34
- UNANSWERED (search key) .................................... 40
- UNDELETED (search key) ..................................... 40
- UNDRAFT (search key) ....................................... 40
- UNFLAGGED (search key) ..................................... 40
- UNKEYWORD <flag> (search key) .............................. 40
- UNSEEN (response code) ..................................... 51
- UNSEEN (search key) ........................................ 40
- UNSEEN (status item) ....................................... 34
- UNSUBSCRIBE (command) ...................................... 30
- Unique Identifier (UID) (message attribute) ................ 7
- X<atom> (command) .......................................... 48
- [RFC-822] Size (message attribute) ......................... 11
- \Answered (system flag) .................................... 9
- \Deleted (system flag) ..................................... 9
- \Draft (system flag) ....................................... 9
- \Flagged (system flag) ..................................... 9
- \Marked (mailbox name attribute) ........................... 54
- \Noinferiors (mailbox name attribute) ...................... 54
- \Noselect (mailbox name attribute) ......................... 54
- \Recent (system flag) ...................................... 10
- \Seen (system flag) ........................................ 9
- \Unmarked (mailbox name attribute) ......................... 54
-
-
-
-
-
-
-Crispin Standards Track [Page 82]
-
diff --git a/doc/rfc/rfc2087.txt b/doc/rfc/rfc2087.txt
deleted file mode 100644
index 4518932..0000000
--- a/doc/rfc/rfc2087.txt
+++ /dev/null
@@ -1,284 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Myers
-Request for Comments: 2087 Carnegie Mellon
-Category: Standards Track January 1997
-
-
- IMAP4 QUOTA extension
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-1. Abstract
-
- The QUOTA extension of the Internet Message Access Protocol [IMAP4]
- permits administrative limits on resource usage (quotas) to be
- manipulated through the IMAP protocol.
-
-Table of Contents
-
- 1. Abstract........................................... 1
- 2. Conventions Used in this Document.................. 1
- 3. Introduction and Overview.......................... 2
- 4. Commands........................................... 2
- 4.1. SETQUOTA Command................................... 2
- 4.2. GETQUOTA Command................................... 2
- 4.3. GETQUOTAROOT Command............................... 3
- 5. Responses.......................................... 3
- 5.1. QUOTA Response..................................... 3
- 5.2. QUOTAROOT Response................................. 4
- 6. Formal syntax...................................... 4
- 7. References......................................... 5
- 8. Security Considerations............................ 5
- 9. Author's Address................................... 5
-
-
-2. Conventions Used in this Document
-
- In examples, "C:" and "S:" indicate lines sent by the client and
- server respectively.
-
-
-
-
-
-
-
-
-Myers Standards Track [Page 1]
-
-RFC 2087 QUOTA January 1997
-
-
-3. Introduction and Overview
-
- The QUOTA extension is present in any IMAP4 implementation which
- returns "QUOTA" as one of the supported capabilities to the
- CAPABILITY command.
-
- An IMAP4 server which supports the QUOTA capability may support
- limits on any number of resources. Each resource has an atom name
- and an implementation-defined interpretation which evaluates to an
- integer. Examples of such resources are:
-
- Name Interpretation
-
- STORAGE Sum of messages' RFC822.SIZE, in units of 1024 octets
- MESSAGE Number of messages
-
-
- Each mailbox has zero or more implementation-defined named "quota
- roots". Each quota root has zero or more resource limits. All
- mailboxes that share the same named quota root share the resource
- limits of the quota root.
-
- Quota root names do not necessarily have to match the names of
- existing mailboxes.
-
-4. Commands
-
-4.1. SETQUOTA Command
-
- Arguments: quota root
- list of resource limits
-
- Data: untagged responses: QUOTA
-
- Result: OK - setquota completed
- NO - setquota error: can't set that data
- BAD - command unknown or arguments invalid
-
- The SETQUOTA command takes the name of a mailbox quota root and a
- list of resource limits. The resource limits for the named quota root
- are changed to be the specified limits. Any previous resource limits
- for the named quota root are discarded.
-
- If the named quota root did not previously exist, an implementation
- may optionally create it and change the quota roots for any number of
- existing mailboxes in an implementation-defined manner.
-
-
-
-
-
-Myers Standards Track [Page 2]
-
-RFC 2087 QUOTA January 1997
-
-
- Example: C: A001 SETQUOTA "" (STORAGE 512)
- S: * QUOTA "" (STORAGE 10 512)
- S: A001 OK Setquota completed
-
-4.2. GETQUOTA Command
-
- Arguments: quota root
-
- Data: untagged responses: QUOTA
-
- Result: OK - getquota completed
- NO - getquota error: no such quota root, permission
- denied
- BAD - command unknown or arguments invalid
-
- The GETQUOTA command takes the name of a quota root and returns the
- quota root's resource usage and limits in an untagged QUOTA response.
-
- Example: C: A003 GETQUOTA ""
- S: * QUOTA "" (STORAGE 10 512)
- S: A003 OK Getquota completed
-
-4.3. GETQUOTAROOT Command
-
- Arguments: mailbox name
-
- Data: untagged responses: QUOTAROOT, QUOTA
-
- Result: OK - getquota completed
- NO - getquota error: no such mailbox, permission denied
- BAD - command unknown or arguments invalid
-
- The GETQUOTAROOT command takes the name of a mailbox and returns the
- list of quota roots for the mailbox in an untagged QUOTAROOT
- response. For each listed quota root, it also returns the quota
- root's resource usage and limits in an untagged QUOTA response.
-
- Example: C: A003 GETQUOTAROOT INBOX
- S: * QUOTAROOT INBOX ""
- S: * QUOTA "" (STORAGE 10 512)
- S: A003 OK Getquota completed
-
-
-
-
-
-
-
-
-
-
-Myers Standards Track [Page 3]
-
-RFC 2087 QUOTA January 1997
-
-
-5. Responses
-
-5.1. QUOTA Response
-
- Data: quota root name
- list of resource names, usages, and limits
-
- This response occurs as a result of a GETQUOTA or GETQUOTAROOT
- command. The first string is the name of the quota root for which
- this quota applies.
-
- The name is followed by a S-expression format list of the resource
- usage and limits of the quota root. The list contains zero or
- more triplets. Each triplet conatins a resource name, the current
- usage of the resource, and the resource limit.
-
- Resources not named in the list are not limited in the quota root.
- Thus, an empty list means there are no administrative resource
- limits in the quota root.
-
- Example: S: * QUOTA "" (STORAGE 10 512)
-
-5.2. QUOTAROOT Response
-
- Data: mailbox name
- zero or more quota root names
-
- This response occurs as a result of a GETQUOTAROOT command. The
- first string is the mailbox and the remaining strings are the
- names of the quota roots for the mailbox.
-
- Example: S: * QUOTAROOT INBOX ""
- S: * QUOTAROOT comp.mail.mime
-
-6. Formal syntax
-
- The following syntax specification uses the augmented Backus-Naur
- Form (BNF) notation as specified in RFC 822 with one exception; the
- delimiter used with the "#" construct is a single space (SP) and not
- one or more commas.
-
- 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.
-
-
-
-
-
-
-Myers Standards Track [Page 4]
-
-RFC 2087 QUOTA January 1997
-
-
- getquota ::= "GETQUOTA" SP astring
-
- getquotaroot ::= "GETQUOTAROOT" SP astring
-
- quota_list ::= "(" #quota_resource ")"
-
- quota_resource ::= atom SP number SP number
-
- quota_response ::= "QUOTA" SP astring SP quota_list
-
- quotaroot_response
- ::= "QUOTAROOT" SP astring *(SP astring)
-
- setquota ::= "SETQUOTA" SP astring SP setquota_list
-
- setquota_list ::= "(" 0#setquota_resource ")"
-
- setquota_resource ::= atom SP number
-
-7. References
-
- [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
- RFC 1730, University of Washington, December 1994.
-
- [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
- Text Messages", STD 11, RFC 822.
-
-8. Security Considerations
-
- Implementors should be careful to make sure the implementation of
- these commands does not violate the site's security policy. The
- resource usage of other users is likely to be considered confidential
- information and should not be divulged to unauthorized persons.
-
-9. Author's Address
-
- John G. Myers
- Carnegie-Mellon University
- 5000 Forbes Ave.
- Pittsburgh PA, 15213-3890
-
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-Myers Standards Track [Page 5]
-
-
diff --git a/doc/rfc/rfc2088.txt b/doc/rfc/rfc2088.txt
deleted file mode 100644
index f36cc76..0000000
--- a/doc/rfc/rfc2088.txt
+++ /dev/null
@@ -1,115 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Myers
-Request for Comments: 2088 Carnegie Mellon
-Cateogry: Standards Track January 1997
-
-
- IMAP4 non-synchronizing literals
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-1. Abstract
-
- The Internet Message Access Protocol [IMAP4] contains the "literal"
- syntactic construct for communicating strings. When sending a
- literal from client to server, IMAP4 requires the client to wait for
- the server to send a command continuation request between sending the
- octet count and the string data. This document specifies an
- alternate form of literal which does not require this network round
- trip.
-
-2. Conventions Used in this Document
-
- In examples, "C:" and "S:" indicate lines sent by the client and
- server respectively.
-
-3. Specification
-
- The non-synchronizing literal is added an alternate form of literal,
- and may appear in communication from client to server instead of the
- IMAP4 form of literal. The IMAP4 form of literal, used in
- communication from client to server, is referred to as a
- synchronizing literal.
-
- Non-synchronizing literals may be used with any IMAP4 server
- implementation which returns "LITERAL+" as one of the supported
- capabilities to the CAPABILITY command. If the server does not
- advertise the LITERAL+ capability, the client must use synchronizing
- literals instead.
-
- The non-synchronizing literal is distinguished from the original
- synchronizing literal by having a plus ('+') between the octet count
- and the closing brace ('}'). The server does not generate a command
- continuation request in response to a non-synchronizing literal, and
-
-
-
-Myers Standards Track [Page 1]
-
-RFC 2088 LITERAL January 1997
-
-
- clients are not required to wait before sending the octets of a non-
- synchronizing literal.
-
- The protocol receiver of an IMAP4 server must check the end of every
- received line for an open brace ('{') followed by an octet count, a
- plus ('+'), and a close brace ('}') immediately preceeding the CRLF.
- If it finds this sequence, it is the octet count of a non-
- synchronizing literal and the server MUST treat the specified number
- of following octets and the following line as part of the same
- command. A server MAY still process commands and reject errors on a
- line-by-line basis, as long as it checks for non-synchronizing
- literals at the end of each line.
-
- Example: C: A001 LOGIN {11+}
- C: FRED FOOBAR {7+}
- C: fat man
- S: A001 OK LOGIN completed
-
-4. Formal Syntax
-
- The following syntax specification uses the augmented Backus-Naur
- Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
- Non-terminals referenced but not defined below are as defined by
- [IMAP4].
-
- literal ::= "{" number ["+"] "}" CRLF *CHAR8
- ;; Number represents the number of CHAR8 octets
-
-6. References
-
- [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
- draft-crispin-imap-base-XX.txt, University of Washington, April 1996.
-
- [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
- Messages", STD 11, RFC 822.
-
-7. Security Considerations
-
- There are no known security issues with this extension.
-
-8. Author's Address
-
- John G. Myers
- Carnegie-Mellon University
- 5000 Forbes Ave.
- Pittsburgh PA, 15213-3890
-
- Email: address@hidden
-
-
-
-Myers Standards Track [Page 2]
-
diff --git a/doc/rfc/rfc2111.txt b/doc/rfc/rfc2111.txt
deleted file mode 100644
index 3ccd234..0000000
--- a/doc/rfc/rfc2111.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group E. Levinson
-Request for Comments: 2111 XIson, Inc.
-Category: Standards Track March 1997
-
-
- Content-ID and Message-ID Uniform Resource Locators
-
-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 Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow
- references to messages and the body parts of messages. For example,
- within a single multipart message, one HTML body part might include
- embedded references to other parts of the same message.
-
-1. Introduction
-
- The use of [MIME] within email to convey Web pages and their
- associated images requires a URL scheme to permit the HTML to refer
- to the images or other data included in the message. The Content-ID
- Uniform Resource Locator, "cid:", serves that purpose.
-
- Similarly Net News readers use Message-IDs to link related messages
- together. The Message-ID URL provides a scheme, "mid:", to refer to
- such messages as a "resource".
-
- The "mid" (Message-ID) and "cid" (Content-ID) URL schemes provide
- identifiers for messages and their body parts. The "mid" scheme uses
- (a part of) the message-id of an email message to refer to a specific
- message. The "cid" scheme refers to a specific body part of a
- message; its use is generally limited to references to other body
- parts in the same message as the referring body part. The "mid"
- scheme may also refer to a specific body part within a designated
- message, by including the content-ID's address.
-
- A note on terminology. The terms "body part" and "MIME entity" are
- used interchangeably. They refer to the headers and body of a MIME
- message, either the message itself or one of the body parts contained
- in a Multipart message.
-
-
-
-
-
-Levinson Standards Track [Page 1]
-
-RFC 2111 CID and MID URLs March 1997
-
-
-2. The MID and CID URL Schemes
-
- RFC1738 [URL] reserves the "mid" and "cid" schemes for Message-ID and
- Content-ID respectively. This memorandum defines the syntax for
- those URLs. Because they use the same syntactic elements they are
- presented together.
-
- The URLs take the form
-
- content-id = url-addr-spec
-
- message-id = url-addr-spec
-
- url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec
-
- cid-url = "cid" ":" content-id
-
- mid-url = "mid" ":" message-id [ "/" content-id ]
-
- Note: in Internet mail messages, the addr-spec in a Content-ID
- [MIME] or Message-ID [822] header are enclosed in angle brackets
- (<>). Since addr-spec in a Message-ID or Content-ID might contain
- characters not allowed within a URL; any such character (including
- "/", which is reserved within the "mid" scheme) must be hex-
- encoded using the %hh escape mechanism in [URL].
-
- A "mid" URL with only a "message-id" refers to an entire message.
- With the appended "content-id", it refers to a body part within a
- message, as does a "cid" URL. The Content-ID of a MIME body part is
- required to be globally unique. However, in many systems that store
- messages, body parts are not indexed independently their context
- (message). The "mid" URL long form was designed to supply the
- context needed to support interoperability with such systems.
-
- A implementation conforming to this specification is required to
- support the "mid" URL long form (message-id/content-id). Conforming
- implementations can choose to, but are not required to, take
- advantage of the content-id's uniqueness and interpret a "cid" URL to
- refer to any body part within the message store.
-
- In limited circumstances (e.g., within multipart/alternate), a single
- message may contain several body parts that have the same Content-ID.
- That occurs, for example, when identical data can be accessed through
- different methods [MIME, sect. 7.2.3]. In those cases, conforming
- implementations are required to use the rules of the containing MIME
- entity (e.g., multi-part/alternate) to select the body part to which
- the Content-ID refers.
-
-
-
-
-Levinson Standards Track [Page 2]
-
-RFC 2111 CID and MID URLs March 1997
-
-
- A "cid" URL is converted to the corresponding Content-ID message
- header [MIME] by removing the "cid:" prefix, converting %hh hex-
- escaped characters to their ASCII equivalents and enclosing the
- remaining parts with an angle bracket pair, "<" and ">". For
- example, "mid:address@hidden" corresponds to
-
- Message-ID: <address@hidden>
-
- A "mid" URL is converted to a Message-ID or Message-ID/Content-ID
- pair in a similar fashion.
-
- Both message-id and content-id are required to be globally unique.
- That is, no two different messages will ever have the same Message-ID
- addr-spec; no different body parts will ever have the same Content-ID
- addr-spec. A common technique used by many message systems is to use
- a time and date stamp along with the local host's domain name, e.g.,
- address@hidden
-
-Some Examples
-
- The following message contains an HTML body part that refers to an
- image contained in another body part. Both body parts are contained
- in a Multipart/Related MIME entity. The HTML IMG tag contains a
- cidurl which points to the image.
-
- From: address@hidden
- To: address@hidden
- Subject: A simple example
- Mime-Version: 1.0
- Content-Type: multipart/related; boundary="boundary-example-1";
- type=Text/HTML
-
- --boundary-example 1
- Content-Type: Text/HTML; charset=US-ASCII
-
- ... text of the HTML document, which might contain a hyperlink
- to the other body part, for example through a statement such as:
- <IMG SRC="cid:foo4*foo1@bar.net" ALT="IETF logo">
-
- --boundary-example-1
- Content-ID: address@hidden
- Content-Type: IMAGE/GIF
- Content-Transfer-Encoding: BASE64
-
-
-
-
-
-
-
-
-Levinson Standards Track [Page 3]
-
-RFC 2111 CID and MID URLs March 1997
-
-
- R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
- NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
- etc...
-
- --boundary-example-1--
-
- The following message points to another message (hopefully still in
- the recipient's message store).
-
- From: address@hidden
- To: address@hidden
- Subject: Here's how to do it
- Content-type: text/html; charset=usascii
-
- ... The items in my
- <A HREF= "mid:address@hidden/address@hidden">
- previous message</A>, shows how the approach you propose can be
- used to accomplish ...
-
-3. Security Considerations
-
- The URLs defined here provide an addressing or referencing mechanism.
- The values of these URLs disclose no more about the originators
- environment than the corresponding Message-ID and Content-ID values.
- Where concern exists about such disclosures the originator of a
- message using mid and cid URLs must take precautions to insure that
- confidential information is not disclosed. Those precautions should
- already be in place to handle existing mail use of the Message-ID and
- Content-ID.
-
-4. References
-
-[822] Crocker, D., "Standard for the Format of ARPA Internet Text
- Messages," August 1982, University of Delaware, STD 11, RFC
- 822.
-
-[MIME] N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail
- Extensions) Part One: Mechanisms for Specifying and
- Describing the Format of Internet Message Bodies,"
- September 1993, RFC 1521.
-
-[URL] Berners-Lee, T., Masinter, L., and McCahill, M., "Uniform
- Resource Locators (URL)," December 1994.
-
-[MULREL] E. Levinson, "The MIME Multipart/Related Content-type,"
- December 1995, RFC 1874.
-
-
-
-
-
-Levinson Standards Track [Page 4]
-
-RFC 2111 CID and MID URLs March 1997
-
-
-5. Acknowledgments
-
- The original concept of "mid" and "cid" URLs were part of the Tim
- Berners-Lee's original vision of the World Wide Web. The ideas and
- design have benefited greatly by discussions with Harald Alvestrand,
- Dan Connolly, Roy Fielding, Larry Masinter, Jacob Palme, and others
- in the MHTML working group.
-
-6. Author's Address
-
- Edward Levinson
- 47 Clive Street
- Metuchen, NJ 08840-1060
- USA
- +1 908 549 3716
- <address@hidden>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Levinson Standards Track [Page 5]
-
diff --git a/doc/rfc/rfc2177.txt b/doc/rfc/rfc2177.txt
deleted file mode 100644
index 0c10c77..0000000
--- a/doc/rfc/rfc2177.txt
+++ /dev/null
@@ -1,164 +0,0 @@
-
- Network Working Group
- Request for Comments: 2177
- Category: Standards Track
- B. Leiba
- IBM T.J. Watson Research Center
- June 1997
-
- Page 1
-
- IMAP4 IDLE command
-
- Status of this Memo
- This document specifies an Internet standards track protocol
- for the Internet community, and requests discussion and
- suggestions for improvements. Please refer to the current
- edition of the "Internet Official Protocol Standards" (STD 1)
- for the standardization state and status of this protocol.
- Distribution of this memo is unlimited.
-
- 1 Abstract
- The Internet Message Access Protocol [IMAP4] requires a client
- to poll the server for changes to the selected mailbox (new
- mail, deletions). It's often more desirable to have the server
- transmit updates to the client in real time. This allows a user
- to see new mail immediately. It also helps some real-time
- applications based on IMAP, which might otherwise need to poll
- extremely often (such as every few seconds). (While the spec
- actually does allow a server to push EXISTS responses
- aysynchronously, a client can't expect this behaviour and must
- poll.)
-
- This document specifies the syntax of an IDLE command, which
- will allow a client to tell the server that it's ready to
- accept such real-time updates.
-
- 2 Conventions Used in this Document
- In examples, "C:" and "S:" indicate lines sent by the client
- and server respectively.
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and
- "MAY" in this document are to be interpreted as described in
- RFC 2060 [IMAP4].
-
- 3 Specification
- IDLE Command
-
- Arguments: none
-
- Responses: continuation data will be requested; the client
- sends the continuation data "DONE" to end the command
- __________________________________________________________
-
- Page 2
-
- Result: OK - IDLE completed after client sent "DONE"
- NO - failure: the server will not allow the IDLE
- command at this time
- BAD - command unknown or arguments invalid
-
- The IDLE command may be used with any IMAP4 server
- implementation that returns "IDLE" as one of the supported
- capabilities to the CAPABILITY command. If the server does not
- advertise the IDLE capability, the client MUST NOT use the IDLE
- command and must poll for mailbox updates. In particular, the
- client MUST continue to be able to accept unsolicited untagged
- responses to ANY command, as specified in the base IMAP
- specification.
-
- The IDLE command is sent from the client to the server when the
- client is ready to accept unsolicited mailbox update messages.
- The server requests a response to the IDLE command using the
- continuation ("+") response. The IDLE command remains active
- until the client responds to the continuation, and as long as
- an IDLE command is active, the server is now free to send
- untagged EXISTS, EXPUNGE, and other messages at any time.
-
- The IDLE command is terminated by the receipt of a "DONE"
- continuation from the client; such response satisfies the
- server's continuation request. At that point, the server MAY
- send any remaining queued untagged responses and then MUST
- immediately send the tagged response to the IDLE command and
- prepare to process other commands. As in the base
- specification, the processing of any new command may cause the
- sending of unsolicited untagged responses, subject to the
- ambiguity limitations. The client MUST NOT send a command while
- the server is waiting for the DONE, since the server will not
- be able to distinguish a command from a continuation.
-
- The server MAY consider a client inactive if it has an IDLE
- command running, and if such a server has an inactivity timeout
- it MAY log the client off implicitly at the end of its timeout
- period. Because of that, clients using IDLE are advised to
- terminate the IDLE and re-issue it at least every 29 minutes to
- avoid being logged off. This still allows a client to receive
- immediate mailbox updates even though it need only "poll" at
- half hour intervals.
- __________________________________________________________
-
- Page 3
-
- Example: C: A001 SELECT INBOX
- S: * FLAGS (Deleted Seen)
- S: * 3 EXISTS
- S: * 0 RECENT
- S: * OK [UIDVALIDITY 1]
- S: A001 OK SELECT completed
- C: A002 IDLE
- S: + idling
- ...time passes; new mail arrives...
- S: * 4 EXISTS
- C: DONE
- S: A002 OK IDLE terminated
- ...another client expunges message 2 now...
- C: A003 FETCH 4 ALL
- S: * 4 FETCH (...)
- S: A003 OK FETCH completed
- C: A004 IDLE
- S: * 2 EXPUNGE
- S: * 3 EXISTS
- S: + idling
- ...time passes; another client expunges message 3...
- S: * 3 EXPUNGE
- S: * 2 EXISTS
- ...time passes; new mail arrives...
- S: * 3 EXISTS
- C: DONE
- S: A004 OK IDLE terminated
- C: A005 FETCH 3 ALL
- S: * 3 FETCH (...)
- S: A005 OK FETCH completed
- C: A006 IDLE
-
- 4 Formal Syntax
- The following syntax specification uses the augmented
- Backus-Naur Form (BNF) notation as specified in [RFC-822] as
- modified by [IMAP4]. Non-terminals referenced but not defined
- below are as defined by [IMAP4].
-
- command_auth ::= append / create / delete / examine / list / lsub /
- rename / select / status / subscribe / unsubscribe
- / idle
- ;; Valid only in Authenticated or Selected state
-
- idle ::= "IDLE" CRLF "DONE"
- __________________________________________________________
-
- Page 4
-
- 5 References
- [IMAP4] Crispin, M., "Internet Message Access Protocol -
- Version 4rev1", RFC 2060, December 1996.
-
- 6 Security Considerations
- There are no known security issues with this extension.
-
- 7 Author's Address
- Barry Leiba
- IBM T.J. Watson Research Center
- 30 Saw Mill River Road
- Hawthorne, NY 10532
-
- Email: address@hidden
- __________________________________________________________
diff --git a/doc/rfc/rfc2180.txt b/doc/rfc/rfc2180.txt
deleted file mode 100644
index 5760700..0000000
--- a/doc/rfc/rfc2180.txt
+++ /dev/null
@@ -1,787 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Gahrns
-Request for Comments: 2180 Microsoft
-Category: Informational July 1997
-
-
- IMAP4 Multi-Accessed Mailbox Practice
-
-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.
-
-1. Abstract
-
- IMAP4[RFC-2060] is rich client/server protocol that allows a client
- to access and manipulate electronic mail messages on a server.
- Within the protocol framework, it is possible to have differing
- results for particular client/server interactions. If a protocol does
- not allow for this, it is often unduly restrictive.
-
- For example, when multiple clients are accessing a mailbox and one
- attempts to delete the mailbox, an IMAP4 server may choose to
- implement a solution based upon server architectural constraints or
- individual preference.
-
- With this flexibility comes greater client responsibility. It is not
- sufficient for a client to be written based upon the behavior of a
- particular IMAP server. Rather the client must be based upon the
- behavior allowed by the protocol.
-
- By documenting common IMAP4 server practice for the case of
- simultaneous client access to a mailbox, we hope to ensure the widest
- amount of inter-operation between IMAP4 clients and servers.
-
- The behavior described in this document reflects the practice of some
- existing servers or behavior that the consensus of the IMAP mailing
- list has deemed to be reasonable. The behavior described within this
- document is believed to be [RFC-2060] compliant. However, this
- document is not meant to define IMAP4 compliance, nor is it an
- exhaustive list of valid IMAP4 behavior. [RFC-2060] must always be
- consulted to determine IMAP4 compliance, especially for server
- behavior not described within this document.
-
-
-
-
-
-
-
-
-Gahrns Informational [Page 1]
-
-RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
-
-
-2. Conventions used in this document
-
- In examples,"C1:", "C2:" and "C3:" indicate lines sent by 3 different
- clients (client #1, client #2 and client #3) that are connected to a
- server. "S1:", "S2:" and "S3:" indicated lines sent by the server to
- client #1, client #2 and client #3 respectively.
-
- A shared mailbox, is a mailbox that can be used by multiple users.
-
- A multi-accessed mailbox, is a mailbox that has multiple clients
- simultaneously accessing it.
-
- A client is said to have accessed a mailbox after a successful SELECT
- or EXAMINE command.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC-2119].
-
-
-3. Deletion/Renaming of a multi-accessed mailbox
-
- If an external agent or multiple clients are accessing a mailbox,
- care must be taken when handling the deletion or renaming of the
- mailbox. Following are some strategies an IMAP server may choose to
- use when dealing with this situation.
-
-
-3.1. The server MAY fail the DELETE/RENAME command of a multi-accessed
- mailbox
-
- In some cases, this behavior may not be practical. For example, if a
- large number of clients are accessing a shared mailbox, the window in
- which no clients have the mailbox accessed may be small or non-
- existent, effectively rendering the mailbox undeletable or
- unrenamable.
-
- Example:
-
- <Client #1 and Client #2 have mailbox FOO accessed. Client #1 tries
- to DELETE the mailbox and is refused>
-
- C1: A001 DELETE FOO
- S1: A001 NO Mailbox FOO is in use by another user.
-
-
-
-
-
-
-
-Gahrns Informational [Page 2]
-
-RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
-
-
-3.2. The server MAY allow the DELETE command of a multi-accessed
- mailbox, but keep the information in the mailbox available for
- those clients that currently have access to the mailbox.
-
- When all clients have finished accessing the mailbox, it is
- permanently removed. For clients that do not already have access to
- the mailbox, the 'ghosted' mailbox would not be available. For
- example, it would not be returned to these clients in a subsequent
- LIST or LSUB command and would not be a valid mailbox argument to any
- other IMAP command until the reference count of clients accessing the
- mailbox reached 0.
-
- In some cases, this behavior may not be desirable. For example if
- someone created a mailbox with offensive or sensitive information,
- one might prefer to have the mailbox deleted and all access to the
- information contained within removed immediately, rather than
- continuing to allow access until the client closes the mailbox.
-
- Furthermore, this behavior, may prevent 'recycling' of the same
- mailbox name until all clients have finished accessing the original
- mailbox.
-
- Example:
-
- <Client #1 and Client #2 have mailbox FOO selected. Client #1 DELETEs
- mailbox FOO>
-
- C1: A001 DELETE FOO
- S1: A001 OK Mailbox FOO is deleted.
-
- <Client #2 is still able to operate on the deleted mailbox>
-
- C2: B001 STORE 1 +FLAGS (\Seen)
- S2: * 1 FETCH FLAGS (\Seen)
- S2: B001 OK STORE completed
-
- <Client #3 which did not have access to the mailbox prior to the
- deletion by client #1 does not have access to the mailbox>
-
- C3: C001 STATUS FOO (MESSAGES)
- S3: C001 NO Mailbox does not exist
-
- <Nor is client #3 able to create a mailbox with the name FOO, while
- the reference count is non zero>
-
- C3: C002 CREATE FOO
- S3: C002 NO Mailbox FOO is still in use. Try again later.
-
-
-
-
-Gahrns Informational [Page 3]
-
-RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
-
-
- <Client #2 closes its access to the mailbox, no other clients have
- access to the mailbox FOO and reference count becomes 0>
-
- C2: B002 CLOSE
- S2: B002 OK CLOSE Completed
-
- <Now that the reference count on FOO has reached 0, the mailbox name
- can be recycled>
-
- C3: C003 CREATE FOO
- S3: C003 OK CREATE Completed
-
-
-3.3. The server MAY allow the DELETE/RENAME of a multi-accessed
- mailbox, but disconnect all other clients who have the mailbox
- accessed by sending a untagged BYE response.
-
- A server may often choose to disconnect clients in the DELETE case,
- but may choose to implement a "friendlier" method for the RENAME
- case.
-
- Example:
-
- <Client #1 and Client #2 have mailbox FOO accessed. Client #1 DELETEs
- the mailbox FOO>
-
- C1: A002 DELETE FOO
- S1: A002 OK DELETE completed.
-
- <Server disconnects all other users of the mailbox>
- S2: * BYE Mailbox FOO has been deleted.
-
-
-3.4. The server MAY allow the RENAME of a multi-accessed mailbox by
- simply changing the name attribute on the mailbox.
-
- Other clients that have access to the mailbox can continue issuing
- commands such as FETCH that do not reference the mailbox name.
- Clients would discover the renaming the next time they referred to
- the old mailbox name. Some servers MAY choose to include the
- [NEWNAME] response code in their tagged NO response to a command that
- contained the old mailbox name, as a hint to the client that the
- operation can succeed if the command is issued with the new mailbox
- name.
-
-
-
-
-
-
-
-Gahrns Informational [Page 4]
-
-RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
-
-
- Example:
-
- <Client #1 and Client #2 have mailbox FOO accessed. Client #1 RENAMEs
- the mailbox.>
-
- C1: A001 RENAME FOO BAR
- S1: A001 OK RENAME completed.
-
- <Client #2 is still able to do operations that do not reference the
- mailbox name>
-
- C2: B001 FETCH 2:4 (FLAGS)
- S2: * 2 FETCH . . .
- S2: * 3 FETCH . . .
- S2: * 4 FETCH . . .
- S2: B001 OK FETCH completed
-
- <Client #2 is not able to do operations that reference the mailbox
- name>
-
- C2: B002 APPEND FOO {300} C2: Date: Mon, 7 Feb 1994
- 21:52:25 0800 (PST) C2: . . . S2: B002 NO [NEWNAME FOO
- BAR] Mailbox has been renamed
-
-
-4. Expunging of messages on a multi-accessed mailbox
-
- If an external agent or multiple clients are accessing a mailbox,
- care must be taken when handling the EXPUNGE of messages. Other
- clients accessing the mailbox may be in the midst of issuing a
- command that depends upon message sequence numbers. Because an
- EXPUNGE response can not be sent while responding to a FETCH, STORE
- or SEARCH command, it is not possible to immediately notify the
- client of the EXPUNGE. This can result in ambiguity if the client
- issues a FETCH, STORE or SEARCH operation on a message that has been
- EXPUNGED.
-
-
-4.1. Fetching of expunged messages
-
- Following are some strategies an IMAP server may choose to use when
- dealing with a FETCH command on expunged messages.
-
-
-
-
-
-
-
-
-
-Gahrns Informational [Page 5]
-
-RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
-
-
- Consider the following scenario:
-
- - Client #1 and Client #2 have mailbox FOO selected.
- - There are 7 messages in the mailbox.
- - Messages 4:7 are marked for deletion.
- - Client #1 issues an EXPUNGE, to expunge messages 4:7
-
-
-4.1.1. The server MAY allow the EXPUNGE of a multi-accessed mailbox but
- keep the messages available to satisfy subsequent FETCH commands
- until it is able to send an EXPUNGE response to each client.
-
- In some cases, the behavior of keeping "ghosted" messages may not be
- desirable. For example if a message contained offensive or sensitive
- information, one might prefer to instantaneously remove all access to
- the information, regardless of whether another client is in the midst
- of accessing it.
-
- Example: (Building upon the scenario outlined in 4.1.)
-
- <Client #2 is still able to access the expunged messages because the
- server has kept a 'ghosted' copy of the messages until it is able to
- notify client #2 of the EXPUNGE>
-
- C2: B001 FETCH 4:7 RFC822
- S2: * 4 FETCH RFC822 . . . (RFC822 info returned)
- S2: * 5 FETCH RFC822 . . . (RFC822 info returned)
- S2: * 6 FETCH RFC822 . . . (RFC822 info returned)
- S2: * 7 FETCH RFC822 . . . (RFC822 info returned)
- S2: B001 OK FETCH Completed
-
- <Client #2 issues a command where it can get notified of the EXPUNGE>
-
- C2: B002 NOOP
- S2: * 4 EXPUNGE
- S2: * 4 EXPUNGE
- S2: * 4 EXPUNGE
- S2: * 4 EXPUNGE
- S2: * 3 EXISTS
- S2: B002 OK NOOP Complete
-
- <Client #2 no longer has access to the expunged messages>
-
- C2: B003 FETCH 4:7 RFC822
- S2: B003 NO Messages 4:7 are no longer available.
-
-
-
-
-
-
-Gahrns Informational [Page 6]
-
-RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
-
-
-4.1.2 The server MAY allow the EXPUNGE of a multi-accessed mailbox,
- and on subsequent FETCH commands return FETCH responses only for
- non-expunged messages and a tagged NO.
-
- After receiving a tagged NO FETCH response, the client SHOULD issue a
- NOOP command so that it will be informed of any pending EXPUNGE
- responses. The client may then either reissue the failed FETCH
- command, or by examining the EXPUNGE response from the NOOP and the
- FETCH response from the FETCH, determine that the FETCH failed
- because of pending expunges.
-
- Example: (Building upon the scenario outlined in 4.1.)
-
- <Client #2 attempts to FETCH a mix of expunged and non-expunged
- messages. A FETCH response is returned only for then non-expunged
- messages along with a tagged NO>
-
- C2: B001 FETCH 3:5 ENVELOPE
- S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)
- S2: B001 NO Some of the requested messages no longer exist
-
- <Upon receiving a tagged NO FETCH response, Client #2 issues a NOOP
- to be informed of any pending EXPUNGE responses>
-
- C2: B002 NOOP
- S2: * 4 EXPUNGE
- S2: * 4 EXPUNGE
- S2: * 4 EXPUNGE
- S2: * 4 EXPUNGE
- S2: * 3 EXISTS
- S2: B002 OK NOOP Completed.
-
- <By receiving a FETCH response for message 3, and an EXPUNGE response
- that indicates messages 4:7 have been expunged, the client does not
- need to re-issue the FETCH>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gahrns Informational [Page 7]
-
-RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
-
-
-4.1.3 The server MAY allow the EXPUNGE of a multi-accessed mailbox, and
- on subsequent FETCH commands return the usual FETCH responses for
- non-expunged messages, "NIL FETCH Responses" for expunged
- messages, and a tagged OK response.
-
- If all of the messages in the subsequent FETCH command have been
- expunged, the server SHOULD return only a tagged NO. In this case,
- the client SHOULD issue a NOOP command so that it will be informed of
- any pending EXPUNGE responses. The client may then either reissue
- the failed FETCH command, or by examining the EXPUNGE response from
- the NOOP, determine that the FETCH failed because of pending
- expunges.
-
- "NIL FETCH responses" are a representation of empty data as
- appropriate for the FETCH argument specified.
-
- Example:
-
- * 1 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL))
- * 1 FETCH (FLAGS ())
- * 1 FETCH (INTERNALDATE "00-Jan-0000 00:00:00 +0000")
- * 1 FETCH (RFC822 "")
- * 1 FETCH (RFC822.HEADER "")
- * 1 FETCH (RFC822.TEXT "")
- * 1 FETCH (RFC822.SIZE 0)
- * 1 FETCH (BODY ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
- * 1 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
- * 1 FETCH (BODY[<section>] "")
- * 1 FETCH (BODY[<section>]<partial> "")
-
- In some cases, a client may not be able to distinguish between "NIL
- FETCH responses" received because a message was expunged and those
- received because the data actually was NIL. For example, a * 5
- FETCH (FLAGS ()) response could be received if no flags were set on
- message 5, or because message 5 was expunged. In a case of potential
- ambiguity, the client SHOULD issue a command such as NOOP to force
- the sending of the EXPUNGE responses to resolve any ambiguity.
-
- Example: (Building upon the scenario outlined in 4.1.)
-
- <Client #2 attempts to access a mix of expunged and non-expunged
- messages. Normal data is returned for non-expunged message, "NIL
- FETCH responses" are returned for expunged messages>
-
-
-
-
-
-
-
-
-Gahrns Informational [Page 8]
-
-RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
-
-
- C2: B002 FETCH 3:5 ENVELOPE
- S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)
- S2: * 4 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL
- NIL NIL)
- S2: * 5 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL
- NIL NIL)
- S2: B002 OK FETCH Completed
-
- <Client #2 attempts to FETCH only expunged messages and receives a
- tagged NO response>
-
- C2: B002 FETCH 4:7 ENVELOPE
- S2: B002 NO Messages 4:7 have been expunged.
-
-
-4.1.4 To avoid the situation altogether, the server MAY fail the
- EXPUNGE of a multi-accessed mailbox
-
- In some cases, this behavior may not be practical. For example, if a
- large number of clients are accessing a shared mailbox, the window in
- which no clients have the mailbox accessed may be small or non-
- existent, effectively rendering the message unexpungeable.
-
-
-4.2. Storing of expunged messages
-
- Following are some strategies an IMAP server may choose to use when
- dealing with a STORE command on expunged messages.
-
-
-4.2.1 If the ".SILENT" suffix is used, and the STORE completed
- successfully for all the non-expunged messages, the server SHOULD
- return a tagged OK.
-
- Example: (Building upon the scenario outlined in 4.1.)
-
- <Client #2 tries to silently STORE flags on expunged and non-
- expunged messages. The server sets the flags on the non-expunged
- messages and returns OK>
-
- C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN)
- S2: B001 OK
-
-
-
-
-
-
-
-
-
-Gahrns Informational [Page 9]
-
-RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
-
-
-4.2.2. If the ".SILENT" suffix is not used, and only expunged messages
- are referenced, the server SHOULD return only a tagged NO.
-
- Example: (Building upon the scenario outlined in 4.1.)
-
- <Client #2 tries to STORE flags only on expunged messages>
-
- C2: B001 STORE 5:7 +FLAGS (\SEEN)
- S2: B001 NO Messages have been expunged
-
-
-4.2.3. If the ".SILENT" suffix is not used, and a mixture of expunged
- and non-expunged messages are referenced, the server MAY set the
- flags and return a FETCH response for the non-expunged messages
- along with a tagged NO.
-
- After receiving a tagged NO STORE response, the client SHOULD issue a
- NOOP command so that it will be informed of any pending EXPUNGE
- responses. The client may then either reissue the failed STORE
- command, or by examining the EXPUNGE responses from the NOOP and
- FETCH responses from the STORE, determine that the STORE failed
- because of pending expunges.
-
- Example: (Building upon the scenario outlined in 4.1.)
-
- <Client #2 tries to STORE flags on a mixture of expunged and non-
- expunged messages>
-
- C2: B001 STORE 1:7 +FLAGS (\SEEN)
- S2: * FETCH 1 FLAGS (\SEEN)
- S2: * FETCH 2 FLAGS (\SEEN)
- S2: * FETCH 3 FLAGS (\SEEN)
- S2: B001 NO Some of the messages no longer exist.
-
- C2: B002 NOOP
- S2: * 4 EXPUNGE
- S2: * 4 EXPUNGE
- S2: * 4 EXPUNGE
- S2: * 4 EXPUNGE
- S2: * 3 EXISTS
- S2: B002 OK NOOP Completed.
-
- <By receiving FETCH responses for messages 1:3, and an EXPUNGE
- response that indicates messages 4:7 have been expunged, the client
- does not need to re-issue the STORE>
-
-
-
-
-
-
-Gahrns Informational [Page 10]
-
-RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
-
-
-4.2.4. If the ".SILENT" suffix is not used, and a mixture of expunged
- and non-expunged messages are referenced, the server MAY return
- an untagged NO and not set any flags.
-
- After receiving a tagged NO STORE response, the client SHOULD issue a
- NOOP command so that it will be informed of any pending EXPUNGE
- responses. The client would then re-issue the STORE command after
- updating its message list per any EXPUNGE response.
-
- If a large number of clients are accessing a shared mailbox, the
- window in which there are no pending expunges may be small or non-
- existent, effectively disallowing a client from setting the flags on
- all messages at once.
-
- Example: (Building upon the scenario outlined in 4.1.)
-
- <Client #2 tries to STORE flags on a mixture of expunged and non-
- expunged messages>
-
- C2: B001 STORE 1:7 +FLAGS (\SEEN)
- S2: B001 NO Some of the messages no longer exist.
-
- <Client #2 issues a NOOP to be informed of the EXPUNGED messages>
-
- C2: B002 NOOP
- S2: * 4 EXPUNGE
- S2: * 4 EXPUNGE
- S2: * 4 EXPUNGE
- S2: * 4 EXPUNGE
- S2: * 3 EXISTS
- S2: B002 OK NOOP Completed.
-
- <Client #2 updates its message list and re-issues the STORE on only
- those messages that have not been expunged>
-
- C2: B003 STORE 1:3 +FLAGS (\SEEN) S2: * FETCH 1 FLAGS
- (\SEEN) S2: * FETCH 2 FLAGS (\SEEN) S2: * FETCH 3 FLAGS
- (\SEEN) S2: B003 OK STORE Completed
-
-
-4.3. Searching of expunged messages
-
- A server MAY simply not return a search response for messages that
- have been expunged and it has not been able to inform the client
- about. If a client was expecting a particular message to be returned
- in a search result, and it was not, the client SHOULD issue a NOOP
- command to see if the message was expunged by another client.
-
-
-
-
-Gahrns Informational [Page 11]
-
-RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
-
-
-4.4 Copying of expunged messages
-
- COPY is the only IMAP4 sequence number command that is safe to allow
- an EXPUNGE response on. This is because a client is not permitted to
- cascade several COPY commands together. A client is required to wait
- and confirm that the copy worked before issuing another one.
-
-4.4.1 The server MAY disallow the COPY of messages in a multi-access
- mailbox that contains expunged messages.
-
- Pending EXPUNGE response(s) MUST be returned to the COPY command.
-
- Example:
-
- C: A001 COPY 2,4,6,8 FRED
- S: * 4 EXPUNGE
- S: A001 NO COPY rejected, because some of the requested
- messages were expunged
-
- Note: Non of the above messages are copied because if a COPY command
- is unsuccessful, the server MUST restore the destination mailbox to
- its state before the COPY attempt.
-
-
-4.4.2 The server MAY allow the COPY of messages in a multi-access
- mailbox that contains expunged messages.
-
- Pending EXPUNGE response(s) MUST be returned to the COPY command.
- Messages that are copied are messages corresponding to sequence
- numbers before any EXPUNGE response.
-
- Example:
-
- C: A001 COPY 2,4,6,8 FRED
- S: * 3 EXPUNGE
- S: A001 OK COPY completed
-
- In the above example, the messages that are copied to FRED are
- messages 2,4,6,8 at the start of the COPY command. These are
- equivalent to messages 2,3,5,7 at the end of the COPY command. The
- EXPUNGE response can't take place until after the messages from the
- COPY command are identified (because of the "no expunge while no
- commands in progress" rule).
-
-
-
-
-
-
-
-
-Gahrns Informational [Page 12]
-
-RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
-
-
- Example:
-
- C: A001 COPY 2,4,6,8 FRED
- S: * 4 EXPUNGE
- S: A001 OK COPY completed
-
- In the above example, message 4 was copied before it was expunged,
- and MUST appear in the destination mailbox FRED.
-
-
-5. Security Considerations
-
- This document describes behavior of servers that use the IMAP4
- protocol, and as such, has the same security considerations as
- described in [RFC-2060].
-
- In particular, some described server behavior does not allow for the
- immediate deletion of information when a mailbox is accessed by
- multiple clients. This may be a consideration when dealing with
- sensitive information where immediate deletion would be preferred.
-
-
-6. References
-
- [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
- 4rev1", RFC 2060, University of Washington, December 1996.
-
- [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, Harvard University, March 1997.
-
-
-7. Acknowledgments
-
- This document is the result of discussions on the IMAP4 mailing list
- and is meant to reflect consensus of this group. In particular,
- Raymond Cheng, Mark Crispin, Jim Evans, Erik Forsberg, Steve Hole,
- Mark Keasling, Barry Leiba, Syd Logan, John Mani, Pat Moran, Larry
- Osterman, Chris Newman, Bart Schaefer, Vladimir Vulovic, and Jack De
- Winter were active participants in this discussion or made
- suggestions to this document.
-
-
-
-
-
-
-
-
-
-
-
-Gahrns Informational [Page 13]
-
-RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
-
-
-8. Author's Address
-
- Mike Gahrns
- Microsoft
- One Microsoft Way
- Redmond, WA, 98072
-
- Phone: (206) 936-9833
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gahrns Informational [Page 14]
-
diff --git a/doc/rfc/rfc2192.txt b/doc/rfc/rfc2192.txt
deleted file mode 100644
index 1b5a1d4..0000000
--- a/doc/rfc/rfc2192.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group C. Newman
-Request for Comments: 2192 Innosoft
-Category: Standards Track September 1997
-
-
- IMAP URL Scheme
-
-
-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
-
- IMAP [IMAP4] is a rich protocol for accessing remote message
- stores. It provides an ideal mechanism for accessing public
- mailing list archives as well as private and shared message stores.
- This document defines a URL scheme for referencing objects on an
- IMAP server.
-
-
-1. Conventions used in this document
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
- in this document are to be interpreted as defined in "Key words for
- use in RFCs to Indicate Requirement Levels" [KEYWORDS].
-
-
-2. IMAP scheme
-
- The IMAP URL scheme is used to designate IMAP servers, mailboxes,
- messages, MIME bodies [MIME], and search programs on Internet hosts
- accessible using the IMAP protocol.
-
- The IMAP URL follows the common Internet scheme syntax as defined
- in RFC 1738 [BASIC-URL] except that clear text passwords are not
- permitted. If :<port> is omitted, the port defaults to 143.
-
-
-
-
-
-
-
-
-Newman Standards Track [Page 1]
-
-RFC 2192 IMAP URL Scheme September 1997
-
-
- An IMAP URL takes one of the following forms:
-
- imap://<iserver>/
- imap://<iserver>/<enc_list_mailbox>;TYPE=<list_type>
- imap://<iserver>/<enc_mailbox>[uidvalidity][?<enc_search>]
- imap://<iserver>/<enc_mailbox>[uidvalidity]<iuid>[isection]
-
- The first form is used to refer to an IMAP server, the second form
- refers to a list of mailboxes, the third form refers to the
- contents of a mailbox or a set of messages resulting from a search,
- and the final form refers to a specific message or message part.
- Note that the syntax here is informal. The authoritative formal
- syntax for IMAP URLs is defined in section 11.
-
-
-3. IMAP User Name and Authentication Mechanism
-
- A user name and/or authentication mechanism may be supplied. They
- are used in the "LOGIN" or "AUTHENTICATE" commands after making the
- connection to the IMAP server. If no user name or authentication
- mechanism is supplied, the user name "anonymous" is used with the
- "LOGIN" command and the password is supplied as the Internet e-mail
- address of the end user accessing the resource. If the URL doesn't
- supply a user name, the program interpreting the IMAP URL SHOULD
- request one from the user if necessary.
-
- An authentication mechanism can be expressed by adding
- ";AUTH=<enc_auth_type>" to the end of the user name. When such an
- <enc_auth_type> is indicated, the client SHOULD request appropriate
- credentials from that mechanism and use the "AUTHENTICATE" command
- instead of the "LOGIN" command. If no user name is specified, one
- SHOULD be obtained from the mechanism or requested from the user as
- appropriate.
-
- The string ";AUTH=*" indicates that the client SHOULD select an
- appropriate authentication mechanism. It MAY use any mechanism
- listed in the CAPABILITY command or use an out of band security
- service resulting in a PREAUTH connection. If no user name is
- specified and no appropriate authentication mechanisms are
- available, the client SHOULD fall back to anonymous login as
- described above. This allows a URL which grants read-write access
- to authorized users, and read-only anonymous access to other users.
-
- If a user name is included with no authentication mechanism, then
- ";AUTH=*" is assumed.
-
-
-
-
-
-
-Newman Standards Track [Page 2]
-
-RFC 2192 IMAP URL Scheme September 1997
-
-
- Since URLs can easily come from untrusted sources, care must be
- taken when resolving a URL which requires or requests any sort of
- authentication. If authentication credentials are supplied to the
- wrong server, it may compromise the security of the user's account.
- The program resolving the URL should make sure it meets at least
- one of the following criteria in this case:
-
- (1) The URL comes from a trusted source, such as a referral server
- which the client has validated and trusts according to site policy.
- Note that user entry of the URL may or may not count as a trusted
- source, depending on the experience level of the user and site
- policy.
- (2) Explicit local site policy permits the client to connect to the
- server in the URL. For example, if the client knows the site
- domain name, site policy may dictate that any hostname ending in
- that domain is trusted.
- (3) The user confirms that connecting to that domain name with the
- specified credentials and/or mechanism is permitted.
- (4) A mechanism is used which validates the server before passing
- potentially compromising client credentials.
- (5) An authentication mechanism is used which will not reveal
- information to the server which could be used to compromise future
- connections.
-
- URLs which do not include a user name must be treated with extra
- care, since they are more likely to compromise the user's primary
- account. A URL containing ";AUTH=*" must also be treated with
- extra care since it might fall back on a weaker security mechanism.
- Finally, clients are discouraged from using a plain text password
- as a fallback with ";AUTH=*" unless the connection has strong
- encryption (e.g. a key length of greater than 56 bits).
-
- A program interpreting IMAP URLs MAY cache open connections to an
- IMAP server for later re-use. If a URL contains a user name, only
- connections authenticated as that user may be re-used. If a URL
- does not contain a user name or authentication mechanism, then only
- an anonymous connection may be re-used. If a URL contains an
- authentication mechanism without a user name, then any non-
- anonymous connection may be re-used.
-
- Note that if unsafe or reserved characters such as " " or ";" are
- present in the user name or authentication mechanism, they MUST be
- encoded as described in RFC 1738 [BASIC-URL].
-
-
-
-
-
-
-
-
-Newman Standards Track [Page 3]
-
-RFC 2192 IMAP URL Scheme September 1997
-
-
-4. IMAP server
-
- An IMAP URL referring to an IMAP server has the following form:
-
- imap://<iserver>/
-
- A program interpreting this URL would issue the standard set of
- commands it uses to present a view of the contents of an IMAP
- server. This is likely to be semanticly equivalent to one of the
- following URLs:
-
- imap://<iserver>/;TYPE=LIST
- imap://<iserver>/;TYPE=LSUB
-
- The program interpreting this URL SHOULD use the LSUB form if it
- supports mailbox subscriptions.
-
-
-5. Lists of mailboxes
-
- An IMAP URL referring to a list of mailboxes has the following
- form:
-
- imap://<iserver>/<enc_list_mailbox>;TYPE=<list_type>
-
- The <list_type> may be either "LIST" or "LSUB", and is case
- insensitive. The field ";TYPE=<list_type>" MUST be included.
-
- The <enc_list_mailbox> is any argument suitable for the
- list_mailbox field of the IMAP [IMAP4] LIST or LSUB commands. The
- field <enc_list_mailbox> may be omitted, in which case the program
- interpreting the IMAP URL may use "*" or "%" as the
- <enc_list_mailbox>. The program SHOULD use "%" if it supports a
- hierarchical view, otherwise it SHOULD use "*".
-
- Note that if unsafe or reserved characters such as " " or "%" are
- present in <enc_list_mailbox> they MUST be encoded as described in
- RFC 1738 [BASIC-URL]. If the character "/" is present in
- enc_list_mailbox, it SHOULD NOT be encoded.
-
-
-6. Lists of messages
-
- An IMAP URL referring to a list of messages has the following form:
-
- imap://<iserver>/<enc_mailbox>[uidvalidity][?<enc_search>]
-
-
-
-
-
-Newman Standards Track [Page 4]
-
-RFC 2192 IMAP URL Scheme September 1997
-
-
- The <enc_mailbox> field is used as the argument to the IMAP4
- "SELECT" command. Note that if unsafe or reserved characters such
- as " ", ";", or "?" are present in <enc_mailbox> they MUST be
- encoded as described in RFC 1738 [BASIC-URL]. If the character "/"
- is present in enc_mailbox, it SHOULD NOT be encoded.
-
- The [uidvalidity] field is optional. If it is present, it MUST be
- the argument to the IMAP4 UIDVALIDITY status response at the time
- the URL was created. This SHOULD be used by the program
- interpreting the IMAP URL to determine if the URL is stale.
-
- The [?<enc_search>] field is optional. If it is not present, the
- contents of the mailbox SHOULD be presented by the program
- interpreting the URL. If it is present, it SHOULD be used as the
- arguments following an IMAP4 SEARCH command with unsafe characters
- such as " " (which are likely to be present in the <enc_search>)
- encoded as described in RFC 1738 [BASIC-URL].
-
-
-7. A specific message or message part
-
- An IMAP URL referring to a specific message or message part has the
- following form:
-
- imap://<iserver>/<enc_mailbox>[uidvalidity]<iuid>[isection]
-
- The <enc_mailbox> and [uidvalidity] are as defined above.
-
- If [uidvalidity] is present in this form, it SHOULD be used by the
- program interpreting the URL to determine if the URL is stale.
-
- The <iuid> refers to an IMAP4 message UID, and SHOULD be used as
- the <set> argument to the IMAP4 "UID FETCH" command.
-
- The [isection] field is optional. If not present, the URL refers
- to the entire Internet message as returned by the IMAP command "UID
- FETCH <uid> BODY.PEEK[]". If present, the URL refers to the object
- returned by a "UID FETCH <uid> BODY.PEEK[<section>]" command. The
- type of the object may be determined with a "UID FETCH <uid>
- BODYSTRUCTURE" command and locating the appropriate part in the
- resulting BODYSTRUCTURE. Note that unsafe characters in [isection]
- MUST be encoded as described in [BASIC-URL].
-
-
-
-
-
-
-
-
-
-Newman Standards Track [Page 5]
-
-RFC 2192 IMAP URL Scheme September 1997
-
-
-8. Relative IMAP URLs
-
- Relative IMAP URLs are permitted and are resolved according to the
- rules defined in RFC 1808 [REL-URL] with one exception. In IMAP
- URLs, parameters are treated as part of the normal path with
- respect to relative URL resolution. This is believed to be the
- behavior of the installed base and is likely to be documented in a
- future revision of the relative URL specification.
-
- The following observations are also important:
-
- The <iauth> grammar element is considered part of the user name for
- purposes of resolving relative IMAP URLs. This means that unless a
- new login/server specification is included in the relative URL, the
- authentication mechanism is inherited from a base IMAP URL.
-
- URLs always use "/" as the hierarchy delimiter for the purpose of
- resolving paths in relative URLs. IMAP4 permits the use of any
- hierarchy delimiter in mailbox names. For this reason, relative
- mailbox paths will only work if the mailbox uses "/" as the
- hierarchy delimiter. Relative URLs may be used on mailboxes which
- use other delimiters, but in that case, the entire mailbox name
- MUST be specified in the relative URL or inherited as a whole from
- the base URL.
-
- The base URL for a list of mailboxes or messages which was referred
- to by an IMAP URL is always the referring IMAP URL itself. The
- base URL for a message or message part which was referred to by an
- IMAP URL may be more complicated to determine. The program
- interpreting the relative URL will have to check the headers of the
- MIME entity and any enclosing MIME entities in order to locate the
- "Content-Base" and "Content-Location" headers. These headers are
- used to determine the base URL as defined in [HTTP]. For example,
- if the referring IMAP URL contains a "/;SECTION=1.2" parameter,
- then the MIME headers for section 1.2, for section 1, and for the
- enclosing message itself SHOULD be checked in that order for
- "Content-Base" or "Content-Location" headers.
-
-
-9. Multinational Considerations
-
- IMAP4 [IMAP4] section 5.1.3 includes a convention for encoding
- non-US-ASCII characters in IMAP mailbox names. Because this
- convention is private to IMAP, it is necessary to convert IMAP's
- encoding to one that can be more easily interpreted by a URL
- display program. For this reason, IMAP's modified UTF-7 encoding
- for mailboxes MUST be converted to UTF-8 [UTF8]. Since 8-bit
- characters are not permitted in URLs, the UTF-8 characters are
-
-
-
-Newman Standards Track [Page 6]
-
-RFC 2192 IMAP URL Scheme September 1997
-
-
- encoded as required by the URL specification [BASIC-URL]. Sample
- code is included in Appendix A to demonstrate this conversion.
-
-
-10. Examples
-
- The following examples demonstrate how an IMAP4 client program
- might translate various IMAP4 URLs into a series of IMAP4 commands.
- Commands sent from the client to the server are prefixed with "C:",
- and responses sent from the server to the client are prefixed with
- "S:".
-
- The URL:
-
- <imap://minbari.org/gray-council;UIDVALIDITY=385759045/;UID=20>
-
- Results in the following client commands:
-
- <connect to minbari.org, port 143>
- C: A001 LOGIN ANONYMOUS address@hidden
- C: A002 SELECT gray-council
- <client verifies the UIDVALIDITY matches>
- C: A003 UID FETCH 20 BODY.PEEK[]
-
- The URL:
-
- <imap://address@hidden/users.*;type=list>
-
- Results in the following client commands:
-
- <client requests password from user>
- <connect to minbari.org imap server, activate strong encryption>
- C: A001 LOGIN MICHAEL zipper
- C: A002 LIST "" users.*
-
- The URL:
-
- <imap://psicorp.org/~peter/%E6%97%A5%E6%9C%AC%E8%AA%9E/
- %E5%8F%B0%E5%8C%97>
-
- Results in the following client commands:
-
- <connect to psicorp.org, port 143>
- C: A001 LOGIN ANONYMOUS address@hidden
- C: A002 SELECT ~peter/&ZeVnLIqe-/&U,BTFw-
- <commands the client uses for viewing the contents of a mailbox>
-
-
-
-
-
-Newman Standards Track [Page 7]
-
-RFC 2192 IMAP URL Scheme September 1997
-
-
- The URL:
-
- <imap://;address@hidden/gray-council/;uid=20/
- ;section=1.2>
-
- Results in the following client commands:
-
- <connect to minbari.org, port 143>
- C: A001 AUTHENTICATE KERBEROS_V4
- <authentication exchange>
- C: A002 SELECT gray-council
- C: A003 UID FETCH 20 BODY.PEEK[1.2]
-
- If the following relative URL is located in that body part:
-
- <;section=1.4>
-
- This could result in the following client commands:
-
- C: A004 UID FETCH 20 (BODY.PEEK[1.2.MIME]
- BODY.PEEK[1.MIME]
- BODY.PEEK[HEADER.FIELDS (Content-Base Content-Location)])
- <Client looks for Content-Base or Content-Location headers in
- result. If no such headers, then it does the following>
- C: A005 UID FETCH 20 BODY.PEEK[1.4]
-
- The URL:
-
- <imap://;address@hidden/gray%20council?SUBJECT%20shadows>
-
- Could result in the following:
-
- <connect to minbari.org, port 143>
- C: A001 CAPABILITY
- S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI
- S: A001 OK
- C: A002 AUTHENTICATE GSSAPI
- <authentication exchange>
- S: A002 OK user lennier authenticated
- C: A003 SELECT "gray council"
- ...
- C: A004 SEARCH SUBJECT shadows
- S: * SEARCH 8 10 13 14 15 16
- S: A004 OK SEARCH completed
- C: A005 FETCH 8,10,13:16 ALL
- ...
-
-
-
-
-
-Newman Standards Track [Page 8]
-
-RFC 2192 IMAP URL Scheme September 1997
-
-
- NOTE: In this final example, the client has implementation
- dependent choices. The authentication mechanism could be anything,
- including PREAUTH. And the final FETCH command could fetch more or
- less information about the messages, depending on what it wishes to
- display to the user.
-
-
-11. Security Considerations
-
- Security considerations discussed in the IMAP specification [IMAP4]
- and the URL specification [BASIC-URL] are relevant. Security
- considerations related to authenticated URLs are discussed in
- section 3 of this document.
-
- Many email clients store the plain text password for later use
- after logging into an IMAP server. Such clients MUST NOT use a
- stored password in response to an IMAP URL without explicit
- permission from the user to supply that password to the specified
- host name.
-
-
-12. ABNF for IMAP URL scheme
-
- This uses ABNF as defined in RFC 822 [IMAIL]. Terminals from the
- BNF for IMAP [IMAP4] and URLs [BASIC-URL] are also used. Strings
- are not case sensitive and free insertion of linear-white-space is
- not permitted.
-
- achar = uchar / "&" / "=" / "~"
- ; see [BASIC-URL] for "uchar" definition
-
- bchar = achar / ":" / "@" / "/"
-
- enc_auth_type = 1*achar
- ; encoded version of [IMAP-AUTH] "auth_type"
-
- enc_list_mailbox = 1*bchar
- ; encoded version of [IMAP4] "list_mailbox"
-
- enc_mailbox = 1*bchar
- ; encoded version of [IMAP4] "mailbox"
-
- enc_search = 1*bchar
- ; encoded version of search_program below
-
- enc_section = 1*bchar
- ; encoded version of section below
-
-
-
-
-Newman Standards Track [Page 9]
-
-RFC 2192 IMAP URL Scheme September 1997
-
-
- enc_user = 1*achar
- ; encoded version of [IMAP4] "userid"
-
- imapurl = "imap://" iserver "/" [ icommand ]
-
- iauth = ";AUTH=" ( "*" / enc_auth_type )
-
- icommand = imailboxlist / imessagelist / imessagepart
-
- imailboxlist = [enc_list_mailbox] ";TYPE=" list_type
-
- imessagelist = enc_mailbox [ "?" enc_search ] [uidvalidity]
-
- imessagepart = enc_mailbox [uidvalidity] iuid [isection]
-
- isection = "/;SECTION=" enc_section
-
- iserver = [iuserauth "@"] hostport
- ; See [BASIC-URL] for "hostport" definition
-
- iuid = "/;UID=" nz_number
- ; See [IMAP4] for "nz_number" definition
-
- iuserauth = enc_user [iauth] / [enc_user] iauth
-
- list_type = "LIST" / "LSUB"
-
- search_program = ["CHARSET" SPACE astring SPACE]
- search_key *(SPACE search_key)
- ; IMAP4 literals may not be used
- ; See [IMAP4] for "astring" and "search_key"
-
- section = section_text / (nz_number *["." nz_number]
- ["." (section_text / "MIME")])
- ; See [IMAP4] for "section_text" and "nz_number"
-
- uidvalidity = ";UIDVALIDITY=" nz_number
- ; See [IMAP4] for "nz_number" definition
-
-13. References
-
- [BASIC-URL] Berners-Lee, Masinter, McCahill, "Uniform Resource
- Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of
- Minnesota, December 1994.
-
- <ftp://ds.internic.net/rfc/rfc1738.txt>
-
-
-
-
-
-Newman Standards Track [Page 10]
-
-RFC 2192 IMAP URL Scheme September 1997
-
-
- [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
- 4rev1", RFC 2060, University of Washington, December 1996.
-
- <ftp://ds.internic.net/rfc/rfc2060.txt>
-
- [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731,
- Carnegie-Mellon University, December 1994.
-
- <ftp://ds.internic.net/rfc/rfc1731.txt>
-
- [HTTP] Fielding, Gettys, Mogul, Frystyk, Berners-Lee, "Hypertext
- Transfer Protocol -- HTTP/1.1", RFC 2068, UC Irvine, DEC, MIT/LCS,
- January 1997.
-
- <ftp://ds.internic.net/rfc/rfc2068.txt>
-
- [IMAIL] Crocker, "Standard for the Format of ARPA Internet Text
- Messages", STD 11, RFC 822, University of Delaware, August 1982.
-
- <ftp://ds.internic.net/rfc/rfc822.txt>
-
- [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, Harvard University, March 1997.
-
- <ftp://ds.internic.net/rfc/rfc2119.txt>
-
- [MIME] Freed, N., Borenstein, N., "Multipurpose Internet Mail
- Extensions", RFC 2045, Innosoft, First Virtual, November 1996.
-
- <ftp://ds.internic.net/rfc/rfc2045.txt>
-
- [REL-URL] Fielding, "Relative Uniform Resource Locators", RFC 1808,
- UC Irvine, June 1995.
-
- <ftp://ds.internic.net/rfc/rfc1808.txt>
-
- [UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and
- ISO 10646", RFC 2044, Alis Technologies, October 1996.
-
- <ftp://ds.internic.net/rfc/rfc2044.txt>
-
-14. Author's Address
-
- Chris Newman
- Innosoft International, Inc.
- 1050 Lakes Drive
- West Covina, CA 91790 USA
- EMail: address@hidden
-
-
-
-Newman Standards Track [Page 11]
-
-RFC 2192 IMAP URL Scheme September 1997
-
-
-Appendix A. Sample code
-
-Here is sample C source code to convert between URL paths and IMAP
-mailbox names, taking into account mapping between IMAP's modified UTF-7
-[IMAP4] and hex-encoded UTF-8 which is more appropriate for URLs. This
-code has not been rigorously tested nor does it necessarily behave
-reasonably with invalid input, but it should serve as a useful example.
-This code just converts the mailbox portion of the URL and does not deal
-with parameters, query or server components of the URL.
-
-#include <stdio.h>
-#include <string.h>
-
-/* hexadecimal lookup table */
-static char hex[] = "0123456789ABCDEF";
-
-/* URL unsafe printable characters */
-static char urlunsafe[] = " \"#%&+:;<=>address@hidden|}";
-
-/* UTF7 modified base64 alphabet */
-static char base64chars[] =
- "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+,";
-#define UNDEFINED 64
-
-/* UTF16 definitions */
-#define UTF16MASK 0x03FFUL
-#define UTF16SHIFT 10
-#define UTF16BASE 0x10000UL
-#define UTF16HIGHSTART 0xD800UL
-#define UTF16HIGHEND 0xDBFFUL
-#define UTF16LOSTART 0xDC00UL
-#define UTF16LOEND 0xDFFFUL
-
-/* Convert an IMAP mailbox to a URL path
- * dst needs to have roughly 4 times the storage space of src
- * Hex encoding can triple the size of the input
- * UTF-7 can be slightly denser than UTF-8
- * (worst case: 8 octets UTF-7 becomes 9 octets UTF-8)
- */
-void MailboxToURL(char *dst, char *src)
-{
- unsigned char c, i, bitcount;
- unsigned long ucs4, utf16, bitbuf;
- unsigned char base64[256], utf8[6];
-
-
-
-
-
-
-
-Newman Standards Track [Page 12]
-
-RFC 2192 IMAP URL Scheme September 1997
-
-
- /* initialize modified base64 decoding table */
- memset(base64, UNDEFINED, sizeof (base64));
- for (i = 0; i < sizeof (base64chars); ++i) {
- base64[base64chars[i]] = i;
- }
-
- /* loop until end of string */
- while (*src != '\0') {
- c = *src++;
- /* deal with literal characters and &- */
- if (c != '&' || *src == '-') {
- if (c < ' ' || c > '~' || strchr(urlunsafe, c) != NULL) {
- /* hex encode if necessary */
- dst[0] = '%';
- dst[1] = hex[c >> 4];
- dst[2] = hex[c & 0x0f];
- dst += 3;
- } else {
- /* encode literally */
- *dst++ = c;
- }
- /* skip over the '-' if this is an &- sequence */
- if (c == '&') ++src;
- } else {
- /* convert modified UTF-7 -> UTF-16 -> UCS-4 -> UTF-8 -> HEX */
- bitbuf = 0;
- bitcount = 0;
- ucs4 = 0;
- while ((c = base64[(unsigned char) *src]) != UNDEFINED) {
- ++src;
- bitbuf = (bitbuf << 6) | c;
- bitcount += 6;
- /* enough bits for a UTF-16 character? */
- if (bitcount >= 16) {
- bitcount -= 16;
- utf16 = (bitcount ? bitbuf >> bitcount
- : bitbuf) & 0xffff;
- /* convert UTF16 to UCS4 */
- if
- (utf16 >= UTF16HIGHSTART && utf16 <= UTF16HIGHEND) {
- ucs4 = (utf16 - UTF16HIGHSTART) << UTF16SHIFT;
- continue;
- } else if
- (utf16 >= UTF16LOSTART && utf16 <= UTF16LOEND) {
- ucs4 += utf16 - UTF16LOSTART + UTF16BASE;
- } else {
- ucs4 = utf16;
- }
-
-
-
-Newman Standards Track [Page 13]
-
-RFC 2192 IMAP URL Scheme September 1997
-
-
- /* convert UTF-16 range of UCS4 to UTF-8 */
- if (ucs4 <= 0x7fUL) {
- utf8[0] = ucs4;
- i = 1;
- } else if (ucs4 <= 0x7ffUL) {
- utf8[0] = 0xc0 | (ucs4 >> 6);
- utf8[1] = 0x80 | (ucs4 & 0x3f);
- i = 2;
- } else if (ucs4 <= 0xffffUL) {
- utf8[0] = 0xe0 | (ucs4 >> 12);
- utf8[1] = 0x80 | ((ucs4 >> 6) & 0x3f);
- utf8[2] = 0x80 | (ucs4 & 0x3f);
- i = 3;
- } else {
- utf8[0] = 0xf0 | (ucs4 >> 18);
- utf8[1] = 0x80 | ((ucs4 >> 12) & 0x3f);
- utf8[2] = 0x80 | ((ucs4 >> 6) & 0x3f);
- utf8[3] = 0x80 | (ucs4 & 0x3f);
- i = 4;
- }
- /* convert utf8 to hex */
- for (c = 0; c < i; ++c) {
- dst[0] = '%';
- dst[1] = hex[utf8[c] >> 4];
- dst[2] = hex[utf8[c] & 0x0f];
- dst += 3;
- }
- }
- }
- /* skip over trailing '-' in modified UTF-7 encoding */
- if (*src == '-') ++src;
- }
- }
- /* terminate destination string */
- *dst = '\0';
-}
-
-/* Convert hex coded UTF-8 URL path to modified UTF-7 IMAP mailbox
- * dst should be about twice the length of src to deal with non-hex
- * coded URLs
- */
-void URLtoMailbox(char *dst, char *src)
-{
- unsigned int utf8pos, utf8total, i, c, utf7mode, bitstogo, utf16flag;
- unsigned long ucs4, bitbuf;
- unsigned char hextab[256];
-
- /* initialize hex lookup table */
-
-
-
-Newman Standards Track [Page 14]
-
-RFC 2192 IMAP URL Scheme September 1997
-
-
- memset(hextab, 0, sizeof (hextab));
- for (i = 0; i < sizeof (hex); ++i) {
- hextab[hex[i]] = i;
- if (isupper(hex[i])) hextab[tolower(hex[i])] = i;
- }
-
- utf7mode = 0;
- utf8total = 0;
- bitstogo = 0;
- while ((c = *src) != '\0') {
- ++src;
- /* undo hex-encoding */
- if (c == '%' && src[0] != '\0' && src[1] != '\0') {
- c = (hextab[src[0]] << 4) | hextab[src[1]];
- src += 2;
- }
- /* normal character? */
- if (c >= ' ' && c <= '~') {
- /* switch out of UTF-7 mode */
- if (utf7mode) {
- if (bitstogo) {
- *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F];
- }
- *dst++ = '-';
- utf7mode = 0;
- }
- *dst++ = c;
- /* encode '&' as '&-' */
- if (c == '&') {
- *dst++ = '-';
- }
- continue;
- }
- /* switch to UTF-7 mode */
- if (!utf7mode) {
- *dst++ = '&';
- utf7mode = 1;
- }
- /* Encode US-ASCII characters as themselves */
- if (c < 0x80) {
- ucs4 = c;
- utf8total = 1;
- } else if (utf8total) {
- /* save UTF8 bits into UCS4 */
- ucs4 = (ucs4 << 6) | (c & 0x3FUL);
- if (++utf8pos < utf8total) {
- continue;
- }
-
-
-
-Newman Standards Track [Page 15]
-
-RFC 2192 IMAP URL Scheme September 1997
-
-
- } else {
- utf8pos = 1;
- if (c < 0xE0) {
- utf8total = 2;
- ucs4 = c & 0x1F;
- } else if (c < 0xF0) {
- utf8total = 3;
- ucs4 = c & 0x0F;
- } else {
- /* NOTE: can't convert UTF8 sequences longer than 4 */
- utf8total = 4;
- ucs4 = c & 0x03;
- }
- continue;
- }
- /* loop to split ucs4 into two utf16 chars if necessary */
- utf8total = 0;
- do {
- if (ucs4 >= UTF16BASE) {
- ucs4 -= UTF16BASE;
- bitbuf = (bitbuf << 16) | ((ucs4 >> UTF16SHIFT)
- + UTF16HIGHSTART);
- ucs4 = (ucs4 & UTF16MASK) + UTF16LOSTART;
- utf16flag = 1;
- } else {
- bitbuf = (bitbuf << 16) | ucs4;
- utf16flag = 0;
- }
- bitstogo += 16;
- /* spew out base64 */
- while (bitstogo >= 6) {
- bitstogo -= 6;
- *dst++ = base64chars[(bitstogo ? (bitbuf >> bitstogo)
- : bitbuf)
- & 0x3F];
- }
- } while (utf16flag);
- }
- /* if in UTF-7 mode, finish in ASCII */
- if (utf7mode) {
- if (bitstogo) {
- *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F];
- }
- *dst++ = '-';
- }
- /* tie off string */
- *dst = '\0';
-}
-
-
-
-Newman Standards Track [Page 16]
-
diff --git a/doc/rfc/rfc2193.txt b/doc/rfc/rfc2193.txt
deleted file mode 100644
index 2fec58d..0000000
--- a/doc/rfc/rfc2193.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Gahrns
-Request for Comments: 2193 Microsoft
-Category: Standards Track September 1997
-
-
- IMAP4 Mailbox Referrals
-
-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
-
- When dealing with large amounts of users, messages and geographically
- dispersed IMAP4 [RFC-2060] servers, it is often desirable to
- distribute messages amongst different servers within an organization.
- For example an administrator may choose to store user's personal
- mailboxes on a local IMAP4 server, while storing shared mailboxes
- remotely on another server. This type of configuration is common
- when it is uneconomical to store all data centrally due to limited
- bandwidth or disk resources.
-
- Mailbox referrals allow clients to seamlessly access mailboxes that
- are distributed across several IMAP4 servers.
-
- A referral mechanism can provide efficiencies over the alternative
- "proxy method", in which the local IMAP4 server contacts the remote
- server on behalf of the client, and then transfers the data from the
- remote server to itself, and then on to the client. The referral
- mechanism's direct client connection to the remote server is often a
- more efficient use of bandwidth, and does not require the local
- server to impersonate the client when authenticating to the remote
- server.
-
-2. Conventions used in this document
-
- In examples, "C:" and "S:" indicate lines sent by the client and
- server respectively.
-
- A home server, is an IMAP4 server that contains the user's inbox.
-
- A remote mailbox is a mailbox that is not hosted on the user's home
- server.
-
-
-
-
-Gahrns Standards Track [Page 1]
-
-RFC 2193 IMAP4 Mailbox Referrals September 1997
-
-
- A remote server is a server that contains remote mailboxes.
-
- A shared mailbox, is a mailbox that multiple users have access to.
-
- An IMAP mailbox referral is when the server directs the client to
- another IMAP mailbox.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC-2119].
-
-3. Introduction and Overview
-
- IMAP4 servers that support this extension MUST list the keyword
- MAILBOX-REFERRALS in their CAPABILITY response. No client action is
- needed to invoke the MAILBOX-REFERRALS capability in a server.
-
- A MAILBOX-REFERRALS capable IMAP4 server MUST NOT return referrals
- that result in a referrals loop.
-
- A referral response consists of a tagged NO response and a REFERRAL
- response code. The REFERRAL response code MUST contain as an
- argument a one or more valid URLs separated by a space as defined in
- [RFC-1738]. If a server replies with multiple URLs for a particular
- object, they MUST all be of the same type. In this case, the URL MUST
- be an IMAP URL as defined in [RFC-2192]. A client that supports the
- REFERRALS extension MUST be prepared for a URL of any type, but it
- need only be able to process IMAP URLs.
-
- A server MAY respond with multiple IMAP mailbox referrals if there is
- more than one replica of the mailbox. This allows the implementation
- of a load balancing or failover scheme. How a server keeps multiple
- replicas of a mailbox in sync is not addressed by this document.
-
- If the server has a preferred order in which the client should
- attempt to access the URLs, the preferred URL SHOULD be listed in the
- first, with the remaining URLs presented in descending order of
- preference. If multiple referrals are given for a mailbox, a server
- should be aware that there are synchronization issues for a client if
- the UIDVALIDITY of the referred mailboxes are different.
-
- An IMAP mailbox referral may be given in response to an IMAP command
- that specifies a mailbox as an argument.
-
-
-
-
-
-
-
-
-Gahrns Standards Track [Page 2]
-
-RFC 2193 IMAP4 Mailbox Referrals September 1997
-
-
- Example:
-
- A001 NO [REFERRAL IMAP://user;address@hidden/REMOTE]Remote Mailbox
-
- NOTE: user;AUTH=* is specified as required by [RFC-2192] to avoid a
- client falling back to anonymous login.
-
- Remote mailboxes and their inferiors, that are accessible only via
- referrals SHOULD NOT appear in LIST and LSUB responses issued against
- the user's home server. They MUST appear in RLIST and RLSUB
- responses issued against the user's home server. Hierarchy referrals,
- in which a client would be required to connect to the remote server
- to issue a LIST to discover the inferiors of a mailbox are not
- addressed in this document.
-
- For example, if shared mailboxes were only accessible via referrals
- on a remote server, a RLIST "" "#SHARED/%" command would return the
- same response if issued against the user's home server or the remote
- server.
-
- Note: Mailboxes that are available on the user's home server do not
- need to be available on the remote server. In addition, there may be
- additional mailboxes available on the remote server, but they will
- not accessible to the client via referrals unless they appear in the
- LIST response to the RLIST command against the user's home server.
-
- A MAILBOX-REFERRALS capable client will issue the RLIST and RLSUB
- commands in lieu of LIST and LSUB. The RLIST and RLSUB commands
- behave identically to their LIST and LSUB counterparts, except remote
- mailboxes are returned in addition to local mailboxes in the LIST and
- LSUB responses. This avoids displaying to a non MAILBOX-REFERRALS
- enabled client inaccessible remote mailboxes.
-
-4.1. SELECT, EXAMINE, DELETE, SUBSCRIBE, UNSUBSCRIBE, STATUS and APPEND
- Referrals
-
- An IMAP4 server MAY respond to the SELECT, EXAMINE, DELETE,
- SUBSCRIBE, UNSUBSCRIBE, STATUS or APPEND command with one or more
- IMAP mailbox referrals to indicate to the client that the mailbox is
- hosted on a remote server.
-
- When a client processes an IMAP mailbox referral, it will open a new
- connection or use an existing connection to the remote server so that
- it is able to issue the commands necessary to process the remote
- mailbox.
-
-
-
-
-
-
-Gahrns Standards Track [Page 3]
-
-RFC 2193 IMAP4 Mailbox Referrals September 1997
-
-
- Example: <IMAP4 connection to home server>
-
- C: A001 DELETE "SHARED/FOO"
- S: A001 NO [REFERRAL IMAP://user;address@hidden/SHARED/FOO]
- Remote mailbox. Try SERVER2.
-
- <Client established a second connection to SERVER2 and
- issues the DELETE command on the referred mailbox>
-
- S: * OK IMAP4rev1 server ready
- C: B001 AUTHENTICATE KERBEROS_V4
- <authentication exchange>
- S: B001 OK user is authenticated
-
- C: B002 DELETE "SHARED/FOO"
- S: B002 OK DELETE completed
-
- Example: <IMAP4 connection to home server>
-
- C: A001 SELECT REMOTE
- S: A001 NO [REFERRAL IMAP://user;address@hidden/REMOTE
- IMAP://user;address@hidden/REMOTE] Remote mailbox.
- Try SERVER2 or SERVER3.
-
- <Client opens second connection to remote server, and
- issues the commands needed to process the items in the
- remote mailbox>
-
- S: * OK IMAP4rev1 server ready
- C: B001 AUTHENTICATE KERBEROS_V4
- <authentication exchange>
- S: B001 OK user is authenticated
-
- C: B002 SELECT REMOTE
- S: * 12 EXISTS
- S: * 1 RECENT
- S: * OK [UNSEEN 10] Message 10 is first unseen
- S: * OK [UIDVALIDITY 123456789]
- S: * FLAGS (Answered Flagged Deleted Seen Draft)
- S: * OK [PERMANENTFLAGS (Answered Deleted Seen ]
- S: B002 OK [READ-WRITE] Selected completed
-
- C: B003 FETCH 10:12 RFC822
- S: * 10 FETCH . . .
- S: * 11 FETCH . . .
- S: * 12 FETCH . . .
- S: B003 OK FETCH Completed
-
-
-
-
-Gahrns Standards Track [Page 4]
-
-RFC 2193 IMAP4 Mailbox Referrals September 1997
-
-
- <Client is finished processing the REMOTE mailbox and
- wants to process a mailbox on its home server>
-
- C: B004 LOGOUT
- S: * BYE IMAP4rev1 server logging out
- S: B004 OK LOGOUT Completed
-
- <Client continues with first connection>
-
- C: A002 SELECT INBOX
- S: * 16 EXISTS
- S: * 2 RECENT
- S: * OK [UNSEEN 10] Message 10 is first unseen
- S: * OK [UIDVALIDITY 123456789]
- S: * FLAGS (Answered Flagged Deleted Seen Draft)
- S: * OK [PERMANENTFLAGS (Answered Deleted Seen ]
- S: A002 OK [READ-WRITE] Selected completed
-
-4.2. CREATE Referrals
-
- An IMAP4 server MAY respond to the CREATE command with one or more
- IMAP mailbox referrals, if it wishes to direct the client to issue
- the CREATE against another server. The server can employ any means,
- such as examining the hierarchy of the specified mailbox name, in
- determining which server the mailbox should be created on.
-
- Example:
-
- C: A001 CREATE "SHARED/FOO"
- S: A001 NO [REFERRAL IMAP://user;address@hidden/SHARED/FOO]
- Mailbox should be created on remote server
-
- Alternatively, because a home server is required to maintain a
- listing of referred remote mailboxes, a server MAY allow the creation
- of a mailbox that will ultimately reside on a remote server against
- the home server, and provide referrals on subsequent commands that
- manipulate the mailbox.
-
- Example:
-
- C: A001 CREATE "SHARED/FOO"
- S: A001 OK CREATE succeeded
-
- C: A002 SELECT "SHARED/FOO"
- S: A002 NO [REFERRAL IMAP://user;address@hidden/SHARED/FOO]
- Remote mailbox. Try SERVER2
-
-
-
-
-
-Gahrns Standards Track [Page 5]
-
-RFC 2193 IMAP4 Mailbox Referrals September 1997
-
-
-4.3. RENAME Referrals
-
- An IMAP4 server MAY respond to the RENAME command with one or more
- pairs of IMAP mailbox referrals. In each pair of IMAP mailbox
- referrals, the first one is an URL to the existing mailbox name and
- the second is an URL to the requested new mailbox name.
-
- If within an IMAP mailbox referral pair, the existing and new mailbox
- URLs are on different servers, the remote servers are unable to
- perform the RENAME operation. To achieve the same behavior of
- server RENAME, the client MAY issue the constituent CREATE, FETCH,
- APPEND, and DELETE commands against both servers.
-
- If within an IMAP mailbox referral pair, the existing and new mailbox
- URLs are on the same server it is an indication that the currently
- connected server is unable to perform the operation. The client can
- simply re-issue the RENAME command on the remote server.
-
- Example:
-
- C: A001 RENAME FOO BAR
- S: A001 NO [REFERRAL IMAP://user;address@hidden/FOO
- IMAP://user;address@hidden/BAR] Unable to rename mailbox
- across servers
-
- Since the existing and new mailbox names are on different servers,
- the client would be required to make a connection to both servers and
- issue the constituent commands require to achieve the RENAME.
-
- Example:
-
- C: A001 RENAME FOO BAR
- S: A001 NO [REFERRAL IMAP://user;address@hidden/FOO
- IMAP://user;address@hidden/BAR] Unable to rename mailbox
- located on SERVER2
-
- Since both the existing and new mailbox are on the same remote
- server, the client can simply make a connection to the remote server
- and re-issue the RENAME command.
-
-4.4. COPY Referrals
-
- An IMAP4 server MAY respond to the COPY command with one or more IMAP
- mailbox referrals. This indicates that the destination mailbox is on
- a remote server. To achieve the same behavior of a server COPY, the
- client MAY issue the constituent FETCH and APPEND commands against
- both servers.
-
-
-
-
-Gahrns Standards Track [Page 6]
-
-RFC 2193 IMAP4 Mailbox Referrals September 1997
-
-
- Example:
-
- C: A001 COPY 1 "SHARED/STUFF"
- S: A001 NO [REFERRAL IMAP://user;address@hidden/SHARED/STUFF]
- Unable to copy message(s) to SERVER2.
-
-5.1 RLIST command
-
- Arguments: reference name
- mailbox name with possible wildcards
-
- Responses: untagged responses: LIST
-
- Result: OK - RLIST Completed
- NO - RLIST Failure
- BAD - command unknown or arguments invalid
-
- The RLIST command behaves identically to its LIST counterpart, except
- remote mailboxes are returned in addition to local mailboxes in the
- LIST responses.
-
-5.2 RLSUB Command
-
- Arguments: reference name
- mailbox name with possible wildcards
-
- Responses: untagged responses: LSUB
-
- Result: OK - RLSUB Completed
- NO - RLSUB Failure
- BAD - command unknown or arguments invalid
-
- The RLSUB command behaves identically to its LSUB counterpart, except
- remote mailboxes are returned in addition to local mailboxes in the
- LSUB responses.
-
-6. Formal Syntax
-
- The following syntax specification uses the augmented Backus-Naur
- Form (BNF) as described in [ABNF].
-
- list_mailbox = <list_mailbox> as defined in [RFC-2060]
-
- mailbox = <mailbox> as defined in [RFC-2060]
-
- mailbox_referral = <tag> SPACE "NO" SPACE
- <referral_response_code> (text / text_mime2)
- ; See [RFC-2060] for <tag>, text and text_mime2 definition
-
-
-
-Gahrns Standards Track [Page 7]
-
-RFC 2193 IMAP4 Mailbox Referrals September 1997
-
-
- referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]"
- ; See [RFC-1738] for <url> definition
-
- rlist = "RLIST" SPACE mailbox SPACE list_mailbox
-
- rlsub = "RLSUB" SPACE mailbox SPACE list_mailbox
-
-6. Security Considerations
-
- The IMAP4 referral mechanism makes use of IMAP URLs, and as such,
- have the same security considerations as general internet URLs [RFC-
- 1738], and in particular IMAP URLs [RFC-2192].
-
- With the MAILBOX-REFERRALS capability, it is potentially easier to
- write a rogue server that injects a bogus referral response that
- directs a user to an incorrect mailbox. Although referrals reduce
- the effort to write such a server, the referral response makes
- detection of the intrusion easier.
-
-7. References
-
- [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
- 4rev1", RFC 2060, University of Washington, December 1996.
-
- [RFC-2192], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft,
- September 1997.
-
- [RFC-1738], Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
- Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation,
- University of Minnesota, December 1994.
-
- [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, Harvard University, March 1997.
-
- [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for
- Syntax Specifications: ABNF", Work in Progress, Internet Mail
- Consortium, April 1997.
-
-8. Acknowledgments
-
- Many valuable suggestions were received from private discussions and
- the IMAP4 mailing list. In particular, Raymond Cheng, Mark Crispin,
- Mark Keasling, Chris Newman and Larry Osterman made significant
- contributions to this document.
-
-
-
-
-
-
-
-Gahrns Standards Track [Page 8]
-
-RFC 2193 IMAP4 Mailbox Referrals September 1997
-
-
-9. Author's Address
-
- Mike Gahrns
- Microsoft
- One Microsoft Way
- Redmond, WA, 98072
-
- Phone: (206) 936-9833
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gahrns Standards Track [Page 9]
-
diff --git a/doc/rfc/rfc2195.txt b/doc/rfc/rfc2195.txt
deleted file mode 100644
index 4a2725b..0000000
--- a/doc/rfc/rfc2195.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Klensin
-Request for Comments: 2195 R. Catoe
-Category: Standards Track P. Krumviede
-Obsoletes: 2095 MCI
- September 1997
-
-
- IMAP/POP AUTHorize Extension for Simple Challenge/Response
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- While IMAP4 supports a number of strong authentication mechanisms as
- described in RFC 1731, it lacks any mechanism that neither passes
- cleartext, reusable passwords across the network nor requires either
- a significant security infrastructure or that the mail server update
- a mail-system-wide user authentication file on each mail access.
- This specification provides a simple challenge-response
- authentication protocol that is suitable for use with IMAP4. Since
- it utilizes Keyed-MD5 digests and does not require that the secret be
- stored in the clear on the server, it may also constitute an
- improvement on APOP for POP3 use as specified in RFC 1734.
-
-1. Introduction
-
- Existing Proposed Standards specify an AUTHENTICATE mechanism for the
- IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for
- the POP3 protocol [POP3-AUTH]. The AUTHENTICATE mechanism is
- intended to be extensible; the four methods specified in [IMAP-AUTH]
- are all fairly powerful and require some security infrastructure to
- support. The base POP3 specification [POP3] also contains a
- lightweight challenge-response mechanism called APOP. APOP is
- associated with most of the risks associated with such protocols: in
- particular, it requires that both the client and server machines have
- access to the shared secret in cleartext form. CRAM offers a method
- for avoiding such cleartext storage while retaining the algorithmic
- simplicity of APOP in using only MD5, though in a "keyed" method.
-
-
-
-
-
-
-
-Klensin, Catoe & Krumviede Standards Track [Page 1]
-
-RFC 2195 IMAP/POP AUTHorize Extension September 1997
-
-
- At present, IMAP [IMAP] lacks any facility corresponding to APOP.
- The only alternative to the strong mechanisms identified in [IMAP-
- AUTH] is a presumably cleartext username and password, supported
- through the LOGIN command in [IMAP]. This document describes a
- simple challenge-response mechanism, similar to APOP and PPP CHAP
- [PPP], that can be used with IMAP (and, in principle, with POP3).
-
- This mechanism also has the advantage over some possible alternatives
- of not requiring that the server maintain information about email
- "logins" on a per-login basis. While mechanisms that do require such
- per-login history records may offer enhanced security, protocols such
- as IMAP, which may have several connections between a given client
- and server open more or less simultaneous, may make their
- implementation particularly challenging.
-
-2. Challenge-Response Authentication Mechanism (CRAM)
-
- The authentication type associated with CRAM is "CRAM-MD5".
-
- The data encoded in the first ready response contains an
- presumptively arbitrary string of random digits, a timestamp, and the
- fully-qualified primary host name of the server. The syntax of the
- unencoded form must correspond to that of an RFC 822 'msg-id'
- [RFC822] as described in [POP3].
-
- The client makes note of the data and then responds with a string
- consisting of the user name, a space, and a 'digest'. The latter is
- computed by applying the keyed MD5 algorithm from [KEYED-MD5] where
- the key is a shared secret and the digested text is the timestamp
- (including angle-brackets).
-
- This shared secret is a string known only to the client and server.
- The `digest' parameter itself is a 16-octet value which is sent in
- hexadecimal format, using lower-case ASCII characters.
-
- When the server receives this client response, it verifies the digest
- provided. If the digest is correct, the server should consider the
- client authenticated and respond appropriately.
-
- Keyed MD5 is chosen for this application because of the greater
- security imparted to authentication of short messages. In addition,
- the use of the techniques described in [KEYED-MD5] for precomputation
- of intermediate results make it possible to avoid explicit cleartext
- storage of the shared secret on the server system by instead storing
- the intermediate results which are known as "contexts".
-
-
-
-
-
-
-Klensin, Catoe & Krumviede Standards Track [Page 2]
-
-RFC 2195 IMAP/POP AUTHorize Extension September 1997
-
-
- CRAM does not support a protection mechanism.
-
- Example:
-
- The examples in this document show the use of the CRAM mechanism with
- the IMAP4 AUTHENTICATE command [IMAP-AUTH]. The base64 encoding of
- the challenges and responses is part of the IMAP4 AUTHENTICATE
- command, not part of the CRAM specification itself.
-
- S: * OK IMAP4 Server
- C: A0001 AUTHENTICATE CRAM-MD5
- S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
- C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
- S: A0001 OK CRAM authentication successful
-
- In this example, the shared secret is the string
- 'tanstaaftanstaaf'. Hence, the Keyed MD5 digest is produced by
- calculating
-
- MD5((tanstaaftanstaaf XOR opad),
- MD5((tanstaaftanstaaf XOR ipad),
- <address@hidden>))
-
- where ipad and opad are as defined in the keyed-MD5 Work in
- Progress [KEYED-MD5] and the string shown in the challenge is the
- base64 encoding of <address@hidden>. The
- shared secret is null-padded to a length of 64 bytes. If the
- shared secret is longer than 64 bytes, the MD5 digest of the
- shared secret is used as a 16 byte input to the keyed MD5
- calculation.
-
- This produces a digest value (in hexadecimal) of
-
- b913a602c7eda7a495b4e6e7334d3890
-
- The user name is then prepended to it, forming
-
- tim b913a602c7eda7a495b4e6e7334d3890
-
- Which is then base64 encoded to meet the requirements of the IMAP4
- AUTHENTICATE command (or the similar POP3 AUTH command), yielding
-
- dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
-
-
-
-
-
-
-
-
-Klensin, Catoe & Krumviede Standards Track [Page 3]
-
-RFC 2195 IMAP/POP AUTHorize Extension September 1997
-
-
-3. References
-
- [CHAP] Lloyd, B., and W. Simpson, "PPP Authentication Protocols",
- RFC 1334, October 1992.
-
- [IMAP] Crispin, M., "Internet Message Access Protocol - Version
- 4rev1", RFC 2060, University of Washington, December 1996.
-
- [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms",
- RFC 1731, Carnegie Mellon, December 1994.
-
- [KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for
- Message Authentication", RFC 2104, February 1997.
-
- [MD5] Rivest, R., "The MD5 Message Digest Algorithm",
- RFC 1321, MIT Laboratory for Computer Science, April 1992.
-
- [POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3",
- STD 53, RFC 1939, Carnegie Mellon, May 1996.
-
- [POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
- Carnegie Mellon, December, 1994.
-
-4. Security Considerations
-
- It is conjectured that use of the CRAM authentication mechanism
- provides origin identification and replay protection for a session.
- Accordingly, a server that implements both a cleartext password
- command and this authentication type should not allow both methods of
- access for a given user.
-
- While the saving, on the server, of "contexts" (see section 2) is
- marginally better than saving the shared secrets in cleartext as is
- required by CHAP [CHAP] and APOP [POP3], it is not sufficient to
- protect the secrets if the server itself is compromised.
- Consequently, servers that store the secrets or contexts must both be
- protected to a level appropriate to the potential information value
- in user mailboxes and identities.
-
- As the length of the shared secret increases, so does the difficulty
- of deriving it.
-
- While there are now suggestions in the literature that the use of MD5
- and keyed MD5 in authentication procedures probably has a limited
- effective lifetime, the technique is now widely deployed and widely
- understood. It is believed that this general understanding may
- assist with the rapid replacement, by CRAM-MD5, of the current uses
- of permanent cleartext passwords in IMAP. This document has been
-
-
-
-Klensin, Catoe & Krumviede Standards Track [Page 4]
-
-RFC 2195 IMAP/POP AUTHorize Extension September 1997
-
-
- deliberately written to permit easy upgrading to use SHA (or whatever
- alternatives emerge) when they are considered to be widely available
- and adequately safe.
-
- Even with the use of CRAM, users are still vulnerable to active
- attacks. An example of an increasingly common active attack is 'TCP
- Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95].
-
- See section 1 above for additional discussion.
-
-5. Acknowledgements
-
- This memo borrows ideas and some text liberally from [POP3] and
- [RFC-1731] and thanks are due the authors of those documents. Ran
- Atkinson made a number of valuable technical and editorial
- contributions to the document.
-
-6. Authors' Addresses
-
- John C. Klensin
- MCI Telecommunications
- 800 Boylston St, 7th floor
- Boston, MA 02199
- USA
-
- EMail: address@hidden
- Phone: +1 617 960 1011
-
- Randy Catoe
- MCI Telecommunications
- 2100 Reston Parkway
- Reston, VA 22091
- USA
-
- EMail: address@hidden
- Phone: +1 703 715 7366
-
- Paul Krumviede
- MCI Telecommunications
- 2100 Reston Parkway
- Reston, VA 22091
- USA
-
- EMail: address@hidden
- Phone: +1 703 715 7251
-
-
-
-
-
-
-Klensin, Catoe & Krumviede Standards Track [Page 5]
-
diff --git a/doc/rfc/rfc2221.txt b/doc/rfc/rfc2221.txt
deleted file mode 100644
index 81d0062..0000000
--- a/doc/rfc/rfc2221.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Gahrns
-Request for Comments: 2221 Microsoft
-Category: Standards Track October 1997
-
-
- IMAP4 Login Referrals
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
-1. Abstract
-
- When dealing with large amounts of users and many IMAP4 [RFC-2060]
- servers, it is often necessary to move users from one IMAP4 server to
- another. For example, hardware failures or organizational changes
- may dictate such a move.
-
- Login referrals allow clients to transparently connect to an
- alternate IMAP4 server, if their home IMAP4 server has changed.
-
- A referral mechanism can provide efficiencies over the alternative
- 'proxy method', in which the local IMAP4 server contacts the remote
- server on behalf of the client, and then transfers the data from the
- remote server to itself, and then on to the client. The referral
- mechanism's direct client connection to the remote server is often a
- more efficient use of bandwidth, and does not require the local
- server to impersonate the client when authenticating to the remote
- server.
-
-2. Conventions used in this document
-
- In examples, "C:" and "S:" indicate lines sent by the client and
- server respectively.
-
- A home server, is an IMAP4 server that contains the user's inbox.
-
- A remote server is a server that contains remote mailboxes.
-
-
-
-
-
-Gahrns Standards Track [Page 1]
-
-RFC 2221 IMAP4 Login Referrals October 1997
-
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC-2119].
-
-3. Introduction and Overview
-
- IMAP4 servers that support this extension MUST list the keyword
- LOGIN-REFERRALS in their CAPABILITY response. No client action is
- needed to invoke the LOGIN-REFERRALS capability in a server.
-
- A LOGIN-REFERRALS capable IMAP4 server SHOULD NOT return a referral
- to a server that will return a referral. A client MUST NOT follow
- more than 10 levels of referral without consulting the user.
-
- A LOGIN-REFERRALS response code MUST contain as an argument a valid
- IMAP server URL as defined in [IMAP-URL].
-
- A home server referral consists of either a tagged NO or OK, or an
- untagged BYE response that contains a LOGIN-REFERRALS response code.
-
- Example: A001 NO [REFERRAL IMAP://user;address@hidden/] Remote Server
-
- NOTE: user;AUTH=* is specified as required by [IMAP-URL] to avoid a
- client falling back to anonymous login.
-
-4. Home Server Referrals
-
- A home server referral may be returned in response to an AUTHENTICATE
- or LOGIN command, or it may appear in the connection startup banner.
- If a server returns a home server referral in a tagged NO response,
- that server does not contain any mailboxes that are accessible to the
- user. If a server returns a home server referral in a tagged OK
- response, it indicates that the user's personal mailboxes are
- elsewhere, but the server contains public mailboxes which are
- readable by the user. After receiving a home server referral, the
- client can not make any assumptions as to whether this was a
- permanent or temporary move of the user.
-
-4.1. LOGIN and AUTHENTICATE Referrals
-
- An IMAP4 server MAY respond to a LOGIN or AUTHENTICATE command with a
- home server referral if it wishes to direct the user to another IMAP4
- server.
-
- Example: C: A001 LOGIN MIKE PASSWORD
- S: A001 NO [REFERRAL IMAP://address@hidden/] Specified user
- is invalid on this server. Try SERVER2.
-
-
-
-
-Gahrns Standards Track [Page 2]
-
-RFC 2221 IMAP4 Login Referrals October 1997
-
-
- Example: C: A001 LOGIN MATTHEW PASSWORD
- S: A001 OK [REFERRAL IMAP://address@hidden/] Specified
- user's personal mailboxes located on Server2, but
- public mailboxes are available.
-
- Example: C: A001 AUTHENTICATE GSSAPI
- <authentication exchange>
- S: A001 NO [REFERRAL IMAP://user;address@hidden/]
- Specified user is invalid on this server. Try
- SERVER2.
-
-4.2. BYE at connection startup referral
-
- An IMAP4 server MAY respond with an untagged BYE and a REFERRAL
- response code that contains an IMAP URL to a home server if it is not
- willing to accept connections and wishes to direct the client to
- another IMAP4 server.
-
- Example: S: * BYE [REFERRAL IMAP://user;address@hidden/] Server not
- accepting connections. Try SERVER2
-
-5. Formal Syntax
-
- The following syntax specification uses the augmented Backus-Naur
- Form (BNF) as described in [ABNF].
-
- This amends the "resp_text_code" element of the IMAP4 grammar
- described in [RFC-2060]
-
- resp_text_code =/ "REFERRAL" SPACE <imapurl>
- ; See [IMAP-URL] for definition of <imapurl>
- ; See [RFC-2060] for base definition of resp_text_code
-
-6. Security Considerations
-
- The IMAP4 login referral mechanism makes use of IMAP URLs, and as
- such, have the same security considerations as general internet URLs
- [RFC-1738], and in particular IMAP URLs [IMAP-URL].
-
- A server MUST NOT give a login referral if authentication for that
- user fails. This is to avoid revealing information about the user's
- account to an unauthorized user.
-
- With the LOGIN-REFERRALS capability, it is potentially easier to
- write a rogue 'password catching' server that collects login data and
- then refers the client to their actual IMAP4 server. Although
- referrals reduce the effort to write such a server, the referral
- response makes detection of the intrusion easier.
-
-
-
-Gahrns Standards Track [Page 3]
-
-RFC 2221 IMAP4 Login Referrals October 1997
-
-
-7. References
-
- [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
- 4rev1", RFC 2060, December 1996.
-
- [IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft,
- September 1997.
-
- [RFC-1738], Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
- Resource Locators (URL)", RFC 1738, December 1994.
-
- [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for
- Syntax Specifications: ABNF", Work in Progress.
-
-8. Acknowledgments
-
- Many valuable suggestions were received from private discussions and
- the IMAP4 mailing list. In particular, Raymond Cheng, Mark Crispin,
- Mark Keasling Chris Newman and Larry Osterman made significant
- contributions to this document.
-
-9. Author's Address
-
- Mike Gahrns
- Microsoft
- One Microsoft Way
- Redmond, WA, 98072
-
- Phone: (206) 936-9833
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gahrns Standards Track [Page 4]
-
-RFC 2221 IMAP4 Login Referrals October 1997
-
-
-10. Full Copyright Statement
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implmentation may be prepared, copied, published
- andand distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gahrns Standards Track [Page 5]
-
diff --git a/doc/rfc/rfc2222.txt b/doc/rfc/rfc2222.txt
deleted file mode 100644
index 2b0a2ab..0000000
--- a/doc/rfc/rfc2222.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Myers
-Request for Comments: 2222 Netscape Communications
-Category: Standards Track October 1997
-
-
- Simple Authentication and Security Layer (SASL)
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
-Table of Contents
-
- 1. Abstract .............................................. 2
- 2. Organization of this Document ......................... 2
- 2.1. How to Read This Document ............................. 2
- 2.2. Conventions Used in this Document ..................... 2
- 2.3. Examples .............................................. 3
- 3. Introduction and Overview ............................. 3
- 4. Profiling requirements ................................ 4
- 5. Specific issues ....................................... 5
- 5.1. Client sends data first ............................... 5
- 5.2. Server returns success with additional data ........... 5
- 5.3. Multiple authentications .............................. 5
- 6. Registration procedures ............................... 6
- 6.1. Comments on SASL mechanism registrations .............. 6
- 6.2. Location of Registered SASL Mechanism List ............ 6
- 6.3. Change Control ........................................ 7
- 6.4. Registration Template ................................. 7
- 7. Mechanism definitions ................................. 8
- 7.1. Kerberos version 4 mechanism .......................... 8
- 7.2. GSSAPI mechanism ...................................... 9
- 7.2.1 Client side of authentication protocol exchange ....... 9
- 7.2.2 Server side of authentication protocol exchange ....... 10
- 7.2.3 Security layer ........................................ 11
- 7.3. S/Key mechanism ....................................... 11
- 7.4. External mechanism .................................... 12
- 8. References ............................................ 13
- 9. Security Considerations ............................... 13
- 10. Author's Address ...................................... 14
-
-
-
-Myers Standards Track [Page 1]
-
-RFC 2222 SASL October 1997
-
-
- Appendix A. Relation of SASL to Transport Security .......... 15
- Full Copyright Statement .................................... 16
-
-1. Abstract
-
- This document describes a method for adding authentication support to
- connection-based protocols. To use this specification, a protocol
- includes a command for identifying and authenticating a user to a
- server and for optionally negotiating protection of subsequent
- protocol interactions. If its use is negotiated, a security layer is
- inserted between the protocol and the connection. This document
- describes how a protocol specifies such a command, defines several
- mechanisms for use by the command, and defines the protocol used for
- carrying a negotiated security layer over the connection.
-
-2. Organization of this Document
-
-2.1. How to Read This Document
-
- This document is written to serve two different audiences, protocol
- designers using this specification to support authentication in their
- protocol, and implementors of clients or servers for those protocols
- using this specification.
-
- The sections "Introduction and Overview", "Profiling requirements",
- and "Security Considerations" cover issues that protocol designers
- need to understand and address in profiling this specification for
- use in a specific protocol.
-
- Implementors of a protocol using this specification need the
- protocol-specific profiling information in addition to the
- information in this document.
-
-2.2. Conventions Used in this Document
-
- In examples, "C:" and "S:" indicate lines sent by the client and
- server respectively.
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
- in this document are to be interpreted as defined in "Key words for
- use in RFCs to Indicate Requirement Levels" [RFC 2119].
-
-
-
-
-
-
-
-
-
-
-Myers Standards Track [Page 2]
-
-RFC 2222 SASL October 1997
-
-
-2.3. Examples
-
- Examples in this document are for the IMAP profile [RFC 2060] of this
- specification. The base64 encoding of challenges and responses, as
- well as the "+ " preceding the responses are part of the IMAP4
- profile, not part of the SASL specification itself.
-
-3. Introduction and Overview
-
- The Simple Authentication and Security Layer (SASL) is a method for
- adding authentication support to connection-based protocols. To use
- this specification, a protocol includes a command for identifying and
- authenticating a user to a server and for optionally negotiating a
- security layer for subsequent protocol interactions.
-
- The command has a required argument identifying a SASL mechanism.
- SASL mechanisms are named by strings, from 1 to 20 characters in
- length, consisting of upper-case letters, digits, hyphens, and/or
- underscores. SASL mechanism names must be registered with the IANA.
- Procedures for registering new SASL mechanisms are given in the
- section "Registration procedures"
-
- If a server supports the requested mechanism, it initiates an
- authentication protocol exchange. This consists of a series of
- server challenges and client responses that are specific to the
- requested mechanism. The challenges and responses are defined by the
- mechanisms as binary tokens of arbitrary length. The protocol's
- profile then specifies how these binary tokens are then encoded for
- transfer over the connection.
-
- After receiving the authentication command or any client response, a
- server may issue a challenge, indicate failure, or indicate
- completion. The protocol's profile specifies how the server
- indicates which of the above it is doing.
-
- After receiving a challenge, a client may issue a response or abort
- the exchange. The protocol's profile specifies how the client
- indicates which of the above it is doing.
-
- During the authentication protocol exchange, the mechanism performs
- authentication, transmits an authorization identity (frequently known
- as a userid) from the client to server, and negotiates the use of a
- mechanism-specific security layer. If the use of a security layer is
- agreed upon, then the mechanism must also define or negotiate the
- maximum cipher-text buffer size that each side is able to receive.
-
-
-
-
-
-
-Myers Standards Track [Page 3]
-
-RFC 2222 SASL October 1997
-
-
- The transmitted authorization identity may be different than the
- identity in the client's authentication credentials. This permits
- agents such as proxy servers to authenticate using their own
- credentials, yet request the access privileges of the identity for
- which they are proxying. With any mechanism, transmitting an
- authorization identity of the empty string directs the server to
- derive an authorization identity from the client's authentication
- credentials.
-
- If use of a security layer is negotiated, it is applied to all
- subsequent data sent over the connection. The security layer takes
- effect immediately following the last response of the authentication
- exchange for data sent by the client and the completion indication
- for data sent by the server. Once the security layer is in effect,
- the protocol stream is processed by the security layer into buffers
- of cipher-text. 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 buffer. The length
- of the cipher-text buffer must be no larger than the maximum size
- that was defined or negotiated by the other side.
-
-4. Profiling requirements
-
- In order to use this specification, a protocol definition must supply
- the following information:
-
- 1. A service name, to be selected from the IANA registry of "service"
- elements for the GSSAPI host-based service name form [RFC 2078].
-
- 2. A definition of the command to initiate the authentication
- protocol exchange. This command must have as a parameter the
- mechanism name being selected by the client.
-
- The command SHOULD have an optional parameter giving an initial
- response. This optional parameter allows the client to avoid a
- round trip when using a mechanism which is defined to have the
- client send data first. When this initial response is sent by the
- client and the selected mechanism is defined to have the server
- start with an initial challenge, the command fails. See section
- 5.1 of this document for further information.
-
- 3. A definition of the method by which the authentication protocol
- exchange is carried out, including how the challenges and
- responses are encoded, how the server indicates completion or
- failure of the exchange, how the client aborts an exchange, and
- how the exchange method interacts with any line length limits in
- the protocol.
-
-
-
-
-Myers Standards Track [Page 4]
-
-RFC 2222 SASL October 1997
-
-
- 4. Identification of the octet where any negotiated security layer
- starts to take effect, in both directions.
-
- 5. A specification of how the authorization identity passed from the
- client to the server is to be interpreted.
-
-5. Specific issues
-
-5.1. Client sends data first
-
- Some mechanisms specify that the first data sent in the
- authentication protocol exchange is from the client to the server.
-
- If a protocol's profile permits the command which initiates an
- authentication protocol exchange to contain an initial client
- response, this parameter SHOULD be used with such mechanisms.
-
- If the initial client response parameter is not given, or if a
- protocol's profile does not permit the command which initiates an
- authentication protocol exchange to contain an initial client
- response, then the server issues a challenge with no data. The
- client's response to this challenge is then used as the initial
- client response. (The server then proceeds to send the next
- challenge, indicates completion, or indicates failure.)
-
-5.2. Server returns success with additional data
-
- Some mechanisms may specify that server challenge data be sent to the
- client along with an indication of successful completion of the
- exchange. This data would, for example, authenticate the server to
- the client.
-
- If a protocol's profile does not permit this server challenge to be
- returned with a success indication, then the server issues the server
- challenge without an indication of successful completion. The client
- then responds with no data. After receiving this empty response, the
- server then indicates successful completion.
-
-5.3. Multiple authentications
-
- Unless otherwise stated by the protocol's profile, only one
- successful SASL negotiation may occur in a protocol session. In this
- case, once an authentication protocol exchange has successfully
- completed, further attempts to initiate an authentication protocol
- exchange fail.
-
-
-
-
-
-
-Myers Standards Track [Page 5]
-
-RFC 2222 SASL October 1997
-
-
- In the case that a profile explicitly permits multiple successful
- SASL negotiations to occur, then in no case may multiple security
- layers be simultaneously in effect. If a security layer is in effect
- and a subsequent SASL negotiation selects no security layer, the
- original security layer remains in effect. If a security layer is in
- effect and a subsequent SASL negotiation selects a second security
- layer, then the second security layer replaces the first.
-
-6. Registration procedures
-
- Registration of a SASL mechanism is done by filling in the template
- in section 6.4 and sending it in to address@hidden IANA has the right
- to reject obviously bogus registrations, but will perform no review
- of clams made in the registration form.
-
- There is no naming convention for SASL mechanisms; any name that
- conforms to the syntax of a SASL mechanism name can be registered.
-
- While the registration procedures do not require it, authors of SASL
- mechanisms are encouraged to seek community review and comment
- whenever that is feasible. Authors may seek community review by
- posting a specification of their proposed mechanism as an internet-
- draft. SASL mechanisms intended for widespread use should be
- standardized through the normal IETF process, when appropriate.
-
-6.1. Comments on SASL mechanism registrations
-
- Comments on registered SASL mechanisms should first be sent to the
- "owner" of the mechanism. Submitters of comments may, after a
- reasonable attempt to contact the owner, request IANA to attach their
- comment to the SASL mechanism registration itself. If IANA approves
- of this the comment will be made accessible in conjunction with the
- SASL mechanism registration itself.
-
-6.2. Location of Registered SASL Mechanism List
-
- SASL mechanism registrations will be posted in the anonymous FTP
- directory "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-
- mechanisms/" and all registered SASL mechanisms will be listed in the
- periodically issued "Assigned Numbers" RFC [currently STD 2, RFC
- 1700]. The SASL mechanism description and other supporting material
- may also be published as an Informational RFC by sending it to "rfc-
- address@hidden" (please follow the instructions to RFC authors [RFC
- 2223]).
-
-
-
-
-
-
-
-Myers Standards Track [Page 6]
-
-RFC 2222 SASL October 1997
-
-
-6.3. Change Control
-
- Once a SASL mechanism registration has been published by IANA, the
- author may request a change to its definition. The change request
- follows the same procedure as the registration request.
-
- The owner of a SASL mechanism may pass responsibility for the SASL
- mechanism to another person or agency by informing IANA; this can be
- done without discussion or review.
-
- The IESG may reassign responsibility for a SASL mechanism. The most
- common case of this will be to enable changes to be made to
- mechanisms where the author of the registration has died, moved out
- of contact or is otherwise unable to make changes that are important
- to the community.
-
- SASL mechanism registrations may not be deleted; mechanisms which are
- no longer believed appropriate for use can be declared OBSOLETE by a
- change to their "intended use" field; such SASL mechanisms will be
- clearly marked in the lists published by IANA.
-
- The IESG is considered to be the owner of all SASL mechanisms which
- are on the IETF standards track.
-
-6.4. Registration Template
-
- To: address@hidden
- Subject: Registration of SASL mechanism X
-
- SASL mechanism name:
-
- Security considerations:
-
- Published specification (optional, recommended):
-
- Person & email address to contact for further information:
-
- Intended usage:
-
- (One of COMMON, LIMITED USE or OBSOLETE)
-
- Author/Change controller:
-
- (Any other information that the author deems interesting may be
- added below this line.)
-
-
-
-
-
-
-Myers Standards Track [Page 7]
-
-RFC 2222 SASL October 1997
-
-
-7. Mechanism definitions
-
- The following mechanisms are hereby defined.
-
-7.1. Kerberos version 4 mechanism
-
- The mechanism name associated with Kerberos version 4 is
- "KERBEROS_V4".
-
- The first challenge consists of a random 32-bit number in network
- byte order. The client responds with a Kerberos ticket and an
- authenticator for the principal "address@hidden", where
- "service" is the service name specified in the protocol's profile,
- "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 contains the server provided challenge in
- network byte order.
-
- Upon decrypting and verifying the ticket and authenticator, the
- server verifies 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 security layers supported by the server, and the sixth
- through eighth octets containing, in network byte order, the maximum
- cipher-text buffer size the server is able to receive. The server
- must encrypt using DES ECB mode the 8 octets of data in the session
- key and issue that encrypted data in a second challenge. The client
- considers the server authenticated if the first four octets of 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 security layer,
- 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 the authorization identity. The
- client must then append from one to eight zero-valued octets so that
- the length of the data is a multiple of eight octets. The client must
- then encrypt using DES PCBC mode the data with the session key and
- respond with the encrypted data. The server decrypts the data and
- verifies the contained checksum. The server must verify that the
- principal identified in the Kerberos ticket is authorized to connect
- as that authorization identity. After this verification, the
- authentication process is complete.
-
-
-
-Myers Standards Track [Page 8]
-
-RFC 2222 SASL October 1997
-
-
- The security layers and their corresponding bit-masks are as follows:
-
- 1 No security layer
- 2 Integrity (krb_mk_safe) protection
- 4 Privacy (krb_mk_priv) protection
-
- Other bit-masks may be defined in the future; bits which are not
- understood must be negotiated off.
-
- EXAMPLE: The following are two Kerberos version 4 login scenarios to
- the IMAP4 protocol (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
-
-
- 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
-
-7.2. GSSAPI mechanism
-
- The mechanism name associated with all mechanisms employing the
- GSSAPI [RFC 2078] is "GSSAPI".
-
-7.2.1 Client side of authentication protocol exchange
-
- The client calls 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
- GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
- "address@hidden" where "service" is the service name specified in
- the protocol's profile, and "hostname" is the fully qualified host
- name of the server. The client then responds with the resulting
- output_token. If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED,
-
-
-
-Myers Standards Track [Page 9]
-
-RFC 2222 SASL October 1997
-
-
- then the client should expect the server to issue a token in a
- subsequent challenge. The client must pass the token to another call
- to GSS_Init_sec_context, repeating the actions in this paragraph.
-
- When GSS_Init_sec_context returns GSS_S_COMPLETE, the client takes
- the following actions: If the last call to GSS_Init_sec_context
- returned an output_token, then the client responds with the
- output_token, otherwise the client responds with no data. The client
- should then expect the server to issue a token in a subsequent
- challenge. The client passes this token to GSS_Unwrap and interprets
- the first octet of resulting cleartext as a bit-mask specifying the
- security layers supported by the server and the second through fourth
- octets as the maximum size output_message to send to the server. The
- client then constructs data, with the first octet containing the
- bit-mask specifying the selected security layer, 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 the authorization identity. The client passes the
- data to GSS_Wrap with conf_flag set to FALSE, and responds with the
- generated output_message. The client can then consider the server
- authenticated.
-
-7.2.2 Server side of authentication protocol exchange
-
- The server passes the initial client response to
- GSS_Accept_sec_context as input_token, setting input_context_handle
- to 0 (initially). If GSS_Accept_sec_context returns
- GSS_S_CONTINUE_NEEDED, the server returns the generated output_token
- to the client in challenge and passes the resulting response to
- another call to GSS_Accept_sec_context, repeating the actions in this
- paragraph.
-
- When GSS_Accept_sec_context returns GSS_S_COMPLETE, the client takes
- the following actions: If the last call to GSS_Accept_sec_context
- returned an output_token, the server returns it to the client in a
- challenge and expects a reply from the client with no data. Whether
- or not an output_token was returned (and after receipt of any
- response from the client to such an output_token), the server then
- constructs 4 octets of data, with the first octet containing a bit-
- mask specifying the security layers 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_Wrap with conf_flag set to FALSE
- and issue the generated output_message to the client in a challenge.
- The server must then pass the resulting response to GSS_Unwrap and
- interpret the first octet of resulting cleartext as the bit-mask for
- the selected security layer, the second through fourth octets as the
- maximum size output_message to send to the client, and the remaining
-
-
-
-Myers Standards Track [Page 10]
-
-RFC 2222 SASL October 1997
-
-
- octets as the authorization identity. The server must verify that
- the src_name is authorized to authenticate as the authorization
- identity. After these verifications, the authentication process is
- complete.
-
-7.2.3 Security layer
-
- The security layers and their corresponding bit-masks are as follows:
-
- 1 No security layer
- 2 Integrity protection.
- Sender calls GSS_Wrap with conf_flag set to FALSE
- 4 Privacy protection.
- Sender calls GSS_Wrap with conf_flag set to TRUE
-
- Other bit-masks may be defined in the future; bits which are not
- understood must be negotiated off.
-
-7.3. S/Key mechanism
-
- The mechanism name associated with S/Key [RFC 1760] using the MD4
- digest algorithm is "SKEY".
-
- The client sends an initial response with the authorization identity.
-
- The server then issues a challenge which contains the decimal
- sequence number followed by a single space and the seed string for
- the indicated authorization identity. 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.
-
- The server must verify the one-time-password. After this
- verification, the authentication process is complete.
-
- S/Key authentication does not provide for any security layers.
-
- EXAMPLE: The following are two S/Key login scenarios in the IMAP4
- protocol.
-
- S: * OK IMAP4 Server
- C: A001 AUTHENTICATE SKEY
- S: +
- C: bW9yZ2Fu
- S: + OTUgUWE1ODMwOA==
- C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
- S: A001 OK S/Key authentication successful
-
-
-
-
-
-Myers Standards Track [Page 11]
-
-RFC 2222 SASL October 1997
-
-
- S: * OK IMAP4 Server
- C: A001 AUTHENTICATE SKEY
- S: +
- C: c21pdGg=
- S: + OTUgUWE1ODMwOA==
- C: BsAY3g4gBNo=
- S: A001 NO S/Key authentication failed
-
- The following is an S/Key login scenario in an IMAP4-like protocol
- which has an optional "initial response" argument to the AUTHENTICATE
- command.
-
- S: * OK IMAP4-Like Server
- C: A001 AUTHENTICATE SKEY bW9yZ2Fu
- S: + OTUgUWE1ODMwOA==
- C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
- S: A001 OK S/Key authentication successful
-
-7.4. External mechanism
-
- The mechanism name associated with external authentication is
- "EXTERNAL".
-
- The client sends an initial response with the authorization identity.
-
- The server uses information, external to SASL, to determine whether
- the client is authorized to authenticate as the authorization
- identity. If the client is so authorized, the server indicates
- successful completion of the authentication exchange; otherwise the
- server indicates failure.
-
- The system providing this external information may be, for example,
- IPsec or TLS.
-
- If the client sends the empty string as the authorization identity
- (thus requesting the authorization identity be derived from the
- client's authentication credentials), the authorization identity is
- to be derived from authentication credentials which exist in the
- system which is providing the external authentication.
-
-
-
-
-
-
-
-
-
-
-
-
-Myers Standards Track [Page 12]
-
-RFC 2222 SASL October 1997
-
-
-8. References
-
- [RFC 2060] Crispin, M., "Internet Message Access Protocol - Version
- 4rev1", RFC 2060, December 1996.
-
- [RFC 2078] Linn, J., "Generic Security Service Application Program
- Interface, Version 2", RFC 2078, January 1997.
-
- [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [RFC 2223] Postel, J., and J. Reynolds, "Instructions to RFC
- Authors", RFC 2223, October 1997.
-
- [RFC 1760] Haller, N., "The S/Key One-Time Password System", RFC
- 1760, February 1995.
-
- [RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
- RFC 1700, October 1994.
-
-9. Security Considerations
-
- Security issues are discussed throughout this memo.
-
- The mechanisms that support integrity protection are designed such
- that the negotiation of the security layer and authorization identity
- is integrity protected. When the client selects a security layer
- with at least integrity protection, this protects against an active
- attacker hijacking the connection and modifying the authentication
- exchange to negotiate a plaintext connection.
-
- When a server or client supports multiple authentication mechanisms,
- each of which has a different security strength, it is possible for
- an active attacker to cause a party to use the least secure mechanism
- supported. To protect against this sort of attack, a client or
- server which supports mechanisms of different strengths should have a
- configurable minimum strength that it will use. It is not sufficient
- for this minimum strength check to only be on the server, since an
- active attacker can change which mechanisms the client sees as being
- supported, causing the client to send authentication credentials for
- its weakest supported mechanism.
-
-
-
-
-
-
-
-
-
-
-Myers Standards Track [Page 13]
-
-RFC 2222 SASL October 1997
-
-
- The client's selection of a SASL mechanism is done in the clear and
- may be modified by an active attacker. It is important for any new
- SASL mechanisms to be designed such that an active attacker cannot
- obtain an authentication with weaker security properties by modifying
- the SASL mechanism name and/or the challenges and responses.
-
- Any protocol interactions prior to authentication are performed in
- the clear and may be modified by an active attacker. In the case
- where a client selects integrity protection, it is important that any
- security-sensitive protocol negotiations be performed after
- authentication is complete. Protocols should be designed such that
- negotiations performed prior to authentication should be either
- ignored or revalidated once authentication is complete.
-
-10. Author's Address
-
- John G. Myers
- Netscape Communications
- 501 E. Middlefield Road
- Mail Stop MV-029
- Mountain View, CA 94043-4042
-
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Myers Standards Track [Page 14]
-
-RFC 2222 SASL October 1997
-
-
-Appendix A. Relation of SASL to Transport Security
-
- Questions have been raised about the relationship between SASL and
- various services (such as IPsec and TLS) which provide a secured
- connection.
-
- Two of the key features of SASL are:
-
- 1. The separation of the authorization identity from the identity in
- the client's credentials. This permits agents such as proxy
- servers to authenticate using their own credentials, yet request
- the access privileges of the identity for which they are proxying.
-
- 2. Upon successful completion of an authentication exchange, the
- server knows the authorization identity the client wishes to use.
- This allows servers to move to a "user is authenticated" state in
- the protocol.
-
- These features are extremely important to some application protocols,
- yet Transport Security services do not always provide them. To
- define SASL mechanisms based on these services would be a very messy
- task, as the framing of these services would be redundant with the
- framing of SASL and some method of providing these important SASL
- features would have to be devised.
-
- Sometimes it is desired to enable within an existing connection the
- use of a security service which does not fit the SASL model. (TLS is
- an example of such a service.) This can be done by adding a command,
- for example "STARTTLS", to the protocol. Such a command is outside
- the scope of SASL, and should be different from the command which
- starts a SASL authentication protocol exchange.
-
- In certain situations, it is reasonable to use SASL underneath one of
- these Transport Security services. The transport service would
- secure the connection, either service would authenticate the client,
- and SASL would negotiate the authorization identity. The SASL
- negotiation would be what moves the protocol from "unauthenticated"
- to "authenticated" state. The "EXTERNAL" SASL mechanism is
- explicitly intended to handle the case where the transport service
- secures the connection and authenticates the client and SASL
- negotiates the authorization identity.
-
- When using SASL underneath a sufficiently strong Transport Security
- service, a SASL security layer would most likely be redundant. The
- client and server would thus probably want to negotiate off the use
- of a SASL security layer.
-
-
-
-
-
-Myers Standards Track [Page 15]
-
-RFC 2222 SASL October 1997
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implmentation may be prepared, copied, published
- andand distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Myers Standards Track [Page 16]
-
diff --git a/doc/rfc/rfc2231.txt b/doc/rfc/rfc2231.txt
deleted file mode 100644
index e00c74f..0000000
--- a/doc/rfc/rfc2231.txt
+++ /dev/null
@@ -1,564 +0,0 @@
-
-
-
-
-
-
-Network Working Group N. Freed
-Request for Comments: 2231 Innosoft
-Updates: 2045, 2047, 2183 K. Moore
-Obsoletes: 2184 University of Tennessee
-Category: Standards Track November 1997
-
-
- MIME Parameter Value and Encoded Word Extensions:
- Character Sets, Languages, and Continuations
-
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
-1. Abstract
-
- This memo defines extensions to the RFC 2045 media type and RFC 2183
- disposition parameter value mechanisms to provide
-
- (1) a means to specify parameter values in character sets
- other than US-ASCII,
-
- (2) to specify the language to be used should the value be
- displayed, and
-
- (3) a continuation mechanism for long parameter values to
- avoid problems with header line wrapping.
-
- This memo also defines an extension to the encoded words defined in
- RFC 2047 to allow the specification of the language to be used for
- display as well as the character set.
-
-2. Introduction
-
- The Multipurpose Internet Mail Extensions, or MIME [RFC-2045, RFC-
- 2046, RFC-2047, RFC-2048, RFC-2049], define a message format that
- allows for:
-
-
-
-
-
-Freed & Moore Standards Track [Page 1]
-
-RFC 2231 MIME Value and Encoded Word Extensions November 1997
-
-
- (1) textual message bodies in character sets other than
- US-ASCII,
-
- (2) non-textual message bodies,
-
- (3) multi-part message bodies, and
-
- (4) textual header information in character sets other than
- US-ASCII.
-
- MIME is now widely deployed and is used by a variety of Internet
- protocols, including, of course, Internet email. However, MIME's
- success has resulted in the need for additional mechanisms that were
- not provided in the original protocol specification.
-
- In particular, existing MIME mechanisms provide for named media type
- (content-type field) parameters as well as named disposition
- (content-disposition field). A MIME media type may specify any
- number of parameters associated with all of its subtypes, and any
- specific subtype may specify additional parameters for its own use. A
- MIME disposition value may specify any number of associated
- parameters, the most important of which is probably the attachment
- disposition's filename parameter.
-
- These parameter names and values end up appearing in the content-type
- and content-disposition header fields in Internet email. This
- inherently imposes three crucial limitations:
-
- (1) Lines in Internet email header fields are folded
- according to RFC 822 folding rules. This makes long
- parameter values problematic.
-
- (2) MIME headers, like the RFC 822 headers they often
- appear in, are limited to 7bit US-ASCII, and the
- encoded-word mechanisms of RFC 2047 are not available
- to parameter values. This makes it impossible to have
- parameter values in character sets other than US-ASCII
- without specifying some sort of private per-parameter
- encoding.
-
- (3) It has recently become clear that character set
- information is not sufficient to properly display some
- sorts of information -- language information is also
- needed [RFC-2130]. For example, support for
- handicapped users may require reading text string
-
-
-
-
-
-
-Freed & Moore Standards Track [Page 2]
-
-RFC 2231 MIME Value and Encoded Word Extensions November 1997
-
-
- aloud. The language the text is written in is needed
- for this to be done correctly. Some parameter values
- may need to be displayed, hence there is a need to
- allow for the inclusion of language information.
-
- The last problem on this list is also an issue for the encoded words
- defined by RFC 2047, as encoded words are intended primarily for
- display purposes.
-
- This document defines extensions that address all of these
- limitations. All of these extensions are implemented in a fashion
- that is completely compatible at a syntactic level with existing MIME
- implementations. In addition, the extensions are designed to have as
- little impact as possible on existing uses of MIME.
-
- IMPORTANT NOTE: These mechanisms end up being somewhat gibbous when
- they actually are used. As such, these mechanisms should not be used
- lightly; they should be reserved for situations where a real need for
- them exists.
-
-2.1. Requirements notation
-
- This document occasionally uses terms that appear in capital letters.
- When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY"
- appear capitalized, they are being used to indicate particular
- requirements of this specification. A discussion of the meanings of
- these terms appears in [RFC- 2119].
-
-3. Parameter Value Continuations
-
- Long MIME media type or disposition parameter values do not interact
- well with header line wrapping conventions. In particular, proper
- header line wrapping depends on there being places where linear
- whitespace (LWSP) is allowed, which may or may not be present in a
- parameter value, and even if present may not be recognizable as such
- since specific knowledge of parameter value syntax may not be
- available to the agent doing the line wrapping. The result is that
- long parameter values may end up getting truncated or otherwise
- damaged by incorrect line wrapping implementations.
-
- A mechanism is therefore needed to break up parameter values into
- smaller units that are amenable to line wrapping. Any such mechanism
- MUST be compatible with existing MIME processors. This means that
-
- (1) the mechanism MUST NOT change the syntax of MIME media
- type and disposition lines, and
-
-
-
-
-
-Freed & Moore Standards Track [Page 3]
-
-RFC 2231 MIME Value and Encoded Word Extensions November 1997
-
-
- (2) the mechanism MUST NOT depend on parameter ordering
- since MIME states that parameters are not order
- sensitive. Note that while MIME does prohibit
- modification of MIME headers during transport, it is
- still possible that parameters will be reordered when
- user agent level processing is done.
-
- The obvious solution, then, is to use multiple parameters to contain
- a single parameter value and to use some kind of distinguished name
- to indicate when this is being done. And this obvious solution is
- exactly what is specified here: The asterisk character ("*") followed
- by a decimal count is employed to indicate that multiple parameters
- are being used to encapsulate a single parameter value. The count
- starts at 0 and increments by 1 for each subsequent section of the
- parameter value. Decimal values are used and neither leading zeroes
- nor gaps in the sequence are allowed.
-
- The original parameter value is recovered by concatenating the
- various sections of the parameter, in order. For example, the
- content-type field
-
- Content-Type: message/external-body; access-type=URL;
- URL*0="ftp://";;
- URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
-
- is semantically identical to
-
- Content-Type: message/external-body; access-type=URL;
- URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar";
-
- Note that quotes around parameter values are part of the value
- syntax; they are NOT part of the value itself. Furthermore, it is
- explicitly permitted to have a mixture of quoted and unquoted
- continuation fields.
-
-4. Parameter Value Character Set and Language Information
-
- Some parameter values may need to be qualified with character set or
- language information. It is clear that a distinguished parameter
- name is needed to identify when this information is present along
- with a specific syntax for the information in the value itself. In
- addition, a lightweight encoding mechanism is needed to accommodate 8
- bit information in parameter values.
-
-
-
-
-
-
-
-
-Freed & Moore Standards Track [Page 4]
-
-RFC 2231 MIME Value and Encoded Word Extensions November 1997
-
-
- Asterisks ("*") are reused to provide the indicator that language and
- character set information is present and encoding is being used. A
- single quote ("'") is used to delimit the character set and language
- information at the beginning of the parameter value. Percent signs
- ("%") are used as the encoding flag, which agrees with RFC 2047.
-
- Specifically, an asterisk at the end of a parameter name acts as an
- indicator that character set and language information may appear at
- the beginning of the parameter value. A single quote is used to
- separate the character set, language, and actual value information in
- the parameter value string, and an percent sign is used to flag
- octets encoded in hexadecimal. For example:
-
- Content-Type: application/x-stuff;
- title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A
-
- Note that it is perfectly permissible to leave either the character
- set or language field blank. Note also that the single quote
- delimiters MUST be present even when one of the field values is
- omitted. This is done when either character set, language, or both
- are not relevant to the parameter value at hand. This MUST NOT be
- done in order to indicate a default character set or language --
- parameter field definitions MUST NOT assign a default character set
- or language.
-
-4.1. Combining Character Set, Language, and Parameter Continuations
-
- Character set and language information may be combined with the
- parameter continuation mechanism. For example:
-
- Content-Type: application/x-stuff
- title*0*=us-ascii'en'This%20is%20even%20more%20
- title*1*=%2A%2A%2Afun%2A%2A%2A%20
- title*2="isn't it!"
-
- Note that:
-
- (1) Language and character set information only appear at
- the beginning of a given parameter value.
-
- (2) Continuations do not provide a facility for using more
- than one character set or language in the same
- parameter value.
-
- (3) A value presented using multiple continuations may
- contain a mixture of encoded and unencoded segments.
-
-
-
-
-
-Freed & Moore Standards Track [Page 5]
-
-RFC 2231 MIME Value and Encoded Word Extensions November 1997
-
-
- (4) The first segment of a continuation MUST be encoded if
- language and character set information are given.
-
- (5) If the first segment of a continued parameter value is
- encoded the language and character set field delimiters
- MUST be present even when the fields are left blank.
-
-5. Language specification in Encoded Words
-
- RFC 2047 provides support for non-US-ASCII character sets in RFC 822
- message header comments, phrases, and any unstructured text field.
- This is done by defining an encoded word construct which can appear
- in any of these places. Given that these are fields intended for
- display, it is sometimes necessary to associate language information
- with encoded words as well as just the character set. This
- specification extends the definition of an encoded word to allow the
- inclusion of such information. This is simply done by suffixing the
- character set specification with an asterisk followed by the language
- tag. For example:
-
- From: =?US-ASCII*EN?Q?Keith_Moore?= <address@hidden>
-
-6. IMAP4 Handling of Parameter Values
-
- IMAP4 [RFC-2060] servers SHOULD decode parameter value continuations
- when generating the BODY and BODYSTRUCTURE fetch attributes.
-
-7. Modifications to MIME ABNF
-
- The ABNF for MIME parameter values given in RFC 2045 is:
-
- parameter := attribute "=" value
-
- attribute := token
- ; Matching of attributes
- ; is ALWAYS case-insensitive.
-
- This specification changes this ABNF to:
-
- parameter := regular-parameter / extended-parameter
-
- regular-parameter := regular-parameter-name "=" value
-
- regular-parameter-name := attribute [section]
-
- attribute := 1*attribute-char
-
-
-
-
-
-Freed & Moore Standards Track [Page 6]
-
-RFC 2231 MIME Value and Encoded Word Extensions November 1997
-
-
- attribute-char := <any (US-ASCII) CHAR except SPACE, CTLs,
- "*", "'", "%", or tspecials>
-
- section := initial-section / other-sections
-
- initial-section := "*0"
-
- other-sections := "*" ("1" / "2" / "3" / "4" / "5" /
- "6" / "7" / "8" / "9") *DIGIT)
-
- extended-parameter := (extended-initial-name "="
- extended-value) /
- (extended-other-names "="
- extended-other-values)
-
- extended-initial-name := attribute [initial-section] "*"
-
- extended-other-names := attribute other-sections "*"
-
- extended-initial-value := [charset] "'" [language] "'"
- extended-other-values
-
- extended-other-values := *(ext-octet / attribute-char)
-
- ext-octet := "%" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
-
- charset := <registered character set name>
-
- language := <registered language tag [RFC-1766]>
-
- The ABNF given in RFC 2047 for encoded-words is:
-
- encoded-word := "=?" charset "?" encoding "?" encoded-text "?="
-
- This specification changes this ABNF to:
-
- encoded-word := "=?" charset ["*" language] "?" encoded-text "?="
-
-8. Character sets which allow specification of language
-
- In the future it is likely that some character sets will provide
- facilities for inline language labeling. Such facilities are
- inherently more flexible than those defined here as they allow for
- language switching in the middle of a string.
-
-
-
-
-
-
-
-Freed & Moore Standards Track [Page 7]
-
-RFC 2231 MIME Value and Encoded Word Extensions November 1997
-
-
- If and when such facilities are developed they SHOULD be used in
- preference to the language labeling facilities specified here. Note
- that all the mechanisms defined here allow for the omission of
- language labels so as to be able to accommodate this possible future
- usage.
-
-9. Security Considerations
-
- This RFC does not discuss security issues and is not believed to
- raise any security issues not already endemic in electronic mail and
- present in fully conforming implementations of MIME.
-
-10. References
-
- [RFC-822]
- Crocker, D., "Standard for the Format of ARPA Internet
- Text Messages", STD 11, RFC 822 August 1982.
-
- [RFC-1766]
- Alvestrand, H., "Tags for the Identification of
- Languages", RFC 1766, March 1995.
-
- [RFC-2045]
- Freed, N., and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message
- Bodies", RFC 2045, December 1996.
-
- [RFC-2046]
- Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part Two: Media Types", RFC 2046,
- December 1996.
-
- [RFC-2047]
- Moore, K., "Multipurpose Internet Mail Extensions (MIME)
- Part Three: Representation of Non-ASCII Text in Internet
- Message Headers", RFC 2047, December 1996.
-
- [RFC-2048]
- Freed, N., Klensin, J. and J. Postel, "Multipurpose
- Internet Mail Extensions (MIME) Part Four: MIME
- Registration Procedures", RFC 2048, December 1996.
-
- [RFC-2049]
- Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part Five: Conformance Criteria and
- Examples", RFC 2049, December 1996.
-
-
-
-
-
-Freed & Moore Standards Track [Page 8]
-
-RFC 2231 MIME Value and Encoded Word Extensions November 1997
-
-
- [RFC-2060]
- Crispin, M., "Internet Message Access Protocol - Version
- 4rev1", RFC 2060, December 1996.
-
- [RFC-2119]
- Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [RFC-2130]
- Weider, C., Preston, C., Simonsen, K., Alvestrand, H.,
- Atkinson, R., Crispin, M., and P. Svanberg, "Report from the
- IAB Character Set Workshop", RFC 2130, April 1997.
-
- [RFC-2183]
- Troost, R., Dorner, S. and K. Moore, "Communicating
- Presentation Information in Internet Messages: The
- Content-Disposition Header", RFC 2183, August 1997.
-
-11. Authors' Addresses
-
- Ned Freed
- Innosoft International, Inc.
- 1050 Lakes Drive
- West Covina, CA 91790
- USA
-
- Phone: +1 626 919 3600
- Fax: +1 626 919 3614
- EMail: address@hidden
-
-
- Keith Moore
- Computer Science Dept.
- University of Tennessee
- 107 Ayres Hall
- Knoxville, TN 37996-1301
- USA
-
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-Freed & Moore Standards Track [Page 9]
-
-RFC 2231 MIME Value and Encoded Word Extensions November 1997
-
-
-12. Full Copyright Statement
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Freed & Moore Standards Track [Page 10]
-
-
diff --git a/doc/rfc/rfc2245.txt b/doc/rfc/rfc2245.txt
deleted file mode 100644
index 1025a90..0000000
--- a/doc/rfc/rfc2245.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group C. Newman
-Request for Comments: 2245 Innosoft
-Category: Standards Track November 1997
-
-
- Anonymous SASL Mechanism
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
-Abstract
-
- It is common practice on the Internet to permit anonymous access to
- various services. Traditionally, this has been done with a plain
- text password mechanism using "anonymous" as the user name and
- optional trace information, such as an email address, as the
- password. As plaintext login commands are not permitted in new IETF
- protocols, a new way to provide anonymous login is needed within the
- context of the SASL [SASL] framework.
-
-1. Conventions Used in this Document
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
- in this document are to be interpreted as defined in "Key words for
- use in RFCs to Indicate Requirement Levels" [KEYWORDS].
-
-2. Anonymous SASL mechanism
-
- The mechanism name associated with anonymous access is "ANONYMOUS".
- The mechanism consists of a single message from the client to the
- server. The client sends optional trace information in the form of a
- human readable string. The trace information should take one of
- three forms: an Internet email address, an opaque string which does
- not contain the '@' character and can be interpreted by the system
- administrator of the client's domain, or nothing. For privacy
- reasons, an Internet email address should only be used with
- permission from the user.
-
-
-
-
-
-Newman Standards Track [Page 1]
-
-RFC 2245 Anonymous SASL Mechanism November 1997
-
-
- A server which permits anonymous access will announce support for the
- ANONYMOUS mechanism, and allow anyone to log in using that mechanism,
- usually with restricted access.
-
- The formal grammar for the client message using Augmented BNF [ABNF]
- follows.
-
- message = [email / token]
-
- TCHAR = %x20-3F / %x41-7E
- ;; any printable US-ASCII character except '@'
-
- email = addr-spec
- ;; as defined in [IMAIL], except with no free
- ;; insertion of linear-white-space, and the
- ;; local-part MUST either be entirely enclosed in
- ;; quotes or entirely unquoted
-
- token = 1*255TCHAR
-
-3. Example
-
-
- Here is a sample anonymous login between an IMAP client and server.
- In this example, "C:" and "S:" indicate lines sent by the client and
- server respectively. If such lines are wrapped without a new "C:" or
- "S:" label, then the wrapping is for editorial clarity and is not
- part of the command.
-
- Note that this example uses the IMAP profile [IMAP4] of SASL. The
- base64 encoding of challenges and responses, as well as the "+ "
- preceding the responses are part of the IMAP4 profile, not part of
- SASL itself. Newer profiles of SASL will include the client message
- with the AUTHENTICATE command itself so the extra round trip below
- (the server response with an empty "+ ") can be eliminated.
-
- In this example, the user's opaque identification token is "sirhc".
-
- S: * OK IMAP4 server ready
- C: A001 CAPABILITY
- S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-MD5 AUTH=ANONYMOUS
- S: A001 OK done
- C: A002 AUTHENTICATE ANONYMOUS
- S: +
- C: c2lyaGM=
- S: A003 OK Welcome, trace information has been logged.
-
-
-
-
-
-Newman Standards Track [Page 2]
-
-RFC 2245 Anonymous SASL Mechanism November 1997
-
-
-4. Security Considerations
-
- The anonymous mechanism grants access to information by anyone. For
- this reason it should be disabled by default so the administrator can
- make an explicit decision to enable it.
-
- If the anonymous user has any write privileges, a denial of service
- attack is possible by filling up all available space. This can be
- prevented by disabling all write access by anonymous users.
-
- If anonymous users have read and write access to the same area, the
- server can be used as a communication mechanism to anonymously
- exchange information. Servers which accept anonymous submissions
- should implement the common "drop box" model which forbids anonymous
- read access to the area where anonymous submissions are accepted.
-
- If the anonymous user can run many expensive operations (e.g., an
- IMAP SEARCH BODY command), this could enable a denial of service
- attack. Servers are encouraged to limit the number of anonymous
- users and reduce their priority or limit their resource usage.
-
- If there is no idle timeout for the anonymous user and there is a
- limit on the number of anonymous users, a denial of service attack is
- enabled. Servers should implement an idle timeout for anonymous
- users.
-
- The trace information is not authenticated so it can be falsified.
- This can be used as an attempt to get someone else in trouble for
- access to questionable information. Administrators trying to trace
- abuse need to realize this information may be falsified.
-
- A client which uses the user's correct email address as trace
- information without explicit permission may violate that user's
- privacy. Information about who accesses an anonymous archive on a
- sensitive subject (e.g., sexual abuse) has strong privacy needs.
- Clients should not send the email address without explicit permission
- of the user and should offer the option of supplying no trace token
- -- thus only exposing the source IP address and time. Anonymous
- proxy servers could enhance this privacy, but would have to consider
- the resulting potential denial of service attacks.
-
- Anonymous connections are susceptible to man in the middle attacks
- which view or alter the data transferred. Clients and servers are
- encouraged to support external integrity and encryption mechanisms.
-
- Protocols which fail to require an explicit anonymous login are more
- susceptible to break-ins given certain common implementation
- techniques. Specifically, Unix servers which offer user login may
-
-
-
-Newman Standards Track [Page 3]
-
-RFC 2245 Anonymous SASL Mechanism November 1997
-
-
- initially start up as root and switch to the appropriate user id
- after an explicit login command. Normally such servers refuse all
- data access commands prior to explicit login and may enter a
- restricted security environment (e.g., the Unix chroot function) for
- anonymous users. If anonymous access is not explicitly requested,
- the entire data access machinery is exposed to external security
- attacks without the chance for explicit protective measures.
- Protocols which offer restricted data access should not allow
- anonymous data access without an explicit login step.
-
-5. References
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text
- Messages", STD 11, RFC 822, August 1982.
-
- [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
- 4rev1", RFC 2060, December 1996.
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)",
- RFC 2222, October 1997.
-
-6. Author's Address
-
- Chris Newman
- Innosoft International, Inc.
- 1050 Lakes Drive
- West Covina, CA 91790 USA
-
- Email: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Newman Standards Track [Page 4]
-
-RFC 2245 Anonymous SASL Mechanism November 1997
-
-
-7. Full Copyright Statement
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Newman Standards Track [Page 5]
-
diff --git a/doc/rfc/rfc2298.txt b/doc/rfc/rfc2298.txt
deleted file mode 100644
index 6283651..0000000
--- a/doc/rfc/rfc2298.txt
+++ /dev/null
@@ -1,1571 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Fajman
-Request for Comments: 2298 National Institutes of Health
-Category: Standards Track March 1998
-
-
- An Extensible Message Format
- for Message Disposition 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.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
-Abstract
-
- This memo defines a MIME content-type that may be used by a mail user
- agent (UA) or electronic mail gateway to report the disposition of a
- message after it has been sucessfully delivered to a recipient. This
- content-type is intended to be machine-processable. Additional
- message headers are also defined to permit Message Disposition
- Notifications (MDNs) to be requested by the sender of a message. The
- purpose is to extend Internet Mail to support functionality often
- found in other messaging systems, such as X.400 and the proprietary
- "LAN-based" systems, and often referred to as "read receipts,"
- "acknowledgements," or "receipt notifications." The intention is to
- do this while respecting the privacy concerns that have often been
- expressed when such functions have been discussed in the past.
-
- Because many messages are sent between the Internet and other
- messaging systems (such as X.400 or the proprietary "LAN-based"
- systems), the MDN 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, in
- addition to those normally used in Internet Mail. Additional
- attributes may also be defined to support "tunneling" of foreign
- notifications through Internet Mail.
-
-
-
-
-
-
-
-
-Fajman Standards Track [Page 1]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
-Table of Contents
-
- 1. Introduction ............................................ 2
- 2. Requesting Message Disposition Notifications ............ 3
- 3. Format of a Message Disposition Notification ............ 7
- 4. Timeline of events ...................................... 17
- 5. Conformance and Usage Requirements ...................... 18
- 6. Security Considerations ................................. 19
- 7. Collected Grammar ....................................... 20
- 8. Guidelines for Gatewaying MDNs .......................... 22
- 9. Example ................................................. 24
- 10. IANA Registration Forms ................................. 25
- 11. Acknowledgments ......................................... 26
- 12. References .............................................. 26
- 13. Author's Address ........................................ 27
- 14. Copyright ............................................... 28
-
-1. Introduction
-
- This memo defines a MIME content-type [5] for message disposition
- notifications (MDNs). An MDN can be used to notify the sender of a
- message of any of several conditions that may occur after successful
- delivery, such as display of the message contents, printing of the
- message, deletion (without display) of the message, or the
- recipient's refusal to provide MDNs. The "message/disposition-
- notification" content-type defined herein is intended for use within
- the framework of the "multipart/report" content type defined in RFC
- 1892 [7].
-
- This memo defines the format of the notifications and the RFC 822
- headers used to request them.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119.
-
-1.1 Purposes
-
- The MDNs defined in this memo are expected to serve several purposes:
-
- (a) Inform human beings of the disposition of messages after
- succcessful delivery, in a manner which is largely independent
- of human language;
-
- (b) Allow mail user agents to keep track of the disposition of
- messages sent, by associating returned MDNs with earlier message
- transmissions;
-
-
-
-
-Fajman Standards Track [Page 2]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- (c) Convey disposition notification requests and disposition
- notifications between Internet Mail and "foreign" mail systems
- via a gateway;
-
- (d) 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;
-
- (e) Allow language-independent, yet reasonably precise, indications
- of the disposition of a message to be delivered.
-
-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
- their user agents) to unambiguously associate an MDN with the
- message that was sent and the original recipient address for
- which the MDN is issued (if such information is available), even
- if the message was forwarded to another recipient address.
-
- (c) It must also be able to describe the disposition of a message
- independent of any particular human language or of the
- terminology of any particular mail system.
-
- (d) The specification must be extensible in order to accomodate
- future requirements.
-
-2. Requesting Message Disposition Notifications
-
- Message disposition notifications are requested by including a
- Disposition-Notification-To header in the message. Further
- information to be used by the recipient's UA in generating the MDN
- may be provided by including Original-Recipient and/or Disposition-
- Notification-Options headers in the message.
-
-2.1 The Disposition-Notification-To Header
-
- A request that the receiving user agent issue message disposition
- notifications is made by placing a Disposition-Notification-To header
- into the message. The syntax of the header, using the ABNF of RFC
- 822 [2], is
-
-
-
-
-Fajman Standards Track [Page 3]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox
-
- The mailbox token is as specified in RFC 822 [2].
-
- The presence of a Disposition-Notification-To header in a message is
- merely a request for an MDN. The recipients' user agents are always
- free to silently ignore such a request. Alternatively, an explicit
- denial of the request for information about the disposition of the
- message may be sent using the "denied" disposition in an MDN.
-
- An MDN MUST NOT itself have a Disposition-Notification-To header.
- An MDN MUST NOT be generated in response to an MDN.
-
- At most one MDN may be issued on behalf of each particular recipient
- by their user agent. That is, once an MDN has been issued on behalf
- of a recipient, no further MDNs may be issued on behalf of that
- recipient, even if another disposition is performed on the message.
- However, if a message is forwarded, an MDN may been issued for the
- recipient doing the forwarding and the recipient of the forwarded
- message may also cause an MDN to be generated.
-
- While Internet standards normally do not specify the behavior of user
- interfaces, it is strongly recommended that the user agent obtain the
- user's consent before sending an MDN. This consent could be obtained
- for each message through some sort of prompt or dialog box, or
- globally through the user's setting of a preference. The user might
- also indicate globally that MDNs are never to be sent or that a
- "denied" MDN is always sent in response to a request for an MDN.
-
- MDNs SHOULD NOT be sent automatically if the address in the
- Disposition-Notification-To header differs from the address in the
- Return-Path header (see RFC 822 [2]). In this case, confirmation
- from the user SHOULD be obtained, if possible. If obtaining consent
- is not possible (e.g., because the user is not online at the time),
- then an MDN SHOULD NOT be sent.
-
- Confirmation from the user SHOULD be obtained (or no MDN sent) if
- there is no Return-Path header in the message, or if there is more
- than one distinct address in the Disposition-Notification-To header.
-
- The comparison of the addresses should be done using only the addr-
- spec (local-part "@" domain) portion, excluding any phrase and route.
- The comparison MUST be case-sensitive for the local-part and case-
- insensitive for the domain part.
-
- If the message contains more than one Return-Path header, the
- implementation may pick one to use for the comparison, or treat the
- situation as a failure of the comparison.
-
-
-
-Fajman Standards Track [Page 4]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- The reason for not automatically sending an MDN if the comparison
- fails or more than one address is specified is to reduce the
- possibilities for mail loops and use of MDNs for mail bombing.
-
- A message that contains a Disposition-Notification-To header SHOULD
- also contain a Message-ID header as specified in RFC 822 [2]. This
- will permit automatic correlation of MDNs with original messages by
- user agents.
-
- If it is desired to request message disposition notifications for
- some recipients and not others, two copies of the message should be
- sent, one with an Disposition-Notification-To header and one without.
- Many of the other headers of the message (e.g., To, cc) will be the
- same in both copies. The recipients in the respective message
- envelopes determine for whom message disposition notifications are
- requested and for whom they are not. If desired, the Message-ID
- header may be the same in both copies of the message. Note that
- there are other situations (e.g., bcc) in which it is necessary to
- send multiple copies of a message with slightly different headers.
- The combination of such situations and the need to request MDNs for a
- subset of all recipients may result in more than two copies of a
- message being sent, some with a Disposition- Notification-To header
- and some without.
-
- Messages posted to newsgroups SHOULD NOT have a Disposition-
- Notification-To header.
-
-2.2 The Disposition-Notification-Options Header
-
- Future extensions to this specification may require that information
- be supplied to the recipient's UA for additional control over how and
- what MDNs are generated. The Disposition-Notification-Options header
- provides an extensible mechanism for such information. The syntax of
- this header, using the ABNF of RFC 822 [2], is
-
- Disposition-Notification-Options =
- "Disposition-Notification-Options" ":"
- disposition-notification-parameters
-
- disposition-notification-parameters = parameter *(";" parameter)
-
- parameter = attribute "=" importance "," 1#value
-
- importance = "required" / "optional"
-
- The definitions of attribute and value are as in the definition of
- the Content-Type header in RFC 2045 [4].
-
-
-
-
-Fajman Standards Track [Page 5]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- An importance of "required" indicates that interpretation of the
- parameter is necessary for proper generation of an MDN in response to
- this request. If a UA does not understand the meaning of the
- parameter, it MUST NOT generate an MDN with any disposition type
- other than "failed" in response to the request. An importance of
- "optional" indicates that a UA that does not understand the meaning
- of this parameter MAY generate an MDN in response anyway, ignoring
- the value of the parameter.
-
- No parameters are defined in this specification. Parameters may be
- defined in the future by later revisions or extensions to this
- specification. Parameter attribute names beginning with "X-" will
- never be defined as standard names; such names are reserved for
- experimental use. MDN parameter names not beginning with "X-" MUST
- be registered with the Internet Assigned Numbers Authority (IANA) and
- described in a standards-track RFC or an experimental RFC approved by
- the IESG. See Section 10 for a registration form.
-
- If a required parameter is not understood or contains some sort of
- error, the receiving UA SHOULD issue an MDN with a disposition type
- of "failed" (see Section 3.2.6) and include a Failure field (see
- Section 3.2.7) that further describes the problem. MDNs with the a
- disposition type of "failed" and a "Failure" field MAY also be
- generated when other types of errors are detected in the parameters
- of the Disposition-Notification-Options header.
-
- However, an MDN with a disposition type of "failed" MUST NOT be
- generated if the user has indicated a preferance that MDNs are not to
- be sent. If user consent would be required for an MDN of some other
- disposition type to be sent, user consent SHOULD also be obtained
- before sending an MDN with a disposition type of "failed".
-
-2.3 The Original-Recipient Header
-
- Since electronic mail addresses may be rewritten while the message is
- in transit, it is useful for the original recipient address to be
- made available by the delivering MTA. The delivering MTA may be able
- to obtain this information from the ORCPT parameter of the SMTP RCPT
- TO command, as defined in RFC 1891 [8]. If this information is
- available, the delivering MTA SHOULD insert an Original-Recipient
- header at the beginning of the message (along with the Return-Path
- header). The delivering MTA MAY delete any other Original-Recipient
- headers that occur in the message. The syntax of this header, using
- the ABNF of RFC 822 [2], is as follows
-
- original-recipient-header =
- "Original-Recipient" ":" address-type ";" generic-address
-
-
-
-
-Fajman Standards Track [Page 6]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- The address-type and generic-address token are as as specified in the
- description of the Original-Recipient field in section 3.2.3.
-
- The purpose of carrying the original recipient information and
- returning it in the MDN is to permit automatic correlation of MDNs
- with the original message on a per-recipient basis.
-
-2.4 Use with the Message/Partial Content Type
-
- The use of the headers Disposition-Notification-To, Disposition-
- Notification-Options, and Original-Recipient with the MIME
- Message/partial content type (RFC 2046 [5]) requires further
- definition.
-
- When a message is segmented into two or more message/partial
- fragments, the three headers mentioned in the above paragraph SHOULD
- be placed in the "inner" or "enclosed" message (using the terms of
- RFC 2046 [5]). These headers SHOULD NOT be used in the headers of
- any of the fragments themselves.
-
- When the multiple message/partial fragments are reassembled, the
- following applies. If these headers occur along with the other
- headers of a message/partial fragment message, they pertain to an MDN
- to be generated for the fragment. If these headers occur in the
- headers of the "inner" or "enclosed" message (using the terms of RFC
- 2046 [5]), they pertain to an MDN to be generated for the reassembled
- message. Section 5.2.2.1 of RFC 2046 [5]) is amended to specify
- that, in addition to the headers specified there, the three headers
- described in this specification are to be appended, in order, to the
- headers of the reassembled message. Any occurances of the three
- headers defined here in the headers of the initial enclosing message
- must not be copied to the reassembled message.
-
-3. Format of a Message Disposition Notification
-
- A message disposition notification is a MIME message with a top-
- level content-type of multipart/report (defined in RFC 1892 [7]).
- When a multipart/report content is used to transmit an MDN:
-
- (a) The report-type parameter of the multipart/report content is
- "disposition-notification".
-
- (b) The first component of the multipart/report contains a human-
- readable explanation of the MDN, as described in RFC 1892 [7].
-
- (c) The second component of the multipart/report is of content-type
- message/disposition-notification, described in section 3.1 of
- this document.
-
-
-
-Fajman Standards Track [Page 7]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- (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. The decision of whether or not to return the
- message or part of the message is up to the UA generating the
- MDN. However, in the case of encrypted messages requesting
- MDNs, encrypted message text MUST be returned, if it is returned
- at all, only in its original encrypted form.
-
- NOTE: For message dispostion notifications gatewayed from
- foreign systems, the headers of the original message may not be
- available. In this case the third component of the MDN 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 and date fields from the
- original message.
-
- The MDN MUST be addressed (in both the message header and the
- transport envelope) to the address(es) from the Disposition-
- Notification-To header from the original message for which the MDN is
- being generated.
-
- The From field of the message header of the MDN MUST contain the
- address of the person for whom the message disposition notification
- is being issued.
-
- The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST be
- null (<>), specifying that no Delivery Status Notification messages
- or other messages indicating successful or unsuccessful delivery are
- to be sent in response to an MDN.
-
- A message disposition notification MUST NOT itself request an MDN.
- That is, it MUST NOT contain a Disposition-Notification-To header.
-
- The Message-ID header (if present) for an MDN MUST be different from
- the Message-ID of the message for which the MDN is being issued.
-
- A particular MDN describes the disposition of exactly one message for
- exactly one recipient. Multiple MDNs may be generated as a result of
- one message submission, one per recipient. However, due to the
- circumstances described in Section 2.1, MDNs may not be generated for
- some recipients for which MDNs were requested.
-
-3.1 The message/disposition-notification content-type
-
- The message/disposition-notification content-type is defined as
- follows:
-
- MIME type name: message
-
-
-
-Fajman Standards Track [Page 8]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- MIME subtype name: disposition-notification
- 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 6 of this memo.
-
- The message/disposition-notification report type for use in the
- multipart/report is "disposition-notification".
-
- The body of a message/disposition-notification consists of one or
- more "fields" formatted according to the ABNF of RFC 822 header
- "fields" (see [2]). Using the ABNF of RFC 822, the syntax of the
- message/disposition-notification content is as follows:
-
- disposition-notification-content = [ reporting-ua-field CRLF ]
- [ mdn-gateway-field CRLF ]
- [ original-recipient-field CRLF ]
- final-recipient-field CRLF
- [ original-message-id-field CRLF ]
- disposition-field CRLF
- *( failure-field CRLF )
- *( error-field CRLF )
- *( warning-field CRLF )
- *( extension-field CRLF )
-
-3.1.1 General conventions for fields
-
- Since these fields are defined according to the rules of RFC 822 [2],
- 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 notification fields may
- use the "encoded-word" construct defined in RFC 2047 [6].
-
-3.1.2 "*-type" subfields
-
- Several fields consist of a "-type" subfield, followed by a semi-
- colon, followed by "*text". For these fields, the keyword used in
- the address-type or MTA-type subfield indicates the expected format
- of the address or MTA-name that follows.
-
- The "-type" subfields are defined as follows:
-
-
-
-
-Fajman Standards Track [Page 9]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- (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) An "MTA-name-type" specifies the format of a mail transfer
- agent 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 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-type and mta-name-type values, along with
- descriptions of the meanings of each, or a reference to a one or more
- specifications that provide such descriptions. (The "rfc822"
- address-type is defined in RFC 1891 [8].) Registration forms for
- address-type and mta-name-type appear in RFC 1894 [9].
-
- IANA will not accept registrations for any address-type name that
- begins with "X-". These type names are reserved for experimental
- use.
-
-3.1.3 Lexical tokens imported from RFC 822
-
- The following lexical tokens, defined in RFC 822 [2], are used in the
- ABNF grammar for MDNs: atom, CRLF, mailbox, msg-id, text.
-
-3.2 Message/disposition-notification Fields
-
-3.2.1 The Reporting-UA field
-
- reporting-ua-field = "Reporting-UA" ":" ua-name
- [ ";" ua-product ]
-
- ua-name = *text
-
- ua-product = *text
-
- The Reporting-UA field is defined as follows:
-
- A MDN describes the disposition of a message after it has been
- delivered to a recipient. In all cases, the Reporting-UA is the UA
- that performed the disposition described in the MDN. This field is
-
-
-
-Fajman Standards Track [Page 10]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- optional, but recommended. For Internet Mail user agents, it is
- recommended that this field contain both the DNS name of the
- particular instance of the UA that generated the MDN and the name of
- the product. For example,
-
- Reporting-UA: rogers-mac.dcrt.nih.gov; Foomail 97.1
-
- If the reporting UA consists of more than one component (e.g., a base
- program and plug-ins), this may be indicated by including a list of
- product names.
-
-3.2.2 The MDN-Gateway field
-
- The MDN-Gateway field indicates the name of the gateway or MTA that
- translated a foreign (non-Internet) message disposition notification
- into this MDN. This field MUST appear in any MDN which was
- translated by a gateway from a foreign system into MDN format, and
- MUST NOT appear otherwise.
-
- mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name
-
- mta-name = *text
-
- 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.
-
-3.2.3 Original-Recipient field
-
- The Original-Recipient field indicates the original recipient address
- as specified by the sender of the message for which the MDN is being
- issued. For Internet Mail messages the value of the
-
- Original-Recipient field is obtained from the Original-Recipient
- header from the message for which the MDN is being generated. If
- there is no Original-Recipient header in the message, then the
- Original-Recipient field MUST be omitted, unless the same information
- is reliably available some other way. If there is an Original-
- Recipient header in the original message (or original recipient
- information is reliably available some other way), then the
- Original-Recipient field must be supplied. If there is more than one
- Original-Recipient header in the message, the UA may choose the one
- to use or act as if no Original-Recipient header is present.
-
- original-recipient-field =
- "Original-Recipient" ":" address-type ";" generic-address
-
- generic-address = *text
-
-
-
-Fajman Standards Track [Page 11]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- 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 RFC 822 [2]. The value
- "unknown" should be used if the Reporting UA cannot determine the
- type of the original recipient address from the message envelope.
- This address is the same as that provided by the sender and can be
- used to automatically correlate MDN reports with original messages on
- a per recipient basis.
-
-3.2.4 Final-Recipient field
-
- The Final-Recipient field indicates the recipient for which the MDN
- is being issued. This field MUST be present.
-
- 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 From header of
- the MDN) as it was when the MDN was generated by the UA.
-
- 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 MDN with a
- particular message recipient.
-
- 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".
-
- Since mailbox addresses (including those used in the Internet) may be
- case sensitive, the case of alphabetic characters in the address MUST
- be preserved.
-
-3.2.5 Original-Message-ID field
-
- The Original-Message-ID field indicates the message-ID of the message
- for which the MDN is being issued. It is obtained from the Message-
- ID header of the message for which the MDN is issued. This field
- MUST be present if the original message contained a Message-ID
- header. The syntax of the field is
-
-
-
-
-Fajman Standards Track [Page 12]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- original-message-id-field = "Original-Message-ID" ":" msg-id
-
- The msg-id token is as specified in RFC 822 [2].
-
-3.2.6 Disposition field
-
- The Disposition field indicates the action performed by the
- Reporting-UA on behalf of the user. This field MUST be present.
-
- The syntax for the Disposition field is:
-
- disposition-field = "Disposition" ":" disposition-mode ";"
- disposition-type
- [ '/' disposition-modifier
- *( "," dispostion-modifier ) ]
-
- disposition-mode = action-mode "/" sending-mode
-
- action-mode = "manual-action" / "automatic-action"
-
- sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
-
- disposition-type = "displayed"
- / "dispatched"
- / "processed"
- / "deleted"
- / "denied"
- / "failed"
-
- disposition-modifier = ( "error" / "warning" )
- / ( "superseded" / "expired" /
- "mailbox-terminated" )
- / disposition-modifier-extension
-
- disposition-modifier-extension = atom
-
- The disposition-mode, disposition-type and disposition-modifier may
- be spelled in any combination of upper and lower case characters.
-
-3.2.6.1 Disposition modes
-
- The following disposition modes are defined:
-
- "manual-action" The disposition described by the
- disposition type was a result of an
- explicit instruction by the user rather
- than some sort of automatically performed
- action.
-
-
-
-Fajman Standards Track [Page 13]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- "automatic-action" The disposition described by the
- disposition type was a result of an
- automatic action, rather than an explicit
- instruction by the user for this message.
-
- "Manual-action" and "automatic-action" are
- mutually exclusive. One or the other must
- be specified.
-
- "MDN-sent-manually" The user explicity gave permission for
- this particular MDN to be sent.
-
- "MDN-sent-automatically" The MDN was sent because the UA had
- previously been configured to do so
- automatically.
-
- "MDN-sent-manually" and "MDN-sent-
- automatically" are mutually exclusive.
- One or the other must be specified.
-
-3.2.6.2 Disposition types
-
- The following disposition-types are defined:
-
- "displayed" The message has been displayed by the UA to someone
- reading the recipient's mailbox. There is
- no guarantee that the content has been
- read or understood.
-
-
- "dispatched" The message has been sent somewhere in some manner
- (e.g., printed, faxed, forwarded) without
- necessarily having been previously
- displayed to the user. The user may or
- may not see the message later.
-
- "processed" The message has been processed in some manner (i.e.,
- by some sort of rules or server) without
- being displayed to the user. The user may
- or may not see the message later, or there
- may not even be a human user associated
- with the mailbox.
-
- "deleted" The message has been deleted. The recipient may or
- may not have seen the message. The
- recipient might "undelete" the message at
- a later time and read the message.
-
-
-
-
-Fajman Standards Track [Page 14]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- "denied" The recipient does not wish the sender to be informed
- of the message's disposition. A UA may
- also siliently ignore message disposition
- requests in this situation.
-
- "failed" A failure occurred that prevented the proper
- generation of an MDN. More information
- about the cause of the failure may be
- contained in a Failure field. The
- "failed" disposition type is not to be
- used for the situation in which there is
- is some problem in processing the message
- other than interpreting the request for an
- MDN. The "processed" or other disposition
- type with appropriate disposition
- modifiers is to be used in such
- situations.
-
-3.2.6.3 Disposition modifiers
-
- The following disposition modifiers are defined:
-
- "error" An error of some sort occurred
- that prevented successful
- processing of the message.
- Further information is contained
- in an Error field.
-
- "warning" The message was successfully
- processed but some sort of
- exceptional condition occurred.
- Further information is contained
- in a Warning field.
-
- "superseded" The message has been
- automatically rendered obsolete by
- another message received. The
- recipient may still access and
- read the message later.
-
- "expired" The message has reached its
- expiration date and has been
- automatically removed from the
- recipient's mailbox.
-
- "mailbox-terminated" The recipient's mailbox has been
- terminated and all message in it
- automatically removed.
-
-
-
-Fajman Standards Track [Page 15]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- "Obsoleted", "expired", and
- "terminated" are to be used with
- the "deleted" disposition type and
- the "autoaction" and "autosent"
- disposition modifiers.
-
- disposition-modifier-extension Additional disposition modifiers
- may be defined in the future by
- later revisions or extensions to
- this specification. Disposition
- value names beginning with "X-"
- will never be defined as standard
- values; such names are reserved
- for experimental use. MDN
- disposition value names NOT
- beginning with "X-" MUST be
- registered with the Internet
- Assigned Numbers Authority (IANA)
- and described in a standards-
- track RFC or an experimental RFC
- approved by the IESG. See Section
- 10 for a registration form. MDNs
- with disposition modifier names
- not understood by the receiving UA
- MAY be silently ignored or placed
- in the user's mailbox without
- special inter- pretation. They
- MUST not cause any error message
- to be sent to the sender of the
- MDN.
-
- If an UA developer does not wish
- to register the meanings of such
- disposition modifier extensions,
- "X-" modifiers may be used for
- this purpose. To avoid name
- collisions, the name of the UA
- implementation should follow the
- "X-", (e.g. "X-Foomail-fratzed").
-
- It is not required that a UA be able to generate all of the possible
- values of the Disposition field.
-
- One and only one MDN may be issued on behalf of each particular
- recipient by their user agent. That is, once an MDN has been issued
- on behalf of a recipient, no further MDNs may be issued on behalf of
- that recipient, even if another disposition is performed on the
- message. However, if a message is forwarded, a "dispatched" MDN may
-
-
-
-Fajman Standards Track [Page 16]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- been issued for the recipient doing the forwarding and the recipient
- of the forwarded message may also cause an MDN to be generated.
-
-3.2.7 Failure, Error and Warning fields
-
- The Failure, Error and Warning fields are used to supply additional
- information in the form of text messages when the "failure"
- disposition type, "error" disposition modifier, and/or the "warning"
- disposition modifer appear. The syntax is
-
- failure-field = "Failure" ":" *text
-
- error-field = "Error" ":" *text
-
- warning-field = "Warning" ":" *text
-
-3.3 Extension fields
-
- Additional MDN 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. MDN field names NOT beginning with
- "X-" MUST be registered with the Internet Assigned Numbers Authority
- (IANA) and described in a standards-track RFC or an experimental RFC
- approved by the IESG. See Section 10 for a registration form.
-
- Extension MDN fields may be defined for the following reasons:
-
- (a) To allow additional information from foreign disposition
- reports to be tunneled through Internet MDNs. The names of such
- MDN fields should begin with an indication of the foreign
- environment name (e.g. X400-Physical-Forwarding-Address).
-
- (b) To allow transmission of diagnostic information which is
- specific to a particular user agent (UA). The names of such MDN
- fields should begin with an indication of the UA implementation
- which produced the MDN. (e.g. Foomail-information).
-
- If an application 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 application implementation
- should follow the "X-", (e.g. "X-Foomail-Log-ID" or "X-EDI-info").
-
-4. Timeline of events
-
- The following timeline shows when various events in the processing of
- a message and generation of MDNs take place:
-
-
-
-
-Fajman Standards Track [Page 17]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- -- User composes message
-
- -- User tells UA to send message
-
- -- UA passes message to MTA (original recipient information
- passed along)
-
- -- MTA sends message to next MTA
-
- -- Final MTA receives message
-
- -- Final MTA delivers message to UA (possibily generating DSN)
-
- -- UA performs automatic processing and generates corresponding
- MDNs ("dispatched", "processed", "deleted", "denied" or "failed"
- disposition type with "automatic-action" and "MDN-sent-
- automatically" disposition modes)
-
- -- UA displays list of messages to user
-
- -- User selects a message and requests that some action be
- performed on it.
-
- -- UA performs requested action and, with user's permission,
- sends appropriate MDN ("displayed", "dispatched", "processed",
- "deleted", "denied" or "failed" disposition type with "manual-
- action" and "MDN-sent-manually" or "MDN-sent-automatically"
- disposition mode).
-
- -- User possibly performs other actions on message, but no
- further MDNs are generated.
-
-5. Conformance and Usage Requirements
-
- A UA or gateway conforms to this specification if it generates MDNs
- according to the protocol defined in this memo. It is not necessary
- to be able to generate all of the possible values of the Disposition
- field.
-
- UAs and gateways MUST NOT generate the Original-Recipient field of an
- MDN unless the mail protocols provide 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 RFC
- 1891 [8] permits such information to be carried in the envelope if it
- is available. The Original-Recipient header defined in this document
- provides a way for the MTA to pass the original recipient address to
- the UA.
-
-
-
-
-Fajman Standards Track [Page 18]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- Each sender-specified recipient address may result in more than one
- MDN. If an MDN is requested for a recipient that is forwarded to
- multiple recipients of an "alias" (as defined in RFC 1891 [8],
- section 6.2.7.3), each of the recipients may issue an MDN.
-
- Successful distribution of a message to a mailing list exploder
- SHOULD be considered final disposition of the message. A mailing
- list exploder may issue an MDN with a disposition type of "processed"
- and disposition modes of "automatic-action" and "MDN- sent-
- automatically" indicating that the message has been forwarded to the
- list. In this case, the request for MDNs is not propogated to the
- members of the list.
-
- Alternaively, the mailing list exploder may issue no MDN and
- propogate the request for MDNs to all members of the list. The
- latter behavior is not recommended for any but small, closely knit
- lists, as it might cause large numbers of MDNs to be generated and
- may cause confidential subscribers to the list to be revealed. It is
- also permissible for the mailing list exploder to direct MDNs to
- itself, correlate them, and produce a report to the original sender
- of the message.
-
- This specification places no restrictions on the processing of MDNs
- received by user agents or mailing lists.
-
-6. Security Considerations
-
- The following security considerations apply when using MDNs:
-
-6.1 Forgery
-
- MDNs 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 MDNs
- should take appropriate precautions to minimize the potential damage
- from denial-of-service attacks.
-
- Security threats related to forged MDNs include the sending of:
-
- (a) A falsified disposition notification when the indicated
- disposition of the message has not actually ocurred,
-
- (b) Unsolicited MDNs
-
-6.2 Confidentiality
-
- Another dimension of security is confidentiality. There may be cases
- in which a message recipient does not wish the disposition of
-
-
-
-Fajman Standards Track [Page 19]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- messages addressed to him to be known or is concerned that the
- sending of MDNs may reveal other confidential information (e.g., when
- the message was read). In this situation, it is acceptable for the
- UA to issue "denied" MDNs or to silently ignore requests for MDNs.
-
- If the Disposition-Notification-To header is passed on unmodified
- when a message is distributed to the subscribers of a mailing list,
- the subscribers to the list may be revealed to the sender of the
- original message by the generation of MDNs.
-
- Headers of the original message returned in part 3 of the
- multipart/report could reveal confidential information about host
- names and/or network topology inside a firewall.
-
- An unencrypted MDN could reveal confidential information about an
- encrypted message, especially if all or part of the original message
- is returned in part 3 of the multipart/report. Encrypted MDNs are
- not defined in this specification.
-
- In general, any optional MDN field may be omitted if the Reporting UA
- site or user 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 MDNs.
-
-6.3 Non-Repudiation
-
- Within the framework of today's Internet Mail, the MDNs defined in
- this document provide valuable information to the mail user; however,
- MDNs can not be relied upon as a guarantee that a message was or was
- not not seen by the recipient. Even if MDNs are not actively forged,
- they may be lost in transit. The MDN issuing mechanism may be
- bypassed in some manner by the recipient.
-
-7. Collected Grammar
-
- NOTE: The following lexical tokens are defined in RFC 822: atom,
- CRLF, mailbox, msg-id, text. The definitions of attribute and value
- are as in the definition of the Content-Type header in RFC 2045 [4].
-
- Message headers:
-
- mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox
-
- Disposition-Notification-Options =
- "Disposition-Notification-Options" ":"
- disposition-notification-parameters
-
-
-
-
-Fajman Standards Track [Page 20]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- disposition-notification-parameters = parameter *(";" parameter)
-
- parameter = attribute "=" importance "," 1#value
-
- importance = "required" / "optional"
-
- original-recipient-header =
- "Original-Recipient" ":" address-type ";" generic-address
-
-
- Report content:
-
- disposition-notification-content = [ reporting-ua-field CRLF ]
- [ mdn-gateway-field CRLF ]
- [ original-recipient-field CRLF ]
- final-recipient-field CRLF
- [ original-message-id-field CRLF ]
- disposition-field CRLF
- *( failure-field CRLF )
- *( error-field CRLF )
- *( warning-field CRLF )
- *( extension-field CRLF )
-
- address-type = atom
-
- mta-name-type = atom
-
- reporting-ua-field = "Reporting-UA" ":" ua-name
- [ ";" ua-product ]
-
- ua-name = *text
-
- ua-product = *text
-
- mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name
-
- mta-name = *text
-
- original-recipient-field =
- "Original-Recipient" ":" address-type ";" generic-address
-
- generic-address = *text
-
- final-recipient-field =
- "Final-Recipient" ":" address-type ";" generic-address
-
- disposition-field = "Disposition" ":" disposition-mode ";"
- disposition-type
-
-
-
-Fajman Standards Track [Page 21]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- [ '/' disposition-modifier
- *( "," dispostion-modifier ) ]
-
- disposition-mode = action-mode "/" sending-mode
-
- action-mode = "manual-action" / "automatic-action"
-
- sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
-
- disposition-type = "displayed"
- / "dispatched"
- / "processed"
- / "deleted"
- / "denied"
- / "failed"
-
- disposition-modifier = ( "error" / "warning" )
- / ( "superseded" / "expired" /
- "mailbox-terminated" )
- / disposition-modifier-extension
-
- disposition-modifier-extension = atom
-
- original-message-id-field = "Original-Message-ID" ":" msg-id
-
- failure-field = "Failure" ":" *text
-
- error-field = "Error" ":" *text
-
- warning-field = "Warning" ":" *text
-
- extension-field = extension-field-name ":" *text
-
- extension-field-name = atom
-
-8. Guidelines for Gatewaying MDNs
-
- NOTE: This section provides non-binding recommendations for the
- construction of mail gateways that wish to provide semi-transparent
- disposition notifications between the Internet and another electronic
- mail system. Specific MDN gateway requirements for a particular pair
- of mail systems may be defined by other documents.
-
-8.1 Gatewaying from other mail systems to MDNs
-
- A mail gateway may issue an MDN to convey the contents of a "foreign"
- disposition notification over Internet Mail. When there are
- appropriate mappings from the foreign notification elements to MDN
-
-
-
-Fajman Standards Track [Page 22]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- fields, the information may be transmitted in those MDN fields.
- Additional information (such as might be needed to tunnel the foreign
- notification through the Internet) may be defined in extension MDN
- fields. (Such fields should be given names that identify the foreign
- mail protocol, e.g. X400-* for X.400 protocol elements)
-
- The gateway must attempt to supply reasonable values for the
- Reporting-UA, Final-Recipient, and Disposition fields. These will
- normally be obtained by translating the values from the foreign
- notification into their Internet-style equivalents. However, some
- loss of information is to be expected.
-
- The sender-specified recipient address, and the original message-id,
- if present in the foreign notification, should be preserved in the
- Original-Recipient and Original-Message-ID fields.
-
- The gateway should also attempt to preserve the "final" recipient
- address from the foreign system. Whenever possible, foreign protocol
- elements should be encoded as meaningful printable ASCII strings.
-
- For MDNs produced from foreign disposition notifications, the name of
- the gateway MUST appear in the MDN-Gateway field of the MDN.
-
-8.2 Gatewaying from MDNs to other mail systems
-
- It may be possible to gateway MDNs from the Internet into a foreign
- mail system. The primary purpose of such gatewaying is to convey
- disposition information in a form that is usable by the destination
- system. A secondary purpose is to allow "tunneling" of MDNs through
- foreign mail systems, in case the MDN may be gatewayed back into the
- Internet.
-
- In general, the recipient of the MDN (i.e., the sender of the
- original message) will want to know, for each recipient: the closest
- available approximation to the original recipient address, and the
- disposition (displayed, printed, etc.).
-
- If possible, the gateway should attempt to preserve the Original-
- Recipient address and Original-Message-ID (if present), in the
- resulting foreign disposition report.
-
- If it is possible to tunnel an MDN through the destination
- environment, the gateway specification may define a means of
- preserving the MDN information in the disposition reports used by
- that environment.
-
-
-
-
-
-
-Fajman Standards Track [Page 23]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
-9. Example
-
- NOTE: This example is provided as illustration only, and is not
- considered part of the MDN protocol specification. If the example
- conflicts with the protocol definition above, the example is wrong.
-
- Likewise, the use of *-type subfield names or extension fields in
- this example is not to be construed as a definition for those type
- names or extension fields.
-
-9.1 This is an MDN issued after a message has been displayed to the user
- of an Internet Mail user agent.
-
- Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400
- From: Joe Recipient <address@hidden>
- Message-Id: <address@hidden>
- Subject: Disposition notification
- To: Jane Sender <address@hidden>
- MIME-Version: 1.0
- Content-Type: multipart/report; report-type=disposition-notification;
- boundary="RAA14128.773615765/mega.edu"
-
- --RAA14128.773615765/mega.edu
-
- The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe
- Recipient <address@hidden> with subject "First draft of
- report" has been displayed. This is no guarantee that the message
- has been read or understood.
-
- --RAA14128.773615765/mega.edu
- content-type: message/disposition-notification
-
- Reporting-UA: joes-pc.cs.mega.edu; Foomail 97.1
- Original-Recipient: rfc822;address@hidden
- Final-Recipient: rfc822;address@hidden
- Original-Message-ID: <address@hidden>
- Disposition: manual-action/MDN-sent-manually; displayed
-
- --RAA14128.773615765/mega.edu
- content-type: message/rfc822
-
- [original message goes here]
-
- --RAA14128.773615765/mega.edu--
-
-
-
-
-
-
-
-Fajman Standards Track [Page 24]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
-10. IANA Registration Forms
-
- The forms below are for use when registering a new parameter name for
- the Disposition-Notification-Options header, a new disposition
- modifier name, or a new MDN extension field. Each piece of
- information required 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 that
- includes the necessary information. IANA MAY reject registrations
- because of incomplete registration forms, imprecise specifications,
- or inappropriate names.
-
- To register, complete the applicable form below and send it via
- electronic mail to <address@hidden>.
-
-10.1 IANA registration form for Disposition-Notification-Options header
- parameter names
-
- A registration for a Disposition-Notification-Options header
- parameter name MUST include the following information:
-
- (a) The proposed parameter name.
-
- (b) The syntax for parameter values, specified using BNF, ABNF,
- regular expressions, or other non-ambiguous language.
-
- (c) If parameter values 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 Disposition-
- Notification-Options header.
-
- (d) A reference to a standards track RFC or experimental RFC approved
- by the IESG that describes the semantics of the parameter values.
-
-10.2 IANA registration form for disposition modifer names
-
- A registration for a disposition-modifier name MUST include the
- following information:
-
- (a) The proposed disposition-modifier name.
-
- (b) A reference to a standards track RFC or experimental RFC approved
- by the IESG that describes the semantics of the disposition modifier.
-
-10.3 IANA registration form for MDN extension field names
-
- A registration for an MDN extension field name MUST include the
- following information:
-
-
-
-Fajman Standards Track [Page 25]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- (a) The proposed extension field name.
-
- (b) The syntax for extension values, specified using BNF, ABNF,
- regular expressions, or other non-ambiguous language.
-
- (c) If extension field values 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 Disposition-
- Notification-Options header.
-
- (d) A reference to a standards track RFC or experimental RFC approved
- by the IESG that describes the semantics of the extension field.
-
-11. Acknowledgments
-
- This document is based on the Delivery Status Notifications document,
- RFC 1894 [9], by Keith Moore and Greg Vaudreuil. Contributions were
- made by members of the IETF Receipt Working Group, including Harald
- Alverstrand, Ian Bell, Urs Eppenberger, Claus Andri Faerber, Ned
- Freed, Jim Galvin, Carl Hage, Mike Lake, Keith Moore, Paul Overell,
- Pete Resnick, Chuck Shih.
-
-12. References
-
- [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
- August 1982.
-
- [2] Crocker, D., "Standard for the Format of ARPA Internet Text
- Messages", STD 11, RFC 822, August 1982.
-
- [3] Braden, R. (ed.), "Requirements for Internet Hosts -
- Application and Support", STD 3, RFC 1123, October 1989.
-
- [4] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message
- Bodies", RFC 2045, November 1996.
-
- [5] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part Two: Media Types", RFC 2046, November
- 1996.
-
- [6] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part
- Three: Message Header Extensions for Non-Ascii Text", RFC
- 2047, November 1996.
-
- [7] Vaudreuil, G., "The Multipart/Report Content Type for the
- Reporting of Mail System Administrative Messages", RFC 1892,
- January 1996.
-
-
-
-Fajman Standards Track [Page 26]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
- [8] Moore, K., "SMTP Service Extension for Delivery Status
- Notifications", RFC 1891, January 1996.
-
- [9] Moore, K., and G. Vaudreuil, "An Extensible Format for
- Delivery Status Notifications, RFC 1894, January 1996.
-
- [10] Bradner, S., "Key Words for Use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-13. Author's Address
-
- Roger Fajman
- National Institutes of Health
- Building 12A, Room 3063
- 12 South Drive MSC 5659
- Bethesda, Maryland 20892-5659
- USA
-
- EMail: address@hidden
- Phone: +1 301 402 4265
- Fax: +1 301 480 6241
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Fajman Standards Track [Page 27]
-
-RFC 2298 Message Disposition Notifications March 1998
-
-
-14. Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Fajman Standards Track [Page 28]
-
diff --git a/doc/rfc/rfc2342.txt b/doc/rfc/rfc2342.txt
deleted file mode 100644
index 0926646..0000000
--- a/doc/rfc/rfc2342.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Gahrns
-Request for Comments: 2342 Microsoft
-Category: Standards Track C. Newman
- Innosoft
- May 1998
-
-
- IMAP4 Namespace
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
-1. Abstract
-
- IMAP4 [RFC-2060] does not define a default server namespace. As a
- result, two common namespace models have evolved:
-
- The "Personal Mailbox" model, in which the default namespace that is
- presented consists of only the user's personal mailboxes. To access
- shared mailboxes, the user must use an escape mechanism to reach
- another namespace.
-
- The "Complete Hierarchy" model, in which the default namespace that
- is presented includes the user's personal mailboxes along with any
- other mailboxes they have access to.
-
- These two models, create difficulties for certain client operations.
- This document defines a NAMESPACE command that allows a client to
- discover the prefixes of namespaces used by a server for personal
- mailboxes, other users' mailboxes, and shared mailboxes. This allows
- a client to avoid much of the manual user configuration that is now
- necessary when mixing and matching IMAP4 clients and servers.
-
-2. Conventions used in this document
-
- In examples, "C:" and "S:" indicate lines sent by the client and
- server respectively. If such lines are wrapped without a new "C:" or
- "S:" label, then the wrapping is for editorial clarity and is not
- part of the command.
-
-
-
-Gahrns & Newman Standards Track [Page 1]
-
-RFC 2342 IMAP4 Namespace May 1998
-
-
- Personal Namespace: A namespace that the server considers within the
- personal scope of the authenticated user on a particular connection.
- Typically, only the authenticated user has access to mailboxes in
- their Personal Namespace. It is the part of the namespace that
- belongs to the user that is allocated for mailboxes. If an INBOX
- exists for a user, it MUST appear within the user's personal
- namespace. In the typical case, there SHOULD be only one Personal
- Namespace on a server.
-
- Other Users' Namespace: A namespace that consists of mailboxes from
- the Personal Namespaces of other users. To access mailboxes in the
- Other Users' Namespace, the currently authenticated user MUST be
- explicitly granted access rights. For example, it is common for a
- manager to grant to their secretary access rights to their mailbox.
- In the typical case, there SHOULD be only one Other Users' Namespace
- on a server.
-
- Shared Namespace: A namespace that consists of mailboxes that are
- intended to be shared amongst users and do not exist within a user's
- Personal Namespace.
-
- The namespaces a server uses MAY differ on a per-user basis.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC-2119].
-
-3. Introduction and Overview
-
- Clients often attempt to create mailboxes for such purposes as
- maintaining a record of sent messages (e.g. "Sent Mail") or
- temporarily saving messages being composed (e.g. "Drafts"). For
- these clients to inter-operate correctly with the variety of IMAP4
- servers available, the user must enter the prefix of the Personal
- Namespace used by the server. Using the NAMESPACE command, a client
- is able to automatically discover this prefix without manual user
- configuration.
-
- In addition, users are often required to manually enter the prefixes
- of various namespaces in order to view the mailboxes located there.
- For example, they might be required to enter the prefix of #shared to
- view the shared mailboxes namespace. The NAMESPACE command allows a
- client to automatically discover the namespaces that are available on
- a server. This allows a client to present the available namespaces to
- the user in what ever manner it deems appropriate. For example, a
-
-
-
-
-
-
-Gahrns & Newman Standards Track [Page 2]
-
-RFC 2342 IMAP4 Namespace May 1998
-
-
- client could choose to initially display only personal mailboxes, or
- it may choose to display the complete list of mailboxes available,
- and initially position the user at the root of their Personal
- Namespace.
-
- A server MAY choose to make available to the NAMESPACE command only a
- subset of the complete set of namespaces the server supports. To
- provide the ability to access these namespaces, a client SHOULD allow
- the user the ability to manually enter a namespace prefix.
-
-4. Requirements
-
- IMAP4 servers that support this extension MUST list the keyword
- NAMESPACE in their CAPABILITY response.
-
- The NAMESPACE command is valid in the Authenticated and Selected
- state.
-
-5. NAMESPACE Command
-
- Arguments: none
-
- Response: an untagged NAMESPACE response that contains the prefix
- and hierarchy delimiter to the server's Personal
- Namespace(s), Other Users' Namespace(s), and Shared
- Namespace(s) that the server wishes to expose. The
- response will contain a NIL for any namespace class
- that is not available. Namespace_Response_Extensions
- MAY be included in the response.
- Namespace_Response_Extensions which are not on the IETF
- standards track, MUST be prefixed with an "X-".
-
- Result: OK - Command completed
- NO - Error: Can't complete command
- BAD - argument invalid
-
- Example 5.1:
- ===========
-
- < A server that supports a single personal namespace. No leading
- prefix is used on personal mailboxes and "/" is the hierarchy
- delimiter.>
-
- C: A001 NAMESPACE
- S: * NAMESPACE (("" "/")) NIL NIL
- S: A001 OK NAMESPACE command completed
-
-
-
-
-
-Gahrns & Newman Standards Track [Page 3]
-
-RFC 2342 IMAP4 Namespace May 1998
-
-
- Example 5.2:
- ===========
-
- < A user logged on anonymously to a server. No personal mailboxes
- are associated with the anonymous user and the user does not have
- access to the Other Users' Namespace. No prefix is required to
- access shared mailboxes and the hierarchy delimiter is "." >
-
- C: A001 NAMESPACE
- S: * NAMESPACE NIL NIL (("" "."))
- S: A001 OK NAMESPACE command completed
-
- Example 5.3:
- ===========
-
- < A server that contains a Personal Namespace and a single Shared
- Namespace. >
-
- C: A001 NAMESPACE
- S: * NAMESPACE (("" "/")) NIL (("Public Folders/" "/"))
- S: A001 OK NAMESPACE command completed
-
- Example 5.4:
- ===========
-
- < A server that contains a Personal Namespace, Other Users'
- Namespace and multiple Shared Namespaces. Note that the hierarchy
- delimiter used within each namespace can be different. >
-
- C: A001 NAMESPACE
- S: * NAMESPACE (("" "/")) (("~" "/")) (("#shared/" "/")
- ("#public/" "/")("#ftp/" "/")("#news." "."))
- S: A001 OK NAMESPACE command completed
-
- The prefix string allows a client to do things such as automatically
- creating personal mailboxes or LISTing all available mailboxes within
- a namespace.
-
- Example 5.5:
- ===========
-
- < A server that supports only the Personal Namespace, with a
- leading prefix of INBOX to personal mailboxes and a hierarchy
- delimiter of ".">
-
- C: A001 NAMESPACE
- S: * NAMESPACE (("INBOX." ".")) NIL NIL
- S: A001 OK NAMESPACE command completed
-
-
-
-Gahrns & Newman Standards Track [Page 4]
-
-RFC 2342 IMAP4 Namespace May 1998
-
-
- < Automatically create a mailbox to store sent items.>
-
- C: A002 CREATE "INBOX.Sent Mail"
- S: A002 OK CREATE command completed
-
- Although typically a server will support only a single Personal
- Namespace, and a single Other User's Namespace, circumstances exist
- where there MAY be multiples of these, and a client MUST be prepared
- for them. If a client is configured such that it is required to
- create a certain mailbox, there can be circumstances where it is
- unclear which Personal Namespaces it should create the mailbox in.
- In these situations a client SHOULD let the user select which
- namespaces to create the mailbox in.
-
- Example 5.6:
- ===========
-
- < In this example, a server supports 2 Personal Namespaces. In
- addition to the regular Personal Namespace, the user has an
- additional personal namespace to allow access to mailboxes in an
- MH format mailstore. >
-
- < The client is configured to save a copy of all mail sent by the
- user into a mailbox called 'Sent Mail'. Furthermore, after a
- message is deleted from a mailbox, the client is configured to
- move that message to a mailbox called 'Deleted Items'.>
-
- < Note that this example demonstrates how some extension flags can
- be passed to further describe the #mh namespace. >
-
- C: A001 NAMESPACE
- S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM" ("FLAG1" "FLAG2")))
- NIL NIL
- S: A001 OK NAMESPACE command completed
-
- < It is desired to keep only one copy of sent mail. It is unclear
- which Personal Namespace the client should use to create the 'Sent
- Mail' mailbox. The user is prompted to select a namespace and
- only one 'Sent Mail' mailbox is created. >
-
- C: A002 CREATE "Sent Mail"
- S: A002 OK CREATE command completed
-
- < The client is designed so that it keeps two 'Deleted Items'
- mailboxes, one for each namespace. >
-
- C: A003 CREATE "Delete Items"
- S: A003 OK CREATE command completed
-
-
-
-Gahrns & Newman Standards Track [Page 5]
-
-RFC 2342 IMAP4 Namespace May 1998
-
-
- C: A004 CREATE "#mh/Deleted Items"
- S: A004 OK CREATE command completed
-
- The next level of hierarchy following the Other Users' Namespace
- prefix SHOULD consist of <username>, where <username> is a user name
- as per the IMAP4 LOGIN or AUTHENTICATE command.
-
- A client can construct a LIST command by appending a "%" to the Other
- Users' Namespace prefix to discover the Personal Namespaces of other
- users that are available to the currently authenticated user.
-
- In response to such a LIST command, a server SHOULD NOT return user
- names that have not granted access to their personal mailboxes to the
- user in question.
-
- A server MAY return a LIST response containing only the names of
- users that have explicitly granted access to the user in question.
-
- Alternatively, a server MAY return NO to such a LIST command,
- requiring that a user name be included with the Other Users'
- Namespace prefix before listing any other user's mailboxes.
-
- Example 5.7:
- ===========
-
- < A server that supports providing a list of other user's
- mailboxes that are accessible to the currently logged on user. >
-
- C: A001 NAMESPACE
- S: * NAMESPACE (("" "/")) (("Other Users/" "/")) NIL
- S: A001 OK NAMESPACE command completed
-
- C: A002 LIST "" "Other Users/%"
- S: * LIST () "/" "Other Users/Mike"
- S: * LIST () "/" "Other Users/Karen"
- S: * LIST () "/" "Other Users/Matthew"
- S: * LIST () "/" "Other Users/Tesa"
- S: A002 OK LIST command completed
-
- Example 5.8:
- ===========
-
- < A server that does not support providing a list of other user's
- mailboxes that are accessible to the currently logged on user.
- The mailboxes are listable if the client includes the name of the
- other user with the Other Users' Namespace prefix. >
-
-
-
-
-
-Gahrns & Newman Standards Track [Page 6]
-
-RFC 2342 IMAP4 Namespace May 1998
-
-
- C: A001 NAMESPACE
- S: * NAMESPACE (("" "/")) (("#Users/" "/")) NIL
- S: A001 OK NAMESPACE command completed
-
- < In this example, the currently logged on user has access to the
- Personal Namespace of user Mike, but the server chose to suppress
- this information in the LIST response. However, by appending the
- user name Mike (received through user input) to the Other Users'
- Namespace prefix, the client is able to get a listing of the
- personal mailboxes of user Mike. >
-
- C: A002 LIST "" "#Users/%"
- S: A002 NO The requested item could not be found.
-
- C: A003 LIST "" "#Users/Mike/%"
- S: * LIST () "/" "#Users/Mike/INBOX"
- S: * LIST () "/" "#Users/Mike/Foo"
- S: A003 OK LIST command completed.
-
- A prefix string might not contain a hierarchy delimiter, because
- in some cases it is not needed as part of the prefix.
-
- Example 5.9:
- ===========
-
- < A server that allows access to the Other Users' Namespace by
- prefixing the others' mailboxes with a '~' followed by <username>,
- where <username> is a user name as per the IMAP4 LOGIN or
- AUTHENTICATE command.>
-
- C: A001 NAMESPACE
- S: * NAMESPACE (("" "/")) (("~" "/")) NIL
- S: A001 OK NAMESPACE command completed
-
- < List the mailboxes for user mark >
-
- C: A002 LIST "" "~mark/%"
- S: * LIST () "/" "~mark/INBOX"
- S: * LIST () "/" "~mark/foo"
- S: A002 OK LIST command completed
-
- Historical convention has been to start all namespaces with the "#"
- character. Namespaces that include the "#" character are not IMAP
- URL [IMAP-URL] friendly requiring the "#" character to be represented
- as %23 when within URLs. As such, server implementers MAY instead
- consider using namespace prefixes that do not contain the "#"
- character.
-
-
-
-
-Gahrns & Newman Standards Track [Page 7]
-
-RFC 2342 IMAP4 Namespace May 1998
-
-
-6. Formal Syntax
-
- The following syntax specification uses the augmented Backus-Naur
- Form (BNF) as described in [ABNF].
-
- atom = <atom>
- ; <atom> as defined in [RFC-2060]
-
- Namespace = nil / "(" 1*( "(" string SP (<"> QUOTED_CHAR <"> /
- nil) *(Namespace_Response_Extension) ")" ) ")"
-
- Namespace_Command = "NAMESPACE"
-
- Namespace_Response_Extension = SP string SP "(" string *(SP string)
- ")"
-
- Namespace_Response = "*" SP "NAMESPACE" SP Namespace SP Namespace SP
- Namespace
-
- ; The first Namespace is the Personal Namespace(s)
- ; The second Namespace is the Other Users' Namespace(s)
- ; The third Namespace is the Shared Namespace(s)
-
- nil = <nil>
- ; <nil> as defined in [RFC-2060]
-
- QUOTED_CHAR = <QUOTED_CHAR>
- ; <QUOTED_CHAR> as defined in [RFC-2060]
-
- string = <string>
- ; <string> as defined in [RFC-2060]
- ; Note that the namespace prefix is to a mailbox and following
- ; IMAP4 convention, any international string in the NAMESPACE
- ; response MUST be of modified UTF-7 format as described in
- ; [RFC-2060].
-
-7. Security Considerations
-
- In response to a LIST command containing an argument of the Other
- Users' Namespace prefix, a server SHOULD NOT list users that have not
- granted list access to their personal mailboxes to the currently
- authenticated user. Providing such a list, could compromise security
- by potentially disclosing confidential information of who is located
- on the server, or providing a starting point of a list of user
- accounts to attack.
-
-
-
-
-
-
-Gahrns & Newman Standards Track [Page 8]
-
-RFC 2342 IMAP4 Namespace May 1998
-
-
-8. References
-
- [RFC-2060], Crispin, M., "Internet Message Access Protocol Version
- 4rev1", RFC 2060, December 1996.
-
- [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [ABNF] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
-
-9. Acknowledgments
-
- Many people have participated in the discussion of IMAP namespaces on
- the IMAP mailing list. In particular, the authors would like to
- thank Mark Crispin for many of the concepts relating to the Personal
- Namespace and accessing the Personal Namespace of other users, Steve
- Hole for summarizing the two namespace models, John Myers and Jack De
- Winter for their work in a preceding effort trying to define a
- standardized personal namespace, and Larry Osterman for his review
- and collaboration on this document.
-
-11. Authors' Addresses
-
- Mike Gahrns
- Microsoft
- One Microsoft Way
- Redmond, WA, 98072, USA
-
- Phone: (425) 936-9833
- EMail: address@hidden
-
-
- Chris Newman
- Innosoft International, Inc.
- 1050 East Garvey Ave. South
- West Covina, CA, 91790, USA
-
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-
-Gahrns & Newman Standards Track [Page 9]
-
-RFC 2342 IMAP4 Namespace May 1998
-
-
-12. Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gahrns & Newman Standards Track [Page 10]
-
diff --git a/doc/rfc/rfc2368.txt b/doc/rfc/rfc2368.txt
deleted file mode 100644
index abfd1b0..0000000
--- a/doc/rfc/rfc2368.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group P. Hoffman
-Request for Comments: 2368 Internet Mail Consortium
-Updates: 1738, 1808 L. Masinter
-Category: Standards Track Xerox Corporation
- J. Zawinski
- Netscape Communications
- July 1998
-
-
- The mailto URL scheme
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
-Abstract
-
- This document defines the format of Uniform Resource Locators (URL)
- for designating electronic mail addresses. It is one of a suite of
- documents which replace RFC 1738, 'Uniform Resource Locators', and
- RFC 1808, 'Relative Uniform Resource Locators'. The syntax of
- 'mailto' URLs from RFC 1738 is extended to allow creation of more RFC
- 822 messages by allowing the URL to express additional header and
- body fields.
-
-1. Introduction
-
- The mailto URL scheme is used to designate the Internet mailing
- address of an individual or service. In its simplest form, a mailto
- URL contains an Internet mail address.
-
- For greater functionality, because interaction with some resources
- may require message headers or message bodies to be specified as well
- as the mail address, the mailto URL scheme is extended to allow
- setting mail header fields and the message body.
-
-2. Syntax of a mailto URL
-
- Following the syntax conventions of RFC 1738 [RFC1738], a "mailto"
- URL has the form:
-
-
-
-Hoffman, et. al. Standards Track [Page 1]
-
-RFC 2368 The mailto URL scheme July 1998
-
-
- mailtoURL = "mailto:"; [ to ] [ headers ]
- to = #mailbox
- headers = "?" header *( "&" header )
- header = hname "=" hvalue
- hname = *urlc
- hvalue = *urlc
-
- "#mailbox" is as specified in RFC 822 [RFC822]. This means that it
- consists of zero or more comma-separated mail addresses, possibly
- including "phrase" and "comment" components. Note that all URL
- reserved characters in "to" must be encoded: in particular,
- parentheses, commas, and the percent sign ("%"), which commonly occur
- in the "mailbox" syntax.
-
- "hname" and "hvalue" are encodings of an RFC 822 header name and
- value, respectively. As with "to", all URL reserved characters must
- be encoded.
-
- The special hname "body" indicates that the associated hvalue is the
- body of the message. The "body" hname should contain the content for
- the first text/plain body part of the message. The mailto URL is
- primarily intended for generation of short text messages that are
- actually the content of automatic processing (such as "subscribe"
- messages for mailing lists), not general MIME bodies.
-
- Within mailto URLs, the characters "?", "=", "&" are reserved.
-
- Because the "&" (ampersand) character is reserved in HTML, any mailto
- URL which contains an ampersand must be spelled differently in HTML
- than in other contexts. A mailto URL which appears in an HTML
- document must use "&" instead of "&".
-
- Also note that it is legal to specify both "to" and an "hname" whose
- value is "to". That is,
-
- mailto:addr1%2C%20addr2
-
- is equivalent to
-
- mailto:?to=addr1%2C%20addr2
-
- is equivalent to
-
- mailto:addr1?to=addr2
-
- 8-bit characters in mailto URLs are forbidden. MIME encoded words (as
- defined in [RFC2047]) are permitted in header values, but not for any
- part of a "body" hname.
-
-
-
-Hoffman, et. al. Standards Track [Page 2]
-
-RFC 2368 The mailto URL scheme July 1998
-
-
-3. Semantics and operations
-
- A mailto URL designates an "internet resource", which is the mailbox
- specified in the address. When additional headers are supplied, the
- resource designated is the same address, but with an additional
- profile for accessing the resource. While there are Internet
- resources that can only be accessed via electronic mail, the mailto
- URL is not intended as a way of retrieving such objects
- automatically.
-
- In current practice, resolving URLs such as those in the "http"
- scheme causes an immediate interaction between client software and a
- host running an interactive server. The "mailto" URL has unusual
- semantics because resolving such a URL does not cause an immediate
- interaction. Instead, the client creates a message to the designated
- address with the various header fields set as default. The user can
- edit the message, send this message unedited, or choose not to send
- the message. The operation of how any URL scheme is resolved is not
- mandated by the URL specifications.
-
-4. Unsafe headers
-
- The user agent interpreting a mailto URL SHOULD choose not to create
- a message if any of the headers are considered dangerous; it may also
- choose to create a message with only a subset of the headers given in
- the URL. Only the Subject, Keywords, and Body headers are believed
- to be both safe and useful.
-
- The creator of a mailto URL cannot expect the resolver of a URL to
- understand more than the "subject" and "body" headers. Clients that
- resolve mailto URLs into mail messages should be able to correctly
- create RFC 822-compliant mail messages using the "subject" and "body"
- headers.
-
-5. Encoding
-
- RFC 1738 requires that many characters in URLs be encoded. This
- affects the mailto scheme for some common characters that might
- appear in addresses, headers or message contents. One such character
- is space (" ", ASCII hex 20). Note the examples above that use "%20"
- for space in the message body. Also note that line breaks in the
- body of a message MUST be encoded with "%0D%0A".
-
- People creating mailto URLs must be careful to encode any reserved
- characters that are used in the URLs so that properly-written URL
- interpreters can read them. Also, client software that reads URLs
- must be careful to decode strings before creating the mail message so
-
-
-
-
-Hoffman, et. al. Standards Track [Page 3]
-
-RFC 2368 The mailto URL scheme July 1998
-
-
- that the mail messages appear in a form that the recipient will
- understand. These strings should be decoded before showing the user
- the message.
-
- The mailto URL scheme is limited in that it does not provide for
- substitution of variables. Thus, a message body that must include a
- user's email address can not be encoded using the mailto URL. This
- limitation also prevents mailto URLs that are signed with public keys
- and other such variable information.
-
-6. Examples
-
- URLs for an ordinary individual mailing address:
-
- <mailto:address@hidden>
-
- A URL for a mail response system that requires the name of the file
- in the subject:
-
- <mailto:address@hidden>
-
- A mail response system that requires a "send" request in the body:
-
- <mailto:address@hidden>
-
- A similar URL could have two lines with different "send" requests (in
- this case, "send current-issue" and, on the next line, "send index".)
-
- <mailto:address@hidden
- issue%0D%0Asend%20index>
-
- An interesting use of your mailto URL is when browsing archives of
- messages. Each browsed message might contain a mailto URL like:
-
- <mailto:address@hidden
- address@hidden>
-
- A request to subscribe to a mailing list:
-
- <mailto:address@hidden>
-
- A URL for a single user which includes a CC of another user:
-
- <mailto:address@hidden@example.com&body=hello>
-
- Another way of expressing the same thing:
-
- <mailto:address@hidden&address@hidden&body=hello>
-
-
-
-Hoffman, et. al. Standards Track [Page 4]
-
-RFC 2368 The mailto URL scheme July 1998
-
-
- Note the use of the "&" reserved character, above. The following
- example, by using "?" twice, is incorrect:
-
- <mailto:address@hidden@example.com?body=hello> ; WRONG!
-
- According to RFC 822, the characters "?", "&", and even "%" may occur
- in addr-specs. The fact that they are reserved characters in this URL
- scheme is not a problem: those characters may appear in mailto URLs,
- they just may not appear in unencoded form. The standard URL encoding
- mechanisms ("%" followed by a two-digit hex number) must be used in
- certain cases.
-
- To indicate the address "address@hidden" one would do:
-
- <mailto:address@hidden>
-
- To indicate the address "address@hidden", and include
- another header, one would do:
-
- <mailto:address@hidden>
-
- As described above, the "&" (ampersand) character is reserved in HTML
- and must be replacded with "&". Thus, a complex URL that has
- internal ampersands might look like:
-
- Click
- <a href="mailto:address@hidden&address@hidden&body=hello";>
- mailto:address@hidden&address@hidden&body=hello</a> to
- send a greeting message to <i>Joe and Bob</i>.
-
-7. Security Considerations
-
- The mailto scheme can be used to send a message from one user to
- another, and thus can introduce many security concerns. Mail messages
- can be logged at the originating site, the recipient site, and
- intermediary sites along the delivery path. If the messages are not
- encoded, they can also be read at any of those sites.
-
- A mailto URL gives a template for a message that can be sent by mail
- client software. The contents of that template may be opaque or
- difficult to read by the user at the time of specifying the URL.
- Thus, a mail client should never send a message based on a mailto URL
- without first showing the user the full message that will be sent
- (including all headers that were specified by the mailto URL), fully
- decoded, and asking the user for approval to send the message as
- electronic mail. The mail client should also make it clear that the
- user is about to send an electronic mail message, since the user may
- not be aware that this is the result of a mailto URL.
-
-
-
-Hoffman, et. al. Standards Track [Page 5]
-
-RFC 2368 The mailto URL scheme July 1998
-
-
- A mail client should never send anything without complete disclosure
- to the user of what is will be sent; it should disclose not only the
- message destination, but also any headers. Unrecognized headers, or
- headers with values inconsistent with those the mail client would
- normally send should be especially suspect. MIME headers (MIME-
- Version, Content-*) are most likely inappropriate, as are those
- relating to routing (From, Bcc, Apparently-To, etc.)
-
- Note that some headers are inherently unsafe to include in a message
- generated from a URL. For example, headers such as "From:", "Bcc:",
- and so on, should never be interpreted from a URL. In general, the
- fewer headers interpreted from the URL, the less likely it is that a
- sending agent will create an unsafe message.
-
- Examples of problems with sending unapproved mail include:
-
- * mail that breaks laws upon delivery, such as making illegal
- threats;
-
- * mail that identifies the sender as someone interested in breaking
- laws;
-
- * mail that identifies the sender to an unwanted third party;
-
- * mail that causes a financial charge to be incurred on the sender;
-
- * mail that causes an action on the recipient machine that causes
- damage that might be attributed to the sender.
-
- Programs that interpret mailto URLs should ensure that the SMTP
- "From" address is set and correct.
-
-8. IANA Considerations
-
- This document changes the definition of the mailto: URI scheme; any
- registry of URI schemes should refer to this document rather than its
- predecessor, RFC 1738.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman, et. al. Standards Track [Page 6]
-
-RFC 2368 The mailto URL scheme July 1998
-
-
-9. References
-
- [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
- Messages", STD 11, RFC 822, August 1982.
-
- [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, Editors,
- "Uniform Resource Locators (URL)", RFC 1738, December 1994.
-
- [RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC
- 1808, June 1995.
-
- [RFC2047] Moore, K., "MIME Part Three: Message Header Extensions for
- Non-ASCII Text", RFC 2047, November 1996.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman, et. al. Standards Track [Page 7]
-
-RFC 2368 The mailto URL scheme July 1998
-
-
-A. Change from RFC 1738
-
- RFC 1738 defined only a simple 'mailto' with no headers, just an
- addr-spec (not a full mailbox.) However, required usage and
- implementation has led to the development of an extended syntax that
- included more header fields.
-
-B. Acknowledgments
-
- This document was derived from RFC 1738 and RFC 1808 [RFC1808]; the
- acknowledgments from those specifications still applies.
-
- The following people contributed to this memo or had and discussed
- similar ideas for mailto.
-
- Harald Alvestrand
- Bryan Costales
- Steve Dorner
- Al Gilman
- Mark Joseph
- Laurence Lundblade
- Keith Moore
- Jacob Palme
- Michael Patton
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman, et. al. Standards Track [Page 8]
-
-RFC 2368 The mailto URL scheme July 1998
-
-
-C. Author Contact Information
-
- Paul E. Hoffman
- Internet Mail Consortium
- 127 Segre Place
- Santa Cruz, CA 95060 USA
-
- EMail: address@hidden
-
-
- Larry Masinter
- Xerox Corporation
- 3333 Coyote Hill Road
- Palo Alto, CA 94304 USA
-
- EMail: address@hidden
-
-
- Jamie Zawinski
- Netscape Communications Corp.
- 501 East Middlefield Road
- Mountain View, CA 94043 USA
-
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman, et. al. Standards Track [Page 9]
-
-RFC 2368 The mailto URL scheme July 1998
-
-
-D. Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman, et. al. Standards Track [Page 10]
-
diff --git a/doc/rfc/rfc2384.txt b/doc/rfc/rfc2384.txt
deleted file mode 100644
index 11963dd..0000000
--- a/doc/rfc/rfc2384.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Gellens
-Request for Comments: 2384 QUALCOMM, Incorporated
-Category: Standards Track August 1998
-
-
- POP URL Scheme
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
-1. Introduction
-
- [POP3] is a widely-deployed mail access protocol. Many programs
- access POP3 message stores, and thus need POP3 configuration
- information. Since there are multiple configuration elements which
- are required in order to access a mailbox, a single string
- representation is convenient.
-
- A POP3 mailbox (like an [IMAP4] mailbox) is a network resource, and
- URLs are a widely-supported generalized representation of network
- resources.
-
- A means of specifying a POP3 mailbox as a URL will likely be useful
- in many programs and protocols. [ACAP] is one case where a string
- encapsulation of elements required to access network services is
- needed. For example, an [IMAP4] message store is usually specified
- in ACAP datasets as an [IMAP-URL].
-
- This memo defines a URL scheme for referencing a POP mailbox.
-
-2. Conventions Used in this Document
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
- in this document are to be interpreted as defined in "Key words for
- use in RFCs to Indicate Requirement Levels" [KEYWORDS].
-
-
-
-
-
-
-
-Gellens Standards Track [Page 1]
-
-RFC 2384 POP URL Scheme August 1998
-
-
-3. POP Scheme
-
- The POP URL scheme designates a POP server, and optionally a port
- number, authentication mechanism, authentication ID, and/or
- authorization ID.
-
- The POP URL follows the common Internet scheme syntax as defined in
- RFC 1738 [BASIC-URL] except that clear text passwords are not
- permitted. If :<port> is omitted, the port defaults to 110.
-
- The POP URL is described using [ABNF] in Section 8.
-
- A POP URL is of the general form:
-
- pop://<user>;auth=<auth>@<host>:<port>
-
- Where <user>, <host>, and <port> are as defined in RFC 1738, and some
- or all of the elements, except "pop://" and <host>, may be omitted.
-
-4. POP User Name and Authentication Mechanism
-
- An authorization (which mailbox to access) and authentication (whose
- password to check against) identity (referred to as "user name" for
- simplicity) and/or authentication mechanism name may be supplied.
- These are used in a "USER", "APOP", "AUTH" [POP-AUTH], or extension
- command after making the connection to the POP server. If the URL
- doesn't supply an authentication identifier, the program interpreting
- the POP URL SHOULD request one from the user.
-
- An authentication mechanism can be expressed by adding ";AUTH=<enc-
- auth-type>" to the end of the user name. If the authentication
- mechanism name is not preceded by a "+", it is a SASL POP [SASL]
- mechanism. If it is preceded by a "+", it is either "APOP" or an
- extension mechanism.
-
- When an <enc-auth-type> is specified, the client SHOULD request
- appropriate credentials from that mechanism and use the "AUTH",
- "APOP", or extension command instead of the "USER" command. If no
- user name is specified, one SHOULD be obtained from the mechanism or
- requested from the user as appropriate.
-
- The string ";AUTH=*" indicates that the client SHOULD select an
- appropriate authentication mechanism. It MAY use any mechanism
- supported by the POP server.
-
- If an <enc-auth-type> other than ";AUTH=*" is specified, the client
- SHOULD NOT use a different mechanism without explicit user
- permission.
-
-
-
-Gellens Standards Track [Page 2]
-
-RFC 2384 POP URL Scheme August 1998
-
-
- If a user name is included with no authentication mechanism, then
- ";AUTH=*" is assumed.
-
- Since URLs can easily come from untrusted sources, care must be taken
- when resolving a URL which requires or requests any sort of
- authentication. If authentication credentials are supplied to the
- wrong server, it may compromise the security of the user's account.
- The program resolving the URL should make sure it meets at least one
- of the following criteria in this case:
-
- (1) The URL comes from a trusted source, such as a referral server
- which the client has validated and trusts according to site policy.
- Note that user entry of the URL may or may not count as a trusted
- source, depending on the experience level of the user and site
- policy.
-
- (2) Explicit local site policy permits the client to connect to the
- server in the URL. For example, if the client knows the site domain
- name, site policy may dictate that any hostname ending in that domain
- is trusted.
-
- (3) The user confirms that connecting to that domain name with the
- specified credentials and/or mechanism is permitted.
-
- (4) A mechanism is used which validates the server before passing
- potentially compromising client credentials.
-
- (5) An authentication mechanism is used which will not reveal
- information to the server which could be used to compromise future
- connections.
-
- A URL containing ";AUTH=*" should be treated with extra care since it
- might fall back on a weaker security mechanism. Finally, clients are
- discouraged from using a plain text password as a fallback with
- ";AUTH=*" unless the connection has strong encryption (e.g., a key
- length of greater than 56 bits).
-
- Note that if unsafe or reserved characters such as " " or ";" are
- present in the user name or authentication mechanism, they MUST be
- encoded as described in RFC 1738 [BASIC-URL].
-
-5. Relative POP URLs
-
- Relative POP URLs are not permitted.
-
-
-
-
-
-
-
-Gellens Standards Track [Page 3]
-
-RFC 2384 POP URL Scheme August 1998
-
-
-6. Multinational Considerations
-
- Since 8-bit characters are not permitted in URLs, [UTF8] characters
- are encoded as required by the URL specification [BASIC-URL].
-
-7. Examples
-
- The following examples demonstrate how a POP client program might
- translate various POP URLs into a series of POP commands. Commands
- sent from the client to the server are prefixed with "C:", and
- responses sent from the server to the client are prefixed with "S:".
-
- The URL:
-
- <pop://address@hidden>
-
- Results in the following client commands:
-
- <request password from user>
- <connect to mailsrv.qualcomm.com, port 110>
- S: +OK POP3 server ready <address@hidden>
- C: USER rg
- S: +OK
- C: PASS secret
- S: +OK rg's mailbox has 2 messages (320 octets)
-
- The URL:
-
- <pop://rg;address@hidden:8110>
-
- Results in the following client commands:
-
- <client requests password from user>
- <connect to mail.eudora.com, port 8110>
- S: +OK POP3 server ready <address@hidden>
- C: APOP rg c4c9334bac560ecc979e58001b3e22fb
- S: +OK mailbox has 1 message (369 octets)
-
- The URL:
-
- <pop://baz;address@hidden>
-
- Results in the following client commands:
-
- <connect to foo.bar, port 110>
-
- S: +OK POP3 server ready <address@hidden>
- C: AUTH SCRAM-MD5 AGNocmlzADx0NG40UGFiOUhCMEFtL1FMWEI3MmVnQGVsZW
-
-
-
-Gellens Standards Track [Page 4]
-
-RFC 2384 POP URL Scheme August 1998
-
-
- Fub3IuaW5ub3NvZnQuY29tPg==
- S: + dGVzdHNhbHQBAAAAaW1hcEBlbGVhbm9yLmlubm9zb2Z0LmNvbQBq
- aGNOWmxSdVBiemlGcCt2TFYrTkN3
- C: AQAAAMg9jU8CeB4KOfk7sUhSQPs=
- S: + U0odqYw3B7XIIW0oSz65OQ==
- C:
- S: +OK mailbox has 1 message (369 octets)
-
-8. ABNF for POP URL scheme
-
- The POP URL scheme is described using [ABNF]:
-
- achar = uchar / "&" / "=" / "~"
- ; see [BASIC-URL] for "uchar" definition
-
- auth = ";AUTH=" ( "*" / enc-auth-type )
-
- enc-auth-type = enc-sasl / enc-ext
-
- enc-ext = "+" ("APOP" / 1*achar)
- ;APOP or encoded extension mechanism name
-
- enc-sasl = 1*achar
- ;encoded version of [SASL] "auth_type"
-
- enc-user = 1*achar
- ;encoded version of [POP3] mailbox
-
- pop-url = "pop://" server
-
- server = [user-auth "@"] hostport
- ;See [BASIC-URL] for "hostport" definition
-
- user-auth = enc-user [auth]
-
-9. Security Considerations
-
- Security considerations discussed in the [POP3] specification and the
- [BASIC-URL] specification are relevant. Security considerations
- related to authenticated URLs are discussed in section 4 of this
- document.
-
- Many email clients store the plain text password for later use after
- logging into a POP server. Such clients MUST NOT use a stored
- password in response to a POP URL without explicit permission from
- the user to supply that password to the specified host name.
-
-
-
-
-
-Gellens Standards Track [Page 5]
-
-RFC 2384 POP URL Scheme August 1998
-
-
-10. Acknowledgements
-
- This document borrows heavily from Chris Newman's [IMAP-URL]
- specification, and has attempted to follow the advice in [URL-
- GUIDELINES].
-
-11. References
-
- [ABNF] Crocker, D., and P. Overell, "Augmented BNF for
- Syntax Specifications: ABNF", RFC 2234, November
- 1997.
-
- [ACAP] Newman, C., and J. Myers, "ACAP -- Application
- Configuration Access Protocol", RFC 2244, November
- 1997.
-
- [BASIC-URL] Berners-Lee, T., Masinter, L., and M. McCahill,
- "Uniform Resource Locators (URL)", RFC 1738,
- December 1994.
-
- [IMAP-URL] Newman, C., "IMAP URL Scheme", RFC 2192, September
- 1997.
-
- [IMAP4] Crispin, M., "Internet Message Access Protocol -
- Version 4rev1", RFC 2060, December 1996.
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
- December 1994.
-
- [POP3] Myers, J., and M. Rose, "Post Office Protocol --
- Version 3", STD 53, RFC 1939, May 1996.
-
- [SASL] Myers, J., "Simple Authentication and Security Layer
- (SASL)", RFC 2222, October 1997.
-
- [URL-GUIDELINES] Masinter, Alvestrand, Zigmond, "Guidelines for new
- URL Schemes", Work in Progress.
-
- [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 2279, January 1998.
-
-
-
-
-
-
-
-
-Gellens Standards Track [Page 6]
-
-RFC 2384 POP URL Scheme August 1998
-
-
-12. Author's Address
-
- Randall Gellens
- QUALCOMM, Incorporated
- 6455 Lusk Blvd.
- San Diego, CA 92121-2779
- U.S.A.
-
- Phone: +1 619 651 5115
- Fax: +1 619 651 5334
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gellens Standards Track [Page 7]
-
-RFC 2384 POP URL Scheme August 1998
-
-
-13. Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gellens Standards Track [Page 8]
-
diff --git a/doc/rfc/rfc2444.txt b/doc/rfc/rfc2444.txt
deleted file mode 100644
index 80a65a2..0000000
--- a/doc/rfc/rfc2444.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group C. Newman
-Request for Comments: 2444 Innosoft
-Updates: 2222 October 1998
-Category: Standards Track
-
-
- The One-Time-Password SASL Mechanism
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
-Abstract
-
- OTP [OTP] provides a useful authentication mechanism for situations
- where there is limited client or server trust. Currently, OTP is
- added to protocols in an ad-hoc fashion with heuristic parsing. This
- specification defines an OTP SASL [SASL] mechanism so it can be
- easily and formally integrated into many application protocols.
-
-1. How to Read This Document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
- "RECOMMENDED" and "MAY" in this document are to be interpreted as
- defined in "Key words for use in RFCs to Indicate Requirement Levels"
- [KEYWORDS].
-
- This memo assumes the reader is familiar with OTP [OTP], OTP extended
- responses [OTP-EXT] and SASL [SASL].
-
-2. Intended Use
-
- The OTP SASL mechanism replaces the SKEY SASL mechanism [SASL]. OTP
- is a good choice for usage scenarios where the client is untrusted
- (e.g., a kiosk client), as a one-time password will only give the
- client a single opportunity to act on behalf of the user. OTP is
- also a good choice for situations where interactive logins are
- permitted to the server, as a compromised OTP authentication database
- is only subject to dictionary attacks, unlike authentication
- databases for other simple mechanisms such as CRAM-MD5 [CRAM-MD5].
-
-
-
-Newman Standards Track [Page 1]
-
-RFC 2444 OTP SASL Mechanism October 1998
-
-
- It is important to note that each use of the OTP mechanism causes the
- authentication database entry for a user to be updated.
-
- This SASL mechanism provides a formal way to integrate OTP into
- SASL-enabled protocols including IMAP [IMAP4], ACAP [ACAP], POP3
- [POP-AUTH] and LDAPv3 [LDAPv3].
-
-3. Profiling OTP for SASL
-
- OTP [OTP] and OTP extended responses [OTP-EXT] offer a number of
- options. However, for authentication to succeed, the client and
- server need compatible option sets. This specification defines a
- single SASL mechanism: OTP. The following rules apply to this
- mechanism:
-
- o The extended response syntax MUST be used.
-
- o Servers MUST support the following four OTP extended responses:
- "hex", "word", "init-hex" and "init-word". Servers MUST support
- the "word" and "init-word" responses for the standard dictionary
- and SHOULD support alternate dictionaries. Servers MUST NOT
- require use of any additional OTP extensions or options.
-
- o Clients SHOULD support display of the OTP challenge to the user
- and entry of an OTP in multi-word format. Clients MAY also
- support direct entry of the pass phrase and compute the "hex" or
- "word" response.
-
- o Clients MUST indicate when authentication fails due to the
- sequence number getting too low and SHOULD offer the user the
- option to reset the sequence using the "init-hex" or "init-word"
- response.
-
- Support for the MD5 algorithm is REQUIRED, and support for the SHA1
- algorithm is RECOMMENDED.
-
-4. OTP Authentication Mechanism
-
- The mechanism does not provide any security layer.
-
- The client begins by sending a message to the server containing the
- following two pieces of information.
-
- (1) An authorization identity. When the empty string is used, this
- defaults to the authentication identity. This is used by system
- administrators or proxy servers to login with a different user
- identity. This field may be up to 255 octets and is terminated by a
- NUL (0) octet. US-ASCII printable characters are preferred, although
-
-
-
-Newman Standards Track [Page 2]
-
-RFC 2444 OTP SASL Mechanism October 1998
-
-
- UTF-8 [UTF-8] printable characters are permitted to support
- international names. Use of character sets other than US-ASCII and
- UTF-8 is forbidden.
-
- (2) An authentication identity. The identity whose pass phrase will
- be used. This field may be up to 255 octets. US-ASCII printable
- characters are preferred, although UTF-8 [UTF-8] printable characters
- are permitted to support international names. Use of character sets
- other than US-ASCII and UTF-8 is forbidden.
-
- The server responds by sending a message containing the OTP challenge
- as described in OTP [OTP] and OTP extended responses [OTP-EXT].
-
- If a client sees an unknown hash algorithm name it will not be able
- to process a pass phrase input by the user. In this situation the
- client MAY prompt for the six-word format, issue the cancel sequence
- as specified by the SASL profile for the protocol in use and try a
- different SASL mechanism, or close the connection and refuse to
- authenticate. As a result of this behavior, a server is restricted
- to one OTP hash algorithm per user.
-
- On success, the client generates an extended response in the "hex",
- "word", "init-hex" or "init-word" format. The client is not required
- to terminate the response with a space or a newline and SHOULD NOT
- include unnecessary whitespace.
-
- Servers MUST tolerate input of arbitrary length, but MAY fail the
- authentication if the length of client input exceeds reasonable size.
-
-5. Examples
-
- In these example, "C:" represents lines sent from the client to the
- server and "S:" represents lines sent from the server to the client.
- The user name is "tim" and no authorization identity is provided.
- The "<NUL>" below represents an ASCII NUL octet.
-
- The following is an example of the OTP mechanism using the ACAP
- [ACAP] profile of SASL. The pass phrase used in this example is:
- This is a test.
-
- C: a001 AUTHENTICATE "OTP" {4}
- C: <NUL>tim
- S: + "otp-md5 499 ke1234 ext"
- C: "hex:5bf075d9959d036f"
- S: a001 OK "AUTHENTICATE completed"
-
-
-
-
-
-
-Newman Standards Track [Page 3]
-
-RFC 2444 OTP SASL Mechanism October 1998
-
-
- Here is the same example using the six-words response:
-
- C: a001 AUTHENTICATE "OTP" {4}
- C: <NUL>tim
- S: + "otp-md5 499 ke1234 ext"
- C: "word:BOND FOGY DRAB NE RISE MART"
- S: a001 OK "AUTHENTICATE completed"
-
- Here is the same example using the OTP-SHA1 mechanism:
-
- C: a001 AUTHENTICATE "OTP" {4}
- C: <NUL>tim
- S: + "otp-sha1 499 ke1234 ext"
- C: "hex:c90fc02cc488df5e"
- S: a001 OK "AUTHENTICATE completed"
-
- Here is the same example with the init-hex extended response
-
- C: a001 AUTHENTICATE "OTP" {4}
- C: <NUL>tim
- S: + "otp-md5 499 ke1234 ext"
- C: "init-hex:5bf075d9959d036f:md5 499 ke1235:3712dcb4aa5316c1"
- S: a001 OK "OTP sequence reset, authentication complete"
-
- The following is an example of the OTP mechanism using the IMAP
- [IMAP4] profile of SASL. The pass phrase used in this example is:
- this is a test
-
- C: a001 AUTHENTICATE OTP
- S: +
- C: AHRpbQ==
- S: + b3RwLW1kNSAxMjMga2UxMjM0IGV4dA==
- C: aGV4OjExZDRjMTQ3ZTIyN2MxZjE=
- S: a001 OK AUTHENTICATE completed
-
- Note that the lack of an initial client response and the base64
- encoding are characteristics of the IMAP profile of SASL. The server
- challenge is "otp-md5 123 ke1234 ext" and the client response is
- "hex:11d4c147e227c1f1".
-
-6. Security Considerations
-
- This specification introduces no security considerations beyond those
- those described in SASL [SASL], OTP [OTP] and OTP extended responses
- [OTP-EXT]. A brief summary of these considerations follows:
-
- This mechanism does not provide session privacy, server
- authentication or protection from active attacks.
-
-
-
-Newman Standards Track [Page 4]
-
-RFC 2444 OTP SASL Mechanism October 1998
-
-
- This mechanism is subject to passive dictionary attacks. The
- severity of this attack can be reduced by choosing pass phrases well.
-
- The server authentication database necessary for use with OTP need
- not be plaintext-equivalent.
-
- Server implementations MUST protect against the race attack [OTP].
-
-7. Multinational Considerations
-
- As remote access is a crucial service, users are encouraged to
- restrict user names and pass phrases to the US-ASCII character set.
- However, if characters outside the US-ASCII chracter set are used in
- user names and pass phrases, then they are interpreted according to
- UTF-8 [UTF-8].
-
- Server support for alternate dictionaries is strongly RECOMMENDED to
- permit use of the six-word format with non-English words.
-
-8. IANA Considerations
-
- Here is the registration template for the OTP SASL mechanism:
-
- SASL mechanism name: OTP
- Security Considerations: See section 6 of this memo
- Published specification: this memo
- Person & email address to contact for futher information:
- see author's address section below
- Intended usage: COMMON
- Author/Change controller: see author's address section below
-
- This memo also amends the SKEY SASL mechanism registration [SASL] by
- changing its intended usage to OBSOLETE.
-
-9. References
-
- [ACAP] Newman, C. and J. Myers, "ACAP -- Application
- Configuration Access Protocol", RFC 2244, November 1997.
-
- [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
- AUTHorize Extension for Simple Challenge/Response", RFC
- 2195, September 1997.
-
- [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
- 4rev1", RFC 2060, December 1996.
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-Newman Standards Track [Page 5]
-
-RFC 2444 OTP SASL Mechanism October 1998
-
-
- [LDAPv3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
- April 1992.
-
- [OTP] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time
- Password System", RFC 2289, February 1998.
-
- [OTP-EXT] Metz, C., "OTP Extended Responses", RFC 2243, November
- 1997.
-
- [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
- December 1994.
-
- [SASL] Myers, J., "Simple Authentication and Security Layer
- (SASL)", RFC 2222, October 1997.
-
- [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 2279, January 1998.
-
-10. Author's Address
-
- Chris Newman
- Innosoft International, Inc.
- 1050 Lakes Drive
- West Covina, CA 91790 USA
-
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Newman Standards Track [Page 6]
-
-RFC 2444 OTP SASL Mechanism October 1998
-
-
-11. Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Newman Standards Track [Page 7]
-
diff --git a/doc/rfc/rfc2449.txt b/doc/rfc/rfc2449.txt
deleted file mode 100644
index 1282a34..0000000
--- a/doc/rfc/rfc2449.txt
+++ /dev/null
@@ -1,1067 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Gellens
-Request for Comments: 2449 Qualcomm
-Updates: 1939 C. Newman
-Category: Standards Track Innosoft
- L. Lundblade
- Qualcomm
- November 1998
-
-
- POP3 Extension Mechanism
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
-IESG Note
-
- This extension to the POP3 protocol is to be used by a server to
- express policy descisions taken by the server administrator. It is
- not an endorsement of implementations of further POP3 extensions
- generally. It is the general view that the POP3 protocol should stay
- simple, and for the simple purpose of downloading email from a mail
- server. If more complicated operations are needed, the IMAP protocol
- [RFC 2060] should be used. The first paragraph of section 7 should
- be read very carefully.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. Conventions Used in this Document . . . . . . . . . . . . . 3
- 3. General Command and Response Grammar . . . . . . . . . . . . 3
- 4. Parameter and Response Lengths . . . . . . . . . . . . . . 4
- 5. The CAPA Command . . . . . . . . . . . . . . . . . . . . . . 4
- 6. Initial Set of Capabilities . . . . . . . . . . . . . . . . 5
- 6.1. TOP capability . . . . . . . . . . . . . . . . . . . . . 6
- 6.2. USER capability . . . . . . . . . . . . . . . . . . . . 6
- 6.3. SASL capability . . . . . . . . . . . . . . . . . . . . 7
- 6.4. RESP-CODES capability . . . . . . . . . . . . . . . . . 8
- 6.5. LOGIN-DELAY capability . . . . . . . . . . . . . . . . . 8
- 6.6. PIPELINING capability . . . . . . . . . . . . . . . . . 9
-
-
-
-Gellens, et. al. Standards Track [Page 1]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- 6.7. EXPIRE capability . . . . . . . . . . . . . . . . . . . 10
- 6.8. UIDL capability . . . . . . . . . . . . . . . . . . . . 13
- 6.9. IMPLEMENTATION capability . . . . . . . . . . . . . . . 13
- 7. Future Extensions to POP3 . . . . . . . . . . . . . . . . . 14
- 8. Extended POP3 Response Codes . . . . . . . . . . . . . . . . 14
- 8.1. Initial POP3 response codes . . . . . . . . . . . . . . 15
- 8.1.1. The LOGIN-DELAY response code . . . . . . . . . . . 15
- 8.1.2. The IN-USE response code . . . . . . . . . . . . . 16
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
- 10. Security Considerations . . . . . . . . . . . . . . . . . . 17
- 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
- 12. References . . . . . . . . . . . . . . . . . . . . . . . . 17
- 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18
- 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
-
-1. Introduction
-
- The Post Office Protocol version 3 [POP3] is very widely used.
- However, while it includes some optional commands (and some useful
- protocol extensions have been published), it lacks a mechanism for
- advertising support for these extensions or for behavior variations.
-
- Currently these optional features and extensions can only be detected
- by probing, if at all. This is at best inefficient, and possibly
- worse. As a result, some clients have manual configuration options
- for POP3 server capabilities.
-
- Because one of the most important characteristics of POP3 is its
- simplicity, it is desirable that extensions be few in number (see
- section 7). However, some extensions are necessary (such as ones
- that provide improved security [POP-AUTH]), while others are very
- desirable in certain situations. In addition, a means for
- discovering server behavior is needed.
-
- This memo updates RFC 1939 [POP3] to define a mechanism to announce
- support for optional commands, extensions, and unconditional server
- behavior. Included is an initial set of currently deployed
- capabilities which vary between server implementations, and several
- new capabilities (SASL, RESP-CODES, LOGIN-DELAY, PIPELINING, EXPIRE
- and IMPLEMENTATION). This document also extends POP3 error messages
- so that machine parsable codes can be provided to the client. An
- initial set of response codes is included. In addition, an [ABNF]
- specification of POP3 commands and responses is defined.
-
- Public comments should be sent to the IETF POP3 Extensions mailing
- list, <address@hidden>. To subscribe, send a message
- containing SUBSCRIBE to <address@hidden>.
-
-
-
-
-Gellens, et. al. Standards Track [Page 2]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
-2. Conventions Used in this Document
-
- The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
- and "MAY" in this document are to be interpreted as described in "Key
- words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
-
- In examples, "C:" and "S:" indicate lines sent by the client and
- server respectively.
-
-3. General Command and Response Grammar
-
- The general form of POP3 commands and responses is described using
- [ABNF]:
-
- POP3 commands:
-
- command = keyword *(SP param) CRLF ;255 octets maximum
- keyword = 3*4VCHAR
- param = 1*VCHAR
-
- POP3 responses:
-
- response = greeting / single-line / capa-resp / multi-line
- capa-resp = single-line *capability "." CRLF
- capa-tag = 1*cchar
- capability = capa-tag *(SP param) CRLF ;512 octets maximum
- cchar = %x21-2D / %x2F-7F
- ;printable ASCII, excluding "."
- dot-stuffed = *CHAR CRLF ;must be dot-stuffed
- gchar = %x21-3B / %x3D-7F
- ;printable ASCII, excluding "<"
- greeting = "+OK" [resp-code] *gchar [timestamp] *gchar CRLF
- ;512 octets maximum
- multi-line = single-line *dot-stuffed "." CRLF
- rchar = %x21-2E / %x30-5C / %x5E-7F
- ;printable ASCII, excluding "/" and "]"
- resp-code = "[" resp-level *("/" resp-level) "]"
- resp-level = 1*rchar
- schar = %x21-5A / %x5C-7F
- ;printable ASCII, excluding "["
- single-line = status [SP text] CRLF ;512 octets maximum
- status = "+OK" / "-ERR"
- text = *schar / resp-code *CHAR
- timestamp = "<" *VCHAR ">"
- ;MUST conform to RFC-822 msg-id
-
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 3]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
-4. Parameter and Response Lengths
-
- This specification increases the length restrictions on commands and
- parameters imposed by RFC 1939.
-
- The maximum length of a command is increased from 47 characters (4
- character command, single space, 40 character argument, CRLF) to 255
- octets, including the terminating CRLF.
-
- Servers which support the CAPA command MUST support commands up to
- 255 octets. Servers MUST also support the largest maximum command
- length specified by any supported capability.
-
- The maximum length of the first line of a command response (including
- the initial greeting) is unchanged at 512 octets (including the
- terminating CRLF).
-
-5. The CAPA Command
-
- The POP3 CAPA command returns a list of capabilities supported by the
- POP3 server. It is available in both the AUTHORIZATION and
- TRANSACTION states.
-
- A capability description MUST document in which states the capability
- is announced, and in which states the commands are valid.
-
- Capabilities available in the AUTHORIZATION state MUST be announced
- in both states.
-
- If a capability is announced in both states, but the argument might
- differ after authentication, this possibility MUST be stated in the
- capability description.
-
- (These requirements allow a client to issue only one CAPA command if
- it does not use any TRANSACTION-only capabilities, or any
- capabilities whose values may differ after authentication.)
-
- If the authentication step negotiates an integrity protection layer,
- the client SHOULD reissue the CAPA command after authenticating, to
- check for active down-negotiation attacks.
-
- Each capability may enable additional protocol commands, additional
- parameters and responses for existing commands, or describe an aspect
- of server behavior. These details are specified in the description
- of the capability.
-
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 4]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- Section 3 describes the CAPA response using [ABNF]. When a
- capability response describes an optional command, the <capa-tag>
- SHOULD be identical to the command keyword. CAPA response tags are
- case-insensitive.
-
- CAPA
-
- Arguments:
- none
-
- Restrictions:
- none
-
- Discussion:
- An -ERR response indicates the capability command is not
- implemented and the client will have to probe for
- capabilities as before.
-
- An +OK response is followed by a list of capabilities, one
- per line. Each capability name MAY be followed by a single
- space and a space-separated list of parameters. Each
- capability line is limited to 512 octets (including the
- CRLF). The capability list is terminated by a line
- containing a termination octet (".") and a CRLF pair.
-
- Possible Responses:
- +OK -ERR
-
- Examples:
- C: CAPA
- S: +OK Capability list follows
- S: TOP
- S: USER
- S: SASL CRAM-MD5 KERBEROS_V4
- S: RESP-CODES
- S: LOGIN-DELAY 900
- S: PIPELINING
- S: EXPIRE 60
- S: UIDL
- S: IMPLEMENTATION Shlemazle-Plotz-v302
- S: .
-
-6. Initial Set of Capabilities
-
- This section defines an initial set of POP3 capabilities. These
- include the optional POP3 commands, already published POP3
- extensions, and behavior variations between POP3 servers which can
- impact clients.
-
-
-
-Gellens, et. al. Standards Track [Page 5]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- Note that there is no APOP capability, even though APOP is an
- optional command in [POP3]. Clients discover server support of APOP
- by the presence in the greeting banner of an initial challenge
- enclosed in angle brackets ("<>"). Therefore, an APOP capability
- would introduce two ways for a server to announce the same thing.
-
-6.1. TOP capability
-
- CAPA tag:
- TOP
-
- Arguments:
- none
-
- Added commands:
- TOP
-
- Standard commands affected:
- none
-
- Announced states / possible differences:
- both / no
-
- Commands valid in states:
- TRANSACTION
-
- Specification reference:
- [POP3]
-
- Discussion:
- The TOP capability indicates the optional TOP command is
- available.
-
-6.2. USER capability
-
- CAPA tag:
- USER
-
- Arguments:
- none
-
- Added commands:
- USER PASS
-
- Standard commands affected:
- none
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 6]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- Announced states / possible differences:
- both / no
-
- Commands valid in states:
- AUTHENTICATION
-
- Specification reference:
- [POP3]
-
- Discussion:
- The USER capability indicates that the USER and PASS commands
- are supported, although they may not be available to all users.
-
-6.3. SASL capability
-
- CAPA tag:
- SASL
-
- Arguments:
- Supported SASL mechanisms
-
- Added commands:
- AUTH
-
- Standard commands affected:
- none
-
- Announced states / possible differences:
- both / no
-
- Commands valid in states:
- AUTHENTICATION
-
- Specification reference:
- [POP-AUTH, SASL]
-
- Discussion:
- The POP3 AUTH command [POP-AUTH] permits the use of [SASL]
- authentication mechanisms with POP3. The SASL capability
- indicates that the AUTH command is available and that it supports
- an optional base64 encoded second argument for an initial client
- response as described in the SASL specification. The argument to
- the SASL capability is a space separated list of SASL mechanisms
- which are supported.
-
-
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 7]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
-6.4. RESP-CODES capability
-
- CAPA tag:
- RESP-CODES
-
- Arguments:
- none
-
- Added commands:
- none
-
- Standard commands affected:
- none
-
- Announced states / possible differences:
- both / no
-
- Commands valid in states:
- n/a
-
- Specification reference:
- this document
-
- Discussion:
- The RESP-CODES capability indicates that any response text issued
- by this server which begins with an open square bracket ("[") is
- an extended response code (see section 8).
-
-6.5. LOGIN-DELAY capability
-
- CAPA tag:
- LOGIN-DELAY
-
- Arguments:
- minimum seconds between logins; optionally followed by USER in
- AUTHENTICATION state.
-
- Added commands:
- none
-
- Standard commands affected:
- USER PASS APOP AUTH
-
- Announced states / possible differences:
- both / yes
-
- Commands valid in states:
- n/a
-
-
-
-Gellens, et. al. Standards Track [Page 8]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- Specification reference:
- this document
-
- Discussion:
- POP3 clients often login frequently to check for new mail.
- Unfortunately, the process of creating a connection,
- authenticating the user, and opening the user's maildrop can be
- very resource intensive on the server. A number of deployed POP3
- servers try to reduce server load by requiring a delay between
- logins. The LOGIN-DELAY capability includes an integer argument
- which indicates the number of seconds after an "+OK" response to
- a PASS, APOP, or AUTH command before another authentication will
- be accepted. Clients which permit the user to configure a mail
- check interval SHOULD use this capability to determine the
- minimum permissible interval. Servers which advertise LOGIN-
- DELAY SHOULD enforce it.
-
- If the minimum login delay period could differ per user (that is,
- the LOGIN-DELAY argument might change after authentication), the
- server MUST announce in AUTHENTICATION state the largest value
- which could be set for any user. This might be the largest value
- currently in use for any user (so only one value per server), or
- even the largest value which the server permits to be set for any
- user. The server SHOULD append the token "USER" to the LOGIN-
- DELAY parameter in AUTHENTICATION state, to inform the client
- that a more accurate value is available after authentication.
- The server SHOULD announce the more accurate value in TRANSACTION
- state. (The "USER" token allows the client to decide if a second
- CAPA command is needed or not.)
-
- Servers enforce LOGIN-DELAY by rejecting an authentication
- command with or without the LOGIN-DELAY error response. See
- section 8.1.1 for more information.
-
-6.6. PIPELINING capability
-
- CAPA tag:
- PIPELINING
-
- Arguments:
- none
-
- Added commands:
- none
-
- Standard commands affected:
- all
-
-
-
-
-Gellens, et. al. Standards Track [Page 9]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- Announced states / possible differences:
- both / no
-
- Commands valid in states:
- n/a
-
- Specification reference:
- this document
-
- Discussion:
- The PIPELINING capability indicates the server is capable of
- accepting multiple commands at a time; the client does not have
- to wait for the response to a command before issuing a subsequent
- command. If a server supports PIPELINING, it MUST process each
- command in turn. If a client uses PIPELINING, it MUST keep track
- of which commands it has outstanding, and match server responses
- to commands in order. If either the client or server uses
- blocking writes, it MUST not exceed the window size of the
- underlying transport layer.
-
- Some POP3 clients have an option to indicate the server supports
- "Overlapped POP3 commands." This capability removes the need to
- configure this at the client.
-
- This is roughly synonymous with the ESMTP PIPELINING extension
- [PIPELINING], however, since SMTP [SMTP] tends to have short
- commands and responses, the benefit is in grouping multiple
- commands and sending them as a unit. While there are cases of
- this in POP (for example, USER and PASS could be batched,
- multiple RETR and/or DELE commands could be sent as a group),
- because POP has short commands and sometimes lengthy responses,
- there is also an advantage is sending new commands while still
- receiving the response to an earlier command (for example,
- sending RETR and/or DELE commands while processing a UIDL reply).
-
-6.7. EXPIRE capability
-
- CAPA tag:
- EXPIRE
-
- Arguments:
- server-guaranteed minimum retention days, or NEVER; optionally
- followed by USER in AUTHENTICATION state
-
- Added commands:
- none
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 10]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- Standard commands affected:
- none
-
- Announced states / possible differences:
- both / yes
-
- Commands valid in states:
- n/a
-
- Specification reference:
- this document
-
- Discussion:
- While POP3 allows clients to leave messages on the server, RFC
- 1939 [POP3] warns about the problems that may arise from this,
- and allows servers to delete messages based on site policy.
-
- The EXPIRE capability avoids the problems mentioned in RFC 1939,
- by allowing the server to inform the client as to the policy in
- effect. The argument to the EXPIRE capability indicates the
- minimum server retention period, in days, for messages on the
- server.
-
- EXPIRE 0 indicates the client is not permitted to leave mail on
- the server; when the session enters the UPDATE state the server
- MAY assume an implicit DELE for each message which was downloaded
- with RETR.
-
- EXPIRE NEVER asserts that the server does not delete messages.
-
- The concept of a "retention period" is intentionally vague.
- Servers may start counting days to expiration when a message is
- added to a maildrop, when a client becomes aware of the existence
- of a message through the LIST or UIDL commands, when a message
- has been acted upon in some way (for example, TOP or RETR), or at
- some other event. The EXPIRE capability cannot provide a precise
- indication as to exactly when any specific message will expire.
- The capability is intended to make it easier for clients to
- behave in ways which conform to site policy and user wishes. For
- example, a client might display a warning for attempts to
- configure a "leave mail on server" period which is greater than
- or equal to some percentage of the value announced by the server.
-
- If a site uses any automatic deletion policy, it SHOULD use the
- EXPIRE capability to announce this.
-
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 11]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- The EXPIRE capability, with a parameter other than 0 or NEVER, is
- intended to let the client know that the server does permit mail
- to be left on the server, and to present a value which is the
- smallest which might be in force.
-
- Sites which permit users to retain messages indefinitely SHOULD
- announce this with the EXPIRE NEVER response.
-
- If the expiration policy differs per user (that is, the EXPIRE
- argument might change after authentication), the server MUST
- announce in AUTHENTICATION state the smallest value which could
- be set for any user. This might be the smallest value currently
- in use for any user (so only one value per server), or even the
- smallest value which the server permits to be set for any user.
- The server SHOULD append the token "USER" to the EXPIRE parameter
- in AUTHENTICATION state, to inform the client that a more
- accurate value is available after authentication. The server
- SHOULD announce the more accurate value in TRANSACTION state.
- (The "USER" token allows the client to decide if a second CAPA
- command is needed or not.)
-
- A site may have a message expiration policy which treats messages
- differently depending on which user actions have been performed,
- or based on other factors. For example, a site might delete
- unseen messages after 60 days, and completely- or partially-seen
- messages after 15 days.
-
- The announced EXPIRE value is the smallest retention period which
- is or might be used by any category or condition of the current
- site policy, for any user (in AUTHENTICATION state) or the
- specific user (in TRANSACTION state). That is, EXPIRE informs
- the client of the minimum number of days messages may remain on
- the server under any circumstances.
-
- Examples:
- EXPIRE 5 USER
- EXPIRE 30
- EXPIRE NEVER
- EXPIRE 0
-
- The first example indicates the server might delete messages
- after five days, but the period differs per user, and so a more
- accurate value can be obtained by issuing a second CAPA command
- in TRANSACTION state. The second example indicates the server
- could delete messages after 30 days. In the third example, the
- server announces it does not delete messages. The fourth example
- specifies that the site does not permit messages to be left on
- the server.
-
-
-
-Gellens, et. al. Standards Track [Page 12]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
-6.8. UIDL capability
-
- CAPA tag:
- UIDL
-
- Arguments:
- none
-
- Added commands:
- UIDL
-
- Standard commands affected:
- none
-
- Announced states / possible differences:
- both / no
-
- Commands valid in states:
- TRANSACTION
-
- Specification reference:
- [POP3]
-
- Discussion:
- The UIDL capability indicates that the optional UIDL command is
- supported.
-
-6.9. IMPLEMENTATION capability
-
- CAPA tag:
- IMPLEMENTATION
-
- Arguments:
- string giving server implementation information
-
- Added commands:
- none
-
- Standard commands affected:
- none
-
- Announced states / possible differences:
- both (optionally TRANSACTION only) / no
-
- Commands valid in states:
- n/a
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 13]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- Specification reference:
- this document
-
- Discussion:
- It is often useful to identify an implementation of a particular
- server (for example, when logging). This is commonly done in the
- welcome banner, but one must guess if a string is an
- implementation ID or not.
-
- The argument to the IMPLEMENTATION capability consists of one or
- more tokens which identify the server. (Note that since CAPA
- response tag arguments are space-separated, it may be convenient
- for the IMPLEMENTATION capability argument to not contain spaces,
- so that it is a single token.)
-
- Normally, servers announce IMPLEMENTATION in both states.
- However, a server MAY chose to do so only in TRANSACTION state.
-
- A server MAY include the implementation identification both in
- the welcome banner and in the IMPLEMENTATION capability.
-
- Clients MUST NOT modify their behavior based on the server
- implementation. Instead the server and client should agree on a
- private extension.
-
-7. Future Extensions to POP3
-
- Future extensions to POP3 are in general discouraged, as POP3's
- usefulness lies in its simplicity. POP3 is intended as a download-
- and-delete protocol; mail access capabilities are available in IMAP
- [IMAP4]. Extensions which provide support for additional mailboxes,
- allow uploading of messages to the server, or which deviate from
- POP's download-and-delete model are strongly discouraged and unlikely
- to be permitted on the IETF standards track.
-
- Clients MUST NOT require the presence of any extension for basic
- functionality, with the exception of the authentication commands
- (APOP, AUTH [section 6.3] and USER/PASS).
-
- Section 9 specifies how additional capabilities are defined.
-
-8. Extended POP3 Response Codes
-
- Unextended POP3 is only capable of indicating success or failure to
- most commands. Unfortunately, clients often need to know more
- information about the cause of a failure in order to gracefully
- recover. This is especially important in response to a failed login
-
-
-
-
-Gellens, et. al. Standards Track [Page 14]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- (there are widely-deployed clients which attempt to decode the error
- text of a PASS command result, to try and distinguish between "unable
- to get maildrop lock" and "bad login").
-
- This specification amends the POP3 standard to permit an optional
- response code, enclosed in square brackets, at the beginning of the
- human readable text portion of an "+OK" or "-ERR" response. Clients
- supporting this extension MAY remove any information enclosed in
- square brackets prior to displaying human readable text to the user.
- Immediately following the open square bracket "[" character is a
- response code which is interpreted in a case-insensitive fashion by
- the client.
-
- The response code is hierarchical, with a "/" separating levels of
- detail about the error. Clients MUST ignore unknown hierarchical
- detail about the response code. This is important, as it could be
- necessary to provide further detail for response codes in the future.
-
- Section 3 describes response codes using [ABNF].
-
- If a server supports extended response codes, it indicates this by
- including the RESP-CODES capability in the CAPA response.
-
- Examples:
- C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
- S: -ERR [IN-USE] Do you have another POP session running?
-
-8.1. Initial POP3 response codes
-
- This specification defines two POP3 response codes which can be used
- to determine the reason for a failed login. Section 9 specifies how
- additional response codes are defined.
-
-8.1.1. The LOGIN-DELAY response code
-
- This occurs on an -ERR response to an AUTH, USER (see note), PASS or
- APOP command and indicates that the user has logged in recently and
- will not be allowed to login again until the login delay period has
- expired.
-
- NOTE: Returning the LOGIN-DELAY response code to the USER command
- avoids the work of authenticating the user but reveals to the client
- that the specified user exists. Unless the server is operating in an
- environment where user names are not secret (for example, many
- popular email clients advertise the POP server and user name in an
- outgoing mail header), or where server access is restricted, or the
- server can verify that the connection is to the same user, it is
-
-
-
-
-Gellens, et. al. Standards Track [Page 15]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- strongly recommended that the server not issue this response code to
- the USER command. The server still saves the cost of opening the
- maildrop, which in some environments is the most expensive step.
-
-8.1.2. The IN-USE response code
-
- This occurs on an -ERR response to an AUTH, APOP, or PASS command.
- It indicates the authentication was successful, but the user's
- maildrop is currently in use (probably by another POP3 client).
-
-9. IANA Considerations
-
- This document requests that IANA maintain two new registries: POP3
- capabilities and POP3 response codes.
-
- New POP3 capabilities MUST be defined in a standards track or IESG
- approved experimental RFC, and MUST NOT begin with the letter "X".
-
- New POP3 capabilities MUST include the following information:
- CAPA tag
- Arguments
- Added commands
- Standard commands affected
- Announced states / possible differences
- Commands valid in states
- Specification reference
- Discussion
-
- In addition, new limits for POP3 command and response lengths may
- need to be included.
-
- New POP3 response codes MUST be defined in an RFC or other permanent
- and readily available reference, in sufficient detail so that
- interoperability between independent implementations is possible.
- (This is the "Specification Required" policy described in [IANA]).
-
- New POP3 response code specifications MUST include the following
- information: the complete response code, for which responses (+OK
- or -ERR) and commands it is valid, and a definition of its meaning and
- expected client behavior.
-
-
-
-
-
-
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 16]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
-10. Security Considerations
-
- A capability list can reveal information about the server's
- authentication mechanisms which can be used to determine if certain
- attacks will be successful. However, allowing clients to
- automatically detect availability of stronger mechanisms and alter
- their configurations to use them can improve overall security at a
- site.
-
- Section 8.1 discusses the security issues related to use of the
- LOGIN-DELAY response code with the USER command.
-
-11. Acknowledgments
-
- This document has been revised in part based on comments and
- discussions which took place on and off the IETF POP3 Extensions
- mailing list. The help of those who took the time to review this
- memo and make suggestions is appreciated, especially that of Alexey
- Melnikov, Harald Alvestrand, and Mike Gahrns.
-
-12. References
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [IMAP4] Crispin, M., "Internet Message Access Protocol --
- Version 4rev1", RFC 2060, December 1996.
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [PIPELINING] Freed, N., "SMTP Service Extension for Command
- Pipelining", RFC 2197, September 1997.
-
- [POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version
- 3", STD 53, RFC 1939, May 1996.
-
- [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
- December 1994.
-
- [SASL] Myers, J., "Simple Authentication and Security Layer
- (SASL)", RFC 2222, October 1997.
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 17]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
- 821, August 1982.
-
-13. Authors' Addresses
-
- Randall Gellens
- QUALCOMM Incorporated
- 6455 Lusk Blvd.
- San Diego, CA 92121-2779
- USA
-
- Phone: +1 619 651 5115
- Fax: +1 619 845 7268
- EMail: address@hidden
-
-
- Chris Newman
- Innosoft International, Inc.
- 1050 Lakes Drive
- West Covina, CA 91790
- USA
-
- EMail: address@hidden
-
-
- Laurence Lundblade
- QUALCOMM Incorporated
- 6455 Lusk Blvd.
- San Diego, Ca, 92121-2779
- USA
-
- Phone: +1 619 658 3584
- Fax: +1 619 845 7268
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 18]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
-14. Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 19]
-
diff --git a/doc/rfc/rfc2595.txt b/doc/rfc/rfc2595.txt
deleted file mode 100644
index 66897cd..0000000
--- a/doc/rfc/rfc2595.txt
+++ /dev/null
@@ -1,843 +0,0 @@
-
-
-
-
-
-
-Network Working Group C. Newman
-Request for Comments: 2595 Innosoft
-Category: Standards Track June 1999
-
-
- Using TLS with IMAP, POP3 and ACAP
-
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
-1. Motivation
-
- The TLS protocol (formerly known as SSL) provides a way to secure an
- application protocol from tampering and eavesdropping. The option of
- using such security is desirable for IMAP, POP and ACAP due to common
- connection eavesdropping and hijacking attacks [AUTH]. Although
- advanced SASL authentication mechanisms can provide a lightweight
- version of this service, TLS is complimentary to simple
- authentication-only SASL mechanisms or deployed clear-text password
- login commands.
-
- Many sites have a high investment in authentication infrastructure
- (e.g., a large database of a one-way-function applied to user
- passwords), so a privacy layer which is not tightly bound to user
- authentication can protect against network eavesdropping attacks
- without requiring a new authentication infrastructure and/or forcing
- all users to change their password. Recognizing that such sites will
- desire simple password authentication in combination with TLS
- encryption, this specification defines the PLAIN SASL mechanism for
- use with protocols which lack a simple password authentication
- command such as ACAP and SMTP. (Note there is a separate RFC for the
- STARTTLS command in SMTP [SMTPTLS].)
-
- There is a strong desire in the IETF to eliminate the transmission of
- clear-text passwords over unencrypted channels. While SASL can be
- used for this purpose, TLS provides an additional tool with different
- deployability characteristics. A server supporting both TLS with
-
-
-
-
-Newman Standards Track [Page 1]
-
-RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
-
-
- simple passwords and a challenge/response SASL mechanism is likely to
- interoperate with a wide variety of clients without resorting to
- unencrypted clear-text passwords.
-
- The STARTTLS command rectifies a number of the problems with using a
- separate port for a "secure" protocol variant. Some of these are
- mentioned in section 7.
-
-1.1. Conventions Used in this Document
-
- The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
- "MAY", and "OPTIONAL" in this document are to be interpreted as
- described in "Key words for use in RFCs to Indicate Requirement
- Levels" [KEYWORDS].
-
- Terms related to authentication are defined in "On Internet
- Authentication" [AUTH].
-
- Formal syntax is defined using ABNF [ABNF].
-
- In examples, "C:" and "S:" indicate lines sent by the client and
- server respectively.
-
-2. Basic Interoperability and Security Requirements
-
- The following requirements apply to all implementations of the
- STARTTLS extension for IMAP, POP3 and ACAP.
-
-2.1. Cipher Suite Requirements
-
- Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher
- suite is REQUIRED. This is important as it assures that any two
- compliant implementations can be configured to interoperate.
-
- All other cipher suites are OPTIONAL.
-
-2.2. Privacy Operational Mode Security Requirements
-
- Both clients and servers SHOULD have a privacy operational mode which
- refuses authentication unless successful activation of an encryption
- layer (such as that provided by TLS) occurs prior to or at the time
- of authentication and which will terminate the connection if that
- encryption layer is deactivated. Implementations are encouraged to
- have flexability with respect to the minimal encryption strength or
- cipher suites permitted. A minimalist approach to this
- recommendation would be an operational mode where the
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is mandatory prior to
- permitting authentication.
-
-
-
-Newman Standards Track [Page 2]
-
-RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
-
-
- Clients MAY have an operational mode which uses encryption only when
- it is advertised by the server, but authentication continues
- regardless. For backwards compatibility, servers SHOULD have an
- operational mode where only the authentication mechanisms required by
- the relevant base protocol specification are needed to successfully
- authenticate.
-
-2.3. Clear-Text Password Requirements
-
- Clients and servers which implement STARTTLS MUST be configurable to
- refuse all clear-text login commands or mechanisms (including both
- standards-track and nonstandard mechanisms) unless an encryption
- layer of adequate strength is active. Servers which allow
- unencrypted clear-text logins SHOULD be configurable to refuse
- clear-text logins both for the entire server, and on a per-user
- basis.
-
-2.4. Server Identity Check
-
- During the TLS negotiation, the client MUST check its understanding
- of the server hostname against the server's identity as presented in
- the server Certificate message, in order to prevent man-in-the-middle
- attacks. Matching is performed according to these rules:
-
- - The client MUST use the server hostname it used to open the
- connection as the value to compare against the server name as
- expressed in the server certificate. The client MUST NOT use any
- form of the server hostname derived from an insecure remote source
- (e.g., insecure DNS lookup). CNAME canonicalization is not done.
-
- - If a subjectAltName extension of type dNSName is present in the
- certificate, it SHOULD be used as the source of the server's
- identity.
-
- - Matching is case-insensitive.
-
- - A "*" wildcard character MAY be used as the left-most name
- component in the certificate. For example, *.example.com would
- match a.example.com, foo.example.com, etc. but would not match
- example.com.
-
- - If the certificate contains multiple names (e.g. more than one
- dNSName field), then a match with any one of the fields is
- considered acceptable.
-
- If the match fails, the client SHOULD either ask for explicit user
- confirmation, or terminate the connection and indicate the server's
- identity is suspect.
-
-
-
-Newman Standards Track [Page 3]
-
-RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
-
-
-2.5. TLS Security Policy Check
-
- Both the client and server MUST check the result of the STARTTLS
- command and subsequent TLS negotiation to see whether acceptable
- authentication or privacy was achieved. Ignoring this step
- completely invalidates using TLS for security. The decision about
- whether acceptable authentication or privacy was achieved is made
- locally, is implementation-dependent, and is beyond the scope of this
- document.
-
-3. IMAP STARTTLS extension
-
- When the TLS extension is present in IMAP, "STARTTLS" is listed as a
- capability in response to the CAPABILITY command. This extension
- adds a single command, "STARTTLS" to the IMAP protocol which is used
- to begin a TLS negotiation.
-
-3.1. STARTTLS Command
-
- Arguments: none
-
- Responses: no specific responses for this command
-
- Result: OK - begin TLS negotiation
- BAD - command unknown or arguments invalid
-
- A TLS negotiation begins immediately after the CRLF at the end of
- the tagged OK response from the server. Once a client issues a
- STARTTLS command, it MUST NOT issue further commands until a
- server response is seen and the TLS negotiation is complete.
-
- The STARTTLS command is only valid in non-authenticated state.
- The server remains in non-authenticated state, even if client
- credentials are supplied during the TLS negotiation. The SASL
- [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
- client credentials are successfully exchanged, but servers
- supporting the STARTTLS command are not required to support the
- EXTERNAL mechanism.
-
- Once TLS has been started, the client MUST discard cached
- information about server capabilities and SHOULD re-issue the
- CAPABILITY command. This is necessary to protect against
- man-in-the-middle attacks which alter the capabilities list prior
- to STARTTLS. The server MAY advertise different capabilities
- after STARTTLS.
-
- The formal syntax for IMAP is amended as follows:
-
-
-
-
-Newman Standards Track [Page 4]
-
-RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
-
-
- command_any =/ "STARTTLS"
-
- Example: C: a001 CAPABILITY
- S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
- S: a001 OK CAPABILITY completed
- C: a002 STARTTLS
- S: a002 OK Begin TLS negotiation now
- <TLS negotiation, further commands are under TLS layer>
- C: a003 CAPABILITY
- S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL
- S: a003 OK CAPABILITY completed
- C: a004 LOGIN joe password
- S: a004 OK LOGIN completed
-
-3.2. IMAP LOGINDISABLED capability
-
- The current IMAP protocol specification (RFC 2060) requires the
- implementation of the LOGIN command which uses clear-text passwords.
- Many sites may choose to disable this command unless encryption is
- active for security reasons. An IMAP server MAY advertise that the
- LOGIN command is disabled by including the LOGINDISABLED capability
- in the capability response. Such a server will respond with a tagged
- "NO" response to any attempt to use the LOGIN command.
-
- An IMAP server which implements STARTTLS MUST implement support for
- the LOGINDISABLED capability on unencrypted connections.
-
- An IMAP client which complies with this specification MUST NOT issue
- the LOGIN command if this capability is present.
-
- This capability is useful to prevent clients compliant with this
- specification from sending an unencrypted password in an environment
- subject to passive attacks. It has no impact on an environment
- subject to active attacks as a man-in-the-middle attacker can remove
- this capability. Therefore this does not relieve clients of the need
- to follow the privacy mode recommendation in section 2.2.
-
- Servers advertising this capability will fail to interoperate with
- many existing compliant IMAP clients and will be unable to prevent
- those clients from disclosing the user's password.
-
-4. POP3 STARTTLS extension
-
- The POP3 STARTTLS extension adds the STLS command to POP3 servers.
- If this is implemented, the POP3 extension mechanism [POP3EXT] MUST
- also be implemented to avoid the need for client probing of multiple
- commands. The capability name "STLS" indicates this command is
- present and permitted in the current state.
-
-
-
-Newman Standards Track [Page 5]
-
-RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
-
-
- STLS
-
- Arguments: none
-
- Restrictions:
- Only permitted in AUTHORIZATION state.
-
- Discussion:
- A TLS negotiation begins immediately after the CRLF at the
- end of the +OK response from the server. A -ERR response
- MAY result if a security layer is already active. Once a
- client issues a STLS command, it MUST NOT issue further
- commands until a server response is seen and the TLS
- negotiation is complete.
-
- The STLS command is only permitted in AUTHORIZATION state
- and the server remains in AUTHORIZATION state, even if
- client credentials are supplied during the TLS negotiation.
- The AUTH command [POP-AUTH] with the EXTERNAL mechanism
- [SASL] MAY be used to authenticate once TLS client
- credentials are successfully exchanged, but servers
- supporting the STLS command are not required to support the
- EXTERNAL mechanism.
-
- Once TLS has been started, the client MUST discard cached
- information about server capabilities and SHOULD re-issue
- the CAPA command. This is necessary to protect against
- man-in-the-middle attacks which alter the capabilities list
- prior to STLS. The server MAY advertise different
- capabilities after STLS.
-
- Possible Responses:
- +OK -ERR
-
- Examples:
- C: STLS
- S: +OK Begin TLS negotiation
- <TLS negotiation, further commands are under TLS layer>
- ...
- C: STLS
- S: -ERR Command not permitted when TLS active
-
-
-
-
-
-
-
-
-
-
-Newman Standards Track [Page 6]
-
-RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
-
-
-5. ACAP STARTTLS extension
-
- When the TLS extension is present in ACAP, "STARTTLS" is listed as a
- capability in the ACAP greeting. No arguments to this capability are
- defined at this time. This extension adds a single command,
- "STARTTLS" to the ACAP protocol which is used to begin a TLS
- negotiation.
-
-5.1. STARTTLS Command
-
- Arguments: none
-
- Responses: no specific responses for this command
-
- Result: OK - begin TLS negotiation
- BAD - command unknown or arguments invalid
-
- A TLS negotiation begins immediately after the CRLF at the end of
- the tagged OK response from the server. Once a client issues a
- STARTTLS command, it MUST NOT issue further commands until a
- server response is seen and the TLS negotiation is complete.
-
- The STARTTLS command is only valid in non-authenticated state.
- The server remains in non-authenticated state, even if client
- credentials are supplied during the TLS negotiation. The SASL
- [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
- client credentials are successfully exchanged, but servers
- supporting the STARTTLS command are not required to support the
- EXTERNAL mechanism.
-
- After the TLS layer is established, the server MUST re-issue an
- untagged ACAP greeting. This is necessary to protect against
- man-in-the-middle attacks which alter the capabilities list prior
- to STARTTLS. The client MUST discard cached capability
- information and replace it with the information from the new ACAP
- greeting. The server MAY advertise different capabilities after
- STARTTLS.
-
- The formal syntax for ACAP is amended as follows:
-
- command_any =/ "STARTTLS"
-
- Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
- C: a002 STARTTLS
- S: a002 OK "Begin TLS negotiation now"
- <TLS negotiation, further commands are under TLS layer>
- S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
-
-
-
-
-Newman Standards Track [Page 7]
-
-RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
-
-
-6. PLAIN SASL mechanism
-
- Clear-text passwords are simple, interoperate with almost all
- existing operating system authentication databases, and are useful
- for a smooth transition to a more secure password-based
- authentication mechanism. The drawback is that they are unacceptable
- for use over an unencrypted network connection.
-
- This defines the "PLAIN" SASL mechanism for use with ACAP and other
- protocols with no clear-text login command. The PLAIN SASL mechanism
- MUST NOT be advertised or used unless a strong encryption layer (such
- as the provided by TLS) is active or backwards compatibility dictates
- otherwise.
-
- The mechanism consists of a single message from the client to the
- server. The client sends the authorization identity (identity to
- login as), followed by a US-ASCII NUL character, followed by the
- authentication identity (identity whose password will be used),
- followed by a US-ASCII NUL character, followed by the clear-text
- password. The client may leave the authorization identity empty to
- indicate that it is the same as the authentication identity.
-
- The server will verify the authentication identity and password with
- the system authentication database and verify that the authentication
- credentials permit the client to login as the authorization identity.
- If both steps succeed, the user is logged in.
-
- The server MAY also use the password to initialize any new
- authentication database, such as one suitable for CRAM-MD5
- [CRAM-MD5].
-
- Non-US-ASCII characters are permitted as long as they are represented
- in UTF-8 [UTF-8]. Use of non-visible characters or characters which
- a user may be unable to enter on some keyboards is discouraged.
-
- The formal grammar for the client message using Augmented BNF [ABNF]
- follows.
-
- message = [authorize-id] NUL authenticate-id NUL password
- authenticate-id = 1*UTF8-SAFE ; MUST accept up to 255 octets
- authorize-id = 1*UTF8-SAFE ; MUST accept up to 255 octets
- password = 1*UTF8-SAFE ; MUST accept up to 255 octets
- NUL = %x00
- UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 /
- UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6
- UTF8-1 = %x80-BF
- UTF8-2 = %xC0-DF UTF8-1
- UTF8-3 = %xE0-EF 2UTF8-1
-
-
-
-Newman Standards Track [Page 8]
-
-RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
-
-
- UTF8-4 = %xF0-F7 3UTF8-1
- UTF8-5 = %xF8-FB 4UTF8-1
- UTF8-6 = %xFC-FD 5UTF8-1
-
- Here is an example of how this might be used to initialize a CRAM-MD5
- authentication database for ACAP:
-
- Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
- C: a001 AUTHENTICATE "CRAM-MD5"
- S: + "<address@hidden>"
- C: "tim b913a602c7eda7a495b4e6e7334d3890"
- S: a001 NO (TRANSITION-NEEDED)
- "Please change your password, or use TLS to login"
- C: a002 STARTTLS
- S: a002 OK "Begin TLS negotiation now"
- <TLS negotiation, further commands are under TLS layer>
- S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
- C: a003 AUTHENTICATE "PLAIN" {21+}
- C: <NUL>tim<NUL>tanstaaftanstaaf
- S: a003 OK CRAM-MD5 password initialized
-
- Note: In this example, <NUL> represents a single ASCII NUL octet.
-
-7. imaps and pop3s ports
-
- Separate "imaps" and "pop3s" ports were registered for use with SSL.
- Use of these ports is discouraged in favor of the STARTTLS or STLS
- commands.
-
- A number of problems have been observed with separate ports for
- "secure" variants of protocols. This is an attempt to enumerate some
- of those problems.
-
- - Separate ports lead to a separate URL scheme which intrudes into
- the user interface in inappropriate ways. For example, many web
- pages use language like "click here if your browser supports SSL."
- This is a decision the browser is often more capable of making than
- the user.
-
- - Separate ports imply a model of either "secure" or "not secure."
- This can be misleading in a number of ways. First, the "secure"
- port may not in fact be acceptably secure as an export-crippled
- cipher suite might be in use. This can mislead users into a false
- sense of security. Second, the normal port might in fact be
- secured by using a SASL mechanism which includes a security layer.
- Thus the separate port distinction makes the complex topic of
- security policy even more confusing. One common result of this
- confusion is that firewall administrators are often misled into
-
-
-
-Newman Standards Track [Page 9]
-
-RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
-
-
- permitting the "secure" port and blocking the standard port. This
- could be a poor choice given the common use of SSL with a 40-bit
- key encryption layer and plain-text password authentication is less
- secure than strong SASL mechanisms such as GSSAPI with Kerberos 5.
-
- - Use of separate ports for SSL has caused clients to implement only
- two security policies: use SSL or don't use SSL. The desirable
- security policy "use TLS when available" would be cumbersome with
- the separate port model, but is simple with STARTTLS.
-
- - Port numbers are a limited resource. While they are not yet in
- short supply, it is unwise to set a precedent that could double (or
- worse) the speed of their consumption.
-
-
-8. IANA Considerations
-
- This constitutes registration of the "STARTTLS" and "LOGINDISABLED"
- IMAP capabilities as required by section 7.2.1 of RFC 2060 [IMAP].
-
- The registration for the POP3 "STLS" capability follows:
-
- CAPA tag: STLS
- Arguments: none
- Added commands: STLS
- Standard commands affected: May enable USER/PASS as a side-effect.
- CAPA command SHOULD be re-issued after successful completion.
- Announced states/Valid states: AUTHORIZATION state only.
- Specification reference: this memo
-
- The registration for the ACAP "STARTTLS" capability follows:
-
- Capability name: STARTTLS
- Capability keyword: STARTTLS
- Capability arguments: none
- Published Specification(s): this memo
- Person and email address for further information:
- see author's address section below
-
- The registration for the PLAIN SASL mechanism follows:
-
- SASL mechanism name: PLAIN
- Security Considerations: See section 9 of this memo
- Published specification: this memo
- Person & email address to contact for further information:
- see author's address section below
- Intended usage: COMMON
- Author/Change controller: see author's address section below
-
-
-
-Newman Standards Track [Page 10]
-
-RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
-
-
-9. Security Considerations
-
- TLS only provides protection for data sent over a network connection.
- Messages transferred over IMAP or POP3 are still available to server
- administrators and usually subject to eavesdropping, tampering and
- forgery when transmitted through SMTP or NNTP. TLS is no substitute
- for an end-to-end message security mechanism using MIME security
- multiparts [MIME-SEC].
-
- A man-in-the-middle attacker can remove STARTTLS from the capability
- list or generate a failure response to the STARTTLS command. In
- order to detect such an attack, clients SHOULD warn the user when
- session privacy is not active and/or be configurable to refuse to
- proceed without an acceptable level of security.
-
- A man-in-the-middle attacker can always cause a down-negotiation to
- the weakest authentication mechanism or cipher suite available. For
- this reason, implementations SHOULD be configurable to refuse weak
- mechanisms or cipher suites.
-
- Any protocol interactions prior to the TLS handshake are performed in
- the clear and can be modified by a man-in-the-middle attacker. For
- this reason, clients MUST discard cached information about server
- capabilities advertised prior to the start of the TLS handshake.
-
- Clients are encouraged to clearly indicate when the level of
- encryption active is known to be vulnerable to attack using modern
- hardware (such as encryption keys with 56 bits of entropy or less).
-
- The LOGINDISABLED IMAP capability (discussed in section 3.2) only
- reduces the potential for passive attacks, it provides no protection
- against active attacks. The responsibility remains with the client
- to avoid sending a password over a vulnerable channel.
-
- The PLAIN mechanism relies on the TLS encryption layer for security.
- When used without TLS, it is vulnerable to a common network
- eavesdropping attack. Therefore PLAIN MUST NOT be advertised or used
- unless a suitable TLS encryption layer is active or backwards
- compatibility dictates otherwise.
-
- When the PLAIN mechanism is used, the server gains the ability to
- impersonate the user to all services with the same password
- regardless of any encryption provided by TLS or other network privacy
- mechanisms. While many other authentication mechanisms have similar
- weaknesses, stronger SASL mechanisms such as Kerberos address this
- issue. Clients are encouraged to have an operational mode where all
- mechanisms which are likely to reveal the user's password to the
- server are disabled.
-
-
-
-Newman Standards Track [Page 11]
-
-RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
-
-
- The security considerations for TLS apply to STARTTLS and the
- security considerations for SASL apply to the PLAIN mechanism.
- Additional security requirements are discussed in section 2.
-
-10. References
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [ACAP] Newman, C. and J. Myers, "ACAP -- Application
- Configuration Access Protocol", RFC 2244, November 1997.
-
- [AUTH] Haller, N. and R. Atkinson, "On Internet Authentication",
- RFC 1704, October 1994.
-
- [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
- AUTHorize Extension for Simple Challenge/Response", RFC
- 2195, September 1997.
-
- [IMAP] Crispin, M., "Internet Message Access Protocol - Version
- 4rev1", RFC 2060, December 1996.
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
- "Security Multiparts for MIME: Multipart/Signed and
- Multipart/Encrypted", RFC 1847, October 1995.
-
- [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
- STD 53, RFC 1939, May 1996.
-
- [POP3EXT] Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension
- Mechanism", RFC 2449, November 1998.
-
- [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
- December 1994.
-
- [SASL] Myers, J., "Simple Authentication and Security Layer
- (SASL)", RFC 2222, October 1997.
-
- [SMTPTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over
- TLS", RFC 2487, January 1999.
-
- [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
- RFC 2246, January 1999.
-
-
-
-
-
-Newman Standards Track [Page 12]
-
-RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
-
-
- [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 2279, January 1998.
-
-
-11. Author's Address
-
- Chris Newman
- Innosoft International, Inc.
- 1050 Lakes Drive
- West Covina, CA 91790 USA
-
- EMail: address@hidden
-
-
-A. Appendix -- Compliance Checklist
-
- An implementation is not compliant if it fails to satisfy one or more
- of the MUST requirements for the protocols it implements. An
- implementation that satisfies all the MUST and all the SHOULD
- requirements for its protocols is said to be "unconditionally
- compliant"; one that satisfies all the MUST requirements but not all
- the SHOULD requirements for its protocols is said to be
- "conditionally compliant".
-
- Rules Section
- ----- -------
- Mandatory-to-implement Cipher Suite 2.1
- SHOULD have mode where encryption required 2.2
- server SHOULD have mode where TLS not required 2.2
- MUST be configurable to refuse all clear-text login
- commands or mechanisms 2.3
- server SHOULD be configurable to refuse clear-text
- login commands on entire server and on per-user basis 2.3
- client MUST check server identity 2.4
- client MUST use hostname used to open connection 2.4
- client MUST NOT use hostname from insecure remote lookup 2.4
- client SHOULD support subjectAltName of dNSName type 2.4
- client SHOULD ask for confirmation or terminate on fail 2.4
- MUST check result of STARTTLS for acceptable privacy 2.5
- client MUST NOT issue commands after STARTTLS
- until server response and negotiation done 3.1,4,5.1
- client MUST discard cached information 3.1,4,5.1,9
- client SHOULD re-issue CAPABILITY/CAPA command 3.1,4
- IMAP server with STARTTLS MUST implement LOGINDISABLED 3.2
- IMAP client MUST NOT issue LOGIN if LOGINDISABLED 3.2
- POP server MUST implement POP3 extensions 4
- ACAP server MUST re-issue ACAP greeting 5.1
-
-
-
-
-Newman Standards Track [Page 13]
-
-RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
-
-
- client SHOULD warn when session privacy not active and/or
- refuse to proceed without acceptable security level 9
- SHOULD be configurable to refuse weak mechanisms or
- cipher suites 9
-
- The PLAIN mechanism is an optional part of this specification.
- However if it is implemented the following rules apply:
-
- Rules Section
- ----- -------
- MUST NOT use PLAIN unless strong encryption active
- or backwards compatibility dictates otherwise 6,9
- MUST use UTF-8 encoding for characters in PLAIN 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Newman Standards Track [Page 14]
-
-RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Newman Standards Track [Page 15]
-
diff --git a/doc/rfc/rfc2683.txt b/doc/rfc/rfc2683.txt
deleted file mode 100644
index d92e340..0000000
--- a/doc/rfc/rfc2683.txt
+++ /dev/null
@@ -1,1291 +0,0 @@
-
-
-
-
-
-
-Network Working Group B. Leiba
-Request for Comments: 2683 IBM T.J. Watson Research Center
-Category: Informational September 1999
-
-
- IMAP4 Implementation Recommendations
-
-Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard of any kind. Distribution of this
- memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
-1. Abstract
-
- The IMAP4 specification [RFC-2060] describes a rich protocol for use
- in building clients and servers for storage, retrieval, and
- manipulation of electronic mail. Because the protocol is so rich and
- has so many implementation choices, there are often trade-offs that
- must be made and issues that must be considered when designing such
- clients and servers. This document attempts to outline these issues
- and to make recommendations in order to make the end products as
- interoperable as possible.
-
-2. Conventions used in this document
-
- In examples, "C:" indicates lines sent by a client that is connected
- to a server. "S:" indicates lines sent by the server to the client.
-
- The words "must", "must not", "should", "should not", and "may" are
- used with specific meaning in this document; since their meaning is
- somewhat different from that specified in RFC 2119, we do not put
- them in all caps here. Their meaning is as follows:
-
- must -- This word means that the action described is necessary
- to ensure interoperability. The recommendation should
- not be ignored.
- must not -- This phrase means that the action described will be
- almost certain to hurt interoperability. The
- recommendation should not be ignored.
-
-
-
-
-
-
-
-Leiba Informational [Page 1]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
- should -- This word means that the action described is strongly
- recommended and will enhance interoperability or
- usability. The recommendation should not be ignored
- without careful consideration.
- should not -- This phrase means that the action described is strongly
- recommended against, and might hurt interoperability or
- usability. The recommendation should not be ignored
- without careful consideration.
- may -- This word means that the action described is an
- acceptable implementation choice. No specific
- recommendation is implied; this word is used to point
- out a choice that might not be obvious, or to let
- implementors know what choices have been made by
- existing implementations.
-
-3. Interoperability Issues and Recommendations
-
-3.1. Accessibility
-
- This section describes the issues related to access to servers and
- server resources. Concerns here include data sharing and maintenance
- of client/server connections.
-
-3.1.1. Multiple Accesses of the Same Mailbox
-
- One strong point of IMAP4 is that, unlike POP3, it allows for
- multiple simultaneous access to a single mailbox. A user can, thus,
- read mail from a client at home while the client in the office is
- still connected; or the help desk staff can all work out of the same
- inbox, all seeing the same pool of questions. An important point
- about this capability, though is that NO SERVER IS GUARANTEED TO
- SUPPORT THIS. If you are selecting an IMAP server and this facility
- is important to you, be sure that the server you choose to install,
- in the configuration you choose to use, supports it.
-
- If you are designing a client, you must not assume that you can
- access the same mailbox more than once at a time. That means
-
- 1. you must handle gracefully the failure of a SELECT command if the
- server refuses the second SELECT,
- 2. you must handle reasonably the severing of your connection (see
- "Severed Connections", below) if the server chooses to allow the
- second SELECT by forcing the first off,
- 3. you must avoid making multiple connections to the same mailbox in
- your own client (for load balancing or other such reasons), and
- 4. you must avoid using the STATUS command on a mailbox that you have
- selected (with some server implementations the STATUS command has
- the same problems with multiple access as do the SELECT and
-
-
-
-Leiba Informational [Page 2]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
- EXAMINE commands).
-
- A further note about STATUS: The STATUS command is sometimes used to
- check a non-selected mailbox for new mail. This mechanism must not
- be used to check for new mail in the selected mailbox; section 5.2 of
- [RFC-2060] specifically forbids this in its last paragraph. Further,
- since STATUS takes a mailbox name it is an independent operation, not
- operating on the selected mailbox. Because of this, the information
- it returns is not necessarily in synchronization with the selected
- mailbox state.
-
-3.1.2. Severed Connections
-
- The client/server connection may be severed for one of three reasons:
- the client severs the connection, the server severs the connection,
- or the connection is severed by outside forces beyond the control of
- the client and the server (a telephone line drops, for example).
- Clients and servers must both deal with these situations.
-
- When the client wants to sever a connection, it's usually because it
- has finished the work it needed to do on that connection. The client
- should send a LOGOUT command, wait for the tagged response, and then
- close the socket. But note that, while this is what's intended in
- the protocol design, there isn't universal agreement here. Some
- contend that sending the LOGOUT and waiting for the two responses
- (untagged BYE and tagged OK) is wasteful and unnecessary, and that
- the client can simply close the socket. The server should interpret
- the closed socket as a log out by the client. The counterargument is
- that it's useful from the standpoint of cleanup, problem
- determination, and the like, to have an explicit client log out,
- because otherwise there is no way for the server to tell the
- difference between "closed socket because of log out" and "closed
- socket because communication was disrupted". If there is a
- client/server interaction problem, a client which routinely
- terminates a session by breaking the connection without a LOGOUT will
- make it much more difficult to determine the problem.
-
- Because of this disagreement, server designers must be aware that
- some clients might close the socket without sending a LOGOUT. In any
- case, whether or not a LOGOUT was sent, the server should not
- implicitly expunge any messages from the selected mailbox. If a
- client wants the server to do so, it must send a CLOSE or EXPUNGE
- command explicitly.
-
- When the server wants to sever a connection it's usually due to an
- inactivity timeout or is because a situation has arisen that has
- changed the state of the mail store in a way that the server can not
- communicate to the client. The server should send an untagged BYE
-
-
-
-Leiba Informational [Page 3]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
- response to the client and then close the socket. Sending an
- untagged BYE response before severing allows the server to send a
- human-readable explanation of the problem to the client, which the
- client may then log, display to the user, or both (see section 7.1.5
- of [RFC-2060]).
-
- Regarding inactivity timeouts, there is some controversy. Unlike
- POP, for which the design is for a client to connect, retrieve mail,
- and log out, IMAP's design encourages long-lived (and mostly
- inactive) client/server sessions. As the number of users grows, this
- can use up a lot of server resources, especially with clients that
- are designed to maintain sessions for mailboxes that the user has
- finished accessing. To alleviate this, a server may implement an
- inactivity timeout, unilaterally closing a session (after first
- sending an untagged BYE, as noted above). Some server operators have
- reported dramatic improvements in server performance after doing
- this. As specified in [RFC-2060], if such a timeout is done it must
- not be until at least 30 minutes of inactivity. The reason for this
- specification is to prevent clients from sending commands (such as
- NOOP) to the server at frequent intervals simply to avert a too-early
- timeout. If the client knows that the server may not time out the
- session for at least 30 minutes, then the client need not poll at
- intervals more frequent than, say, 25 minutes.
-
-3.2. Scaling
-
- IMAP4 has many features that allow for scalability, as mail stores
- become larger and more numerous. Large numbers of users, mailboxes,
- and messages, and very large messages require thought to handle
- efficiently. This document will not address the administrative
- issues involved in large numbers of users, but we will look at the
- other items.
-
-3.2.1. Flood Control
-
- There are three situations when a client can make a request that will
- result in a very large response - too large for the client reasonably
- to deal with: there are a great many mailboxes available, there are a
- great many messages in the selected mailbox, or there is a very large
- message part. The danger here is that the end user will be stuck
- waiting while the server sends (and the client processes) an enormous
- response. In all of these cases there are things a client can do to
- reduce that danger.
-
- There is also the case where a client can flood a server, by sending
- an arbitratily long command. We'll discuss that issue, too, in this
- section.
-
-
-
-
-Leiba Informational [Page 4]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
-3.2.1.1. Listing Mailboxes
-
- Some servers present Usenet newsgroups to IMAP users. Newsgroups,
- and other such hierarchical mailbox structures, can be very numerous
- but may have only a few entries at the top level of hierarchy. Also,
- some servers are built against mail stores that can, unbeknownst to
- the server, have circular hierarchies - that is, it's possible for
- "a/b/c/d" to resolve to the same file structure as "a", which would
- then mean that "a/b/c/d/b" is the same as "a/b", and the hierarchy
- will never end. The LIST response in this case will be unlimited.
-
- Clients that will have trouble with this are those that use
-
- C: 001 LIST "" *
-
- to determine the mailbox list. Because of this, clients should not
- use an unqualified "*" that way in the LIST command. A safer
- approach is to list each level of hierarchy individually, allowing
- the user to traverse the tree one limb at a time, thus:
-
- C: 001 LIST "" %
- S: * LIST () "/" Banana
- S: * LIST ...etc...
- S: 001 OK done
-
- and then
-
- C: 002 LIST "" Banana/%
- S: * LIST () "/" Banana/Apple
- S: * LIST ...etc...
- S: 002 OK done
-
- Using this technique the client's user interface can give the user
- full flexibility without choking on the voluminous reply to "LIST *".
-
- Of course, it is still possible that the reply to
-
- C: 005 LIST "" alt.fan.celebrity.%
-
- may be thousands of entries long, and there is, unfortunately,
- nothing the client can do to protect itself from that. This has not
- yet been a notable problem.
-
- Servers that may export circular hierarchies (any server that
- directly presents a UNIX file system, for instance) should limit the
- hierarchy depth to prevent unlimited LIST responses. A suggested
- depth limit is 20 hierarchy levels.
-
-
-
-
-Leiba Informational [Page 5]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
-3.2.1.2. Fetching the List of Messages
-
- When a client selects a mailbox, it is given a count, in the untagged
- EXISTS response, of the messages in the mailbox. This number can be
- very large. In such a case it might be unwise to use
-
- C: 004 FETCH 1:* ALL
-
- to populate the user's view of the mailbox. One good method to avoid
- problems with this is to batch the requests, thus:
-
- C: 004 FETCH 1:50 ALL
- S: * 1 FETCH ...etc...
- S: 004 OK done
- C: 005 FETCH 51:100 ALL
- S: * 51 FETCH ...etc...
- S: 005 OK done
- C: 006 FETCH 101:150 ALL
- ...etc...
-
- Using this method, another command, such as "FETCH 6 BODY[1]" can be
- inserted as necessary, and the client will not have its access to the
- server blocked by a storm of FETCH replies. (Such a method could be
- reversed to fetch the LAST 50 messages first, then the 50 prior to
- that, and so on.)
-
- As a smart extension of this, a well designed client, prepared for
- very large mailboxes, will not automatically fetch data for all
- messages AT ALL. Rather, the client will populate the user's view
- only as the user sees it, possibly pre-fetching selected information,
- and only fetching other information as the user scrolls to it. For
- example, to select only those messages beginning with the first
- unseen one:
-
- C: 003 SELECT INBOX
- S: * 10000 EXISTS
- S: * 80 RECENT
- S: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
- S: * OK [UIDVALIDITY 824708485] UID validity status
- S: * OK [UNSEEN 9921] First unseen message
- S: 003 OK [READ-WRITE] SELECT completed
- C: 004 FETCH 9921:* ALL
- ... etc...
-
- If the server does not return an OK [UNSEEN] response, the client may
- use SEARCH UNSEEN to obtain that value.
-
-
-
-
-
-Leiba Informational [Page 6]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
- This mechanism is good as a default presentation method, but only
- works well if the default message order is acceptable. A client may
- want to present various sort orders to the user (by subject, by date
- sent, by sender, and so on) and in that case (lacking a SORT
- extension on the server side) the client WILL have to retrieve all
- message descriptors. A client that provides this service should not
- do it by default and should inform the user of the costs of choosing
- this option for large mailboxes.
-
-3.2.1.3. Fetching a Large Body Part
-
- The issue here is similar to the one for a list of messages. In the
- BODYSTRUCTURE response the client knows the size, in bytes, of the
- body part it plans to fetch. Suppose this is a 70 MB video clip. The
- client can use partial fetches to retrieve the body part in pieces,
- avoiding the problem of an uninterruptible 70 MB literal coming back
- from the server:
-
- C: 022 FETCH 3 BODY[1]<0.20000>
- S: * 3 FETCH (FLAGS(\Seen) BODY[1]<0> {20000}
- S: ...data...)
- S: 022 OK done
- C: 023 FETCH 3 BODY[1]<20001.20000>
- S: * 3 FETCH (BODY[1]<20001> {20000}
- S: ...data...)
- S: 023 OK done
- C: 024 FETCH 3 BODY[1]<40001.20000>
- ...etc...
-
-3.2.1.4. BODYSTRUCTURE vs. Entire Messages
-
- Because FETCH BODYSTRUCTURE is necessary in order to determine the
- number of body parts, and, thus, whether a message has "attachments",
- clients often use FETCH FULL as their normal method of populating the
- user's view of a mailbox. The benefit is that the client can display
- a paperclip icon or some such indication along with the normal
- message summary. However, this comes at a significant cost with some
- server configurations. The parsing needed to generate the FETCH
- BODYSTRUCTURE response may be time-consuming compared with that
- needed for FETCH ENVELOPE. The client developer should consider this
- issue when deciding whether the ability to add a paperclip icon is
- worth the tradeoff in performance, especially with large mailboxes.
-
- Some clients, rather than using FETCH BODYSTRUCTURE, use FETCH BODY[]
- (or the equivalent FETCH RFC822) to retrieve the entire message.
- They then do the MIME parsing in the client. This may give the
- client slightly more flexibility in some areas (access, for instance,
- to header fields that aren't returned in the BODYSTRUCTURE and
-
-
-
-Leiba Informational [Page 7]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
- ENVELOPE responses), but it can cause severe performance problems by
- forcing the transfer of all body parts when the user might only want
- to see some of them - a user logged on by modem and reading a small
- text message with a large ZIP file attached may prefer to read the
- text only and save the ZIP file for later. Therefore, a client
- should not normally retrieve entire messages and should retrieve
- message body parts selectively.
-
-3.2.1.5. Long Command Lines
-
- A client can wind up building a very long command line in an effort to
- try to be efficient about requesting information from a server. This
- can typically happen when a client builds a message set from selected
- messages and doesn't recognise that contiguous blocks of messages may
- be group in a range. Suppose a user selects all 10,000 messages in a
- large mailbox and then unselects message 287. The client could build
- that message set as "1:286,288:10000", but a client that doesn't
- handle that might try to enumerate each message individually and build
- "1,2,3,4, [and so on] ,9999,10000". Adding that to the fetch command
- results in a command line that's almost 49,000 octets long, and,
- clearly, one can construct a command line that's even longer.
-
- A client should limit the length of the command lines it generates to
- approximately 1000 octets (including all quoted strings but not
- including literals). If the client is unable to group things into
- ranges so that the command line is within that length, it should
- split the request into multiple commands. The client should use
- literals instead of long quoted strings, in order to keep the command
- length down.
-
- For its part, a server should allow for a command line of at least
- 8000 octets. This provides plenty of leeway for accepting reasonable
- length commands from clients. The server should send a BAD response
- to a command that does not end within the server's maximum accepted
- command length.
-
-3.2.2. Subscriptions
-
- The client isn't the only entity that can get flooded: the end user,
- too, may need some flood control. The IMAP4 protocol provides such
- control in the form of subscriptions. Most servers support the
- SUBSCRIBE, UNSUBSCRIBE, and LSUB commands, and many users choose to
- narrow down a large list of available mailboxes by subscribing to the
- ones that they usually want to see. Clients, with this in mind,
- should give the user a way to see only subscribed mailboxes. A
- client that never uses the LSUB command takes a significant usability
- feature away from the user. Of course, the client would not want to
- hide the LIST command completely; the user needs to have a way to
-
-
-
-Leiba Informational [Page 8]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
- choose between LIST and LSUB. The usual way to do this is to provide
- a setting like "show which mailboxes?: [] all [] subscribed only".
-
-3.2.3. Searching
-
- IMAP SEARCH commands can become particularly troublesome (that is,
- slow) on mailboxes containing a large number of messages. So let's
- put a few things in perspective in that regard.
-
- The flag searches should be fast. The flag searches (ALL, [UN]SEEN,
- [UN]ANSWERED, [UN]DELETED, [UN]DRAFT, [UN]FLAGGED, NEW, OLD, RECENT)
- are known to be used by clients for the client's own use (for
- instance, some clients use "SEARCH UNSEEN" to find unseen mail and
- "SEARCH DELETED" to warn the user before expunging messages).
-
- Other searches, particularly the text searches (HEADER, TEXT, BODY)
- are initiated by the user, rather than by the client itself, and
- somewhat slower performance can be tolerated, since the user is aware
- that the search is being done (and is probably aware that it might be
- time-consuming). A smart server might use dynamic indexing to speed
- commonly used text searches.
-
- The client may allow other commands to be sent to the server while a
- SEARCH is in progress, but at the time of this writing there is
- little or no server support for parallel processing of multiple
- commands in the same session (and see "Multiple Accesses of the Same
- Mailbox" above for a description of the dangers of trying to work
- around this by doing your SEARCH in another session).
-
- Another word about text searches: some servers, built on database
- back-ends with indexed search capabilities, may return search results
- that do not match the IMAP spec's "case-insensitive substring"
- requirements. While these servers are in violation of the protocol,
- there is little harm in the violation as long as the search results
- are used only in response to a user's request. Still, developers of
- such servers should be aware that they ARE violating the protocol,
- should think carefully about that behaviour, and must be certain that
- their servers respond accurately to the flag searches for the reasons
- outlined above.
-
- In addition, servers should support CHARSET UTF-8 [UTF-8] in
- searches.
-
-
-
-
-
-
-
-
-
-Leiba Informational [Page 9]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
-3.3 Avoiding Invalid Requests
-
- IMAP4 provides ways for a server to tell a client in advance what is
- and isn't permitted in some circumstances. Clients should use these
- features to avoid sending requests that a well designed client would
- know to be invalid. This section explains this in more detail.
-
-3.3.1. The CAPABILITY Command
-
- All IMAP4 clients should use the CAPABILITY command to determine what
- version of IMAP and what optional features a server supports. The
- client should not send IMAP4rev1 commands and arguments to a server
- that does not advertize IMAP4rev1 in its CAPABILITY response.
- Similarly, the client should not send IMAP4 commands that no longer
- exist in IMAP4rev1 to a server that does not advertize IMAP4 in its
- CAPABILITY response. An IMAP4rev1 server is NOT required to support
- obsolete IMAP4 or IMAP2bis commands (though some do; do not let this
- fact lull you into thinking that it's valid to send such commands to
- an IMAP4rev1 server).
-
- A client should not send commands to probe for the existance of
- certain extensions. All standard and standards-track extensions
- include CAPABILITY tokens indicating their presense. All private and
- experimental extensions should do the same, and clients that take
- advantage of them should use the CAPABILITY response to determine
- whether they may be used or not.
-
-3.3.2. Don't Do What the Server Says You Can't
-
- In many cases, the server, in response to a command, will tell the
- client something about what can and can't be done with a particular
- mailbox. The client should pay attention to this information and
- should not try to do things that it's been told it can't do.
-
- Examples:
-
- * Do not try to SELECT a mailbox that has the \Noselect flag set.
- * Do not try to CREATE a sub-mailbox in a mailbox that has the
- \Noinferiors flag set.
- * Do not respond to a failing COPY or APPEND command by trying to
- CREATE the target mailbox if the server does not respond with a
- [TRYCREATE] response code.
- * Do not try to expunge a mailbox that has been selected with the
- [READ-ONLY] response code.
-
-
-
-
-
-
-
-Leiba Informational [Page 10]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
-3.4. Miscellaneous Protocol Considerations
-
- We describe here a number of important protocol-related issues, the
- misunderstanding of which has caused significant interoperability
- problems in IMAP4 implementations. One general item is that every
- implementer should be certain to take note of and to understand
- section 2.2.2 and the preamble to section 7 of the IMAP4rev1 spec
- [RFC-2060].
-
-3.4.1. Well Formed Protocol
-
- We cannot stress enough the importance of adhering strictly to the
- protocol grammar. The specification of the protocol is quite rigid;
- do not assume that you can insert blank space for "readability" if
- none is called for. Keep in mind that there are parsers out there
- that will crash if there are protocol errors. There are clients that
- will report every parser burp to the user. And in any case,
- information that cannot be parsed is information that is lost. Be
- careful in your protocol generation. And see "A Word About Testing",
- below.
-
- In particular, note that the string in the INTERNALDATE response is
- NOT an RFC-822 date string - that is, it is not in the same format as
- the first string in the ENVELOPE response. Since most clients will,
- in fact, accept an RFC-822 date string in the INTERNALDATE response,
- it's easy to miss this in your interoperability testing. But it will
- cause a problem with some client, so be sure to generate the correct
- string for this field.
-
-3.4.2. Special Characters
-
- Certain characters, currently the double-quote and the backslash, may
- not be sent as-is inside a quoted string. These characters must be
- preceded by the escape character if they are in a quoted string, or
- else the string must be sent as a literal. Both clients and servers
- must handle this, both on output (they must send these characters
- properly) and on input (they must be able to receive escaped
- characters in quoted strings). Example:
-
- C: 001 LIST "" %
- S: * LIST () "" INBOX
- S: * LIST () "\\" TEST
- S: * LIST () "\\" {12}
- S: "My" mailbox
- S: 001 OK done
- C: 002 LIST "" "\"My\" mailbox\\%"
- S: * LIST () "\\" {17}
- S: "My" mailbox\Junk
-
-
-
-Leiba Informational [Page 11]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
- S: 002 OK done
-
- Note that in the example the server sent the hierarchy delimiter as
- an escaped character in the quoted string and sent the mailbox name
- containing imbedded double-quotes as a literal. The client used only
- quoted strings, escaping both the backslash and the double-quote
- characters.
-
- The CR and LF characters may be sent ONLY in literals; they are not
- allowed, even if escaped, inside quoted strings.
-
- And while we're talking about special characters: the IMAP spec, in
- the section titled "Mailbox International Naming Convention",
- describes how to encode mailbox names in modified UTF-7 [UTF-7 and
- RFC-2060]. Implementations must adhere to this in order to be
- interoperable in the international market, and servers should
- validate mailbox names sent by client and reject names that do not
- conform.
-
- As to special characters in userids and passwords: clients must not
- restrict what a user may type in for a userid or a password. The
- formal grammar specifies that these are "astrings", and an astring
- can be a literal. A literal, in turn can contain any 8-bit
- character, and clients must allow users to enter all 8-bit characters
- here, and must pass them, unchanged, to the server (being careful to
- send them as literals when necessary). In particular, some server
- configurations use "@" in user names, and some clients do not allow
- that character to be entered; this creates a severe interoperability
- problem.
-
-3.4.3. UIDs and UIDVALIDITY
-
- Servers that support existing back-end mail stores often have no good
- place to save UIDs for messages. Often the existing mail store will
- not have the concept of UIDs in the sense that IMAP has: strictly
- increasing, never re-issued, 32-bit integers. Some servers solve
- this by storing the UIDs in a place that's accessible to end users,
- allowing for the possibility that the users will delete them. Others
- solve it by re-assigning UIDs every time a mailbox is selected.
-
- The server should maintain UIDs permanently for all messages if it
- can. If that's not possible, the server must change the UIDVALIDITY
- value for the mailbox whenever any of the UIDs may have become
- invalid. Clients must recognize that the UIDVALIDITY has changed and
- must respond to that condition by throwing away any information that
- they have saved about UIDs in that mailbox. There have been many
- problems in this area when clients have failed to do this; in the
- worst case it will result in loss of mail when a client deletes the
-
-
-
-Leiba Informational [Page 12]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
- wrong piece of mail by using a stale UID.
-
- It seems to be a common misunderstanding that "the UIDVALIDITY and
- the UID, taken together, form a 64-bit identifier that uniquely
- identifies a message on a server". This is absolutely NOT TRUE.
- There is no assurance that the UIDVALIDITY values of two mailboxes be
- different, so the UIDVALIDITY in no way identifies a mailbox. The
- ONLY purpose of UIDVALIDITY is, as its name indicates, to give the
- client a way to check the validity of the UIDs it has cached. While
- it is a valid implementation choice to put these values together to
- make a 64-bit identifier for the message, the important concept here
- is that UIDs are not unique between mailboxes; they are only unique
- WITHIN a given mailbox.
-
- Some server implementations have attempted to make UIDs unique across
- the entire server. This is inadvisable, in that it limits the life
- of UIDs unnecessarily. The UID is a 32-bit number and will run out
- in reasonably finite time if it's global across the server. If you
- assign UIDs sequentially in one mailbox, you will not have to start
- re-using them until you have had, at one time or another, 2**32
- different messages in that mailbox. In the global case, you will
- have to reuse them once you have had, at one time or another, 2**32
- different messages in the entire mail store. Suppose your server has
- around 8000 users registered (2**13). That gives an average of 2**19
- UIDs per user. Suppose each user gets 32 messages (2**5) per day.
- That gives you 2**14 days (16000+ days = about 45 years) before you
- run out. That may seem like enough, but multiply the usage just a
- little (a lot of spam, a lot of mailing list subscriptions, more
- users) and you limit yourself too much.
-
- What's worse is that if you have to wrap the UIDs, and, thus, you
- have to change UIDVALIDITY and invalidate the UIDs in the mailbox,
- you have to do it for EVERY mailbox in the system, since they all
- share the same UID pool. If you assign UIDs per mailbox and you have
- a problem, you only have to kill the UIDs for that one mailbox.
-
- Under extreme circumstances (and this is extreme, indeed), the server
- may have to invalidate UIDs while a mailbox is in use by a client -
- that is, the UIDs that the client knows about in its active mailbox
- are no longer valid. In that case, the server must immediately
- change the UIDVALIDITY and must communicate this to the client. The
- server may do this by sending an unsolicited UIDVALIDITY message, in
- the same form as in response to the SELECT command. Clients must be
- prepared to handle such a message and the possibly coincident failure
- of the command in process. For example:
-
-
-
-
-
-
-Leiba Informational [Page 13]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
- C: 032 UID STORE 382 +Flags.silent \Deleted
- S: * OK [UIDVALIDITY 12345] New UIDVALIDITY value!
- S: 032 NO UID command rejected because UIDVALIDITY changed!
- C: ...invalidates local information and re-fetches...
- C: 033 FETCH 1:* UID
- ...etc...
-
- At the time of the writing of this document, the only server known to
- do this does so only under the following condition: the client
- selects INBOX, but there is not yet a physical INBOX file created.
- Nonetheless, the SELECT succeeds, exporting an empty INBOX with a
- temporary UIDVALIDITY of 1. While the INBOX remains selected, mail
- is delivered to the user, which creates the real INBOX file and
- assigns a permanent UIDVALIDITY (that is likely not to be 1). The
- server reports the change of UIDVALIDITY, but as there were no
- messages before, so no UIDs have actually changed, all the client
- must do is accept the change in UIDVALIDITY.
-
- Alternatively, a server may force the client to re-select the
- mailbox, at which time it will obtain a new UIDVALIDITY value. To do
- this, the server closes this client session (see "Severed
- Connections" above) and the client then reconnects and gets back in
- synch. Clients must be prepared for either of these behaviours.
-
- We do not know of, nor do we anticipate the future existance of, a
- server that changes UIDVALIDITY while there are existing messages,
- but clients must be prepared to handle this eventuality.
-
-3.4.4. FETCH Responses
-
- When a client asks for certain information in a FETCH command, the
- server may return the requested information in any order, not
- necessarily in the order that it was requested. Further, the server
- may return the information in separate FETCH responses and may also
- return information that was not explicitly requested (to reflect to
- the client changes in the state of the subject message). Some
- examples:
-
- C: 001 FETCH 1 UID FLAGS INTERNALDATE
- S: * 5 FETCH (FLAGS (\Deleted))
- S: * 1 FETCH (FLAGS (\Seen) INTERNALDATE "..." UID 345)
- S: 001 OK done
-
- (In this case, the responses are in a different order. Also, the
- server returned a flag update for message 5, which wasn't part of the
- client's request.)
-
-
-
-
-
-Leiba Informational [Page 14]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
- C: 002 FETCH 2 UID FLAGS INTERNALDATE
- S: * 2 FETCH (INTERNALDATE "...")
- S: * 2 FETCH (UID 399)
- S: * 2 FETCH (FLAGS ())
- S: 002 OK done
-
- (In this case, the responses are in a different order and were
- returned in separate responses.)
-
- C: 003 FETCH 2 BODY[1]
- S: * 2 FETCH (FLAGS (\Seen) BODY[1] {14}
- S: Hello world!
- S: )
- S: 003 OK done
-
- (In this case, the FLAGS response was added by the server, since
- fetching the body part caused the server to set the \Seen flag.)
-
- Because of this characteristic a client must be ready to receive any
- FETCH response at any time and should use that information to update
- its local information about the message to which the FETCH response
- refers. A client must not assume that any FETCH responses will come
- in any particular order, or even that any will come at all. If after
- receiving the tagged response for a FETCH command the client finds
- that it did not get all of the information requested, the client
- should send a NOOP command to the server to ensure that the server
- has an opportunity to send any pending EXPUNGE responses to the
- client (see [RFC-2180]).
-
-3.4.5. RFC822.SIZE
-
- Some back-end mail stores keep the mail in a canonical form, rather
- than retaining the original MIME format of the messages. This means
- that the server must reassemble the message to produce a MIME stream
- when a client does a fetch such as RFC822 or BODY[], requesting the
- entire message. It also may mean that the server has no convenient
- way to know the RFC822.SIZE of the message. Often, such a server
- will actually have to build the MIME stream to compute the size, only
- to throw the stream away and report the size to the client.
-
- When this is the case, some servers have chosen to estimate the size,
- rather than to compute it precisely. Such an estimate allows the
- client to display an approximate size to the user and to use the
- estimate in flood control considerations (q.v.), but requires that
- the client not use the size for things such as allocation of buffers,
- because those buffers might then be too small to hold the actual MIME
- stream. Instead, a client should use the size that's returned in the
- literal when you fetch the data.
-
-
-
-Leiba Informational [Page 15]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
- The protocol requires that the RFC822.SIZE value returned by the
- server be EXACT. Estimating the size is a protocol violation, and
- server designers must be aware that, despite the performance savings
- they might realize in using an estimate, this practice will cause
- some clients to fail in various ways. If possible, the server should
- compute the RFC822.SIZE for a particular message once, and then save
- it for later retrieval. If that's not possible, the server must
- compute the value exactly every time. Incorrect estimates do cause
- severe interoperability problems with some clients.
-
-3.4.6. Expunged Messages
-
- If the server allows multiple connections to the same mailbox, it is
- often possible for messages to be expunged in one client unbeknownst
- to another client. Since the server is not allowed to tell the
- client about these expunged messages in response to a FETCH command,
- the server may have to deal with the issue of how to return
- information about an expunged message. There was extensive
- discussion about this issue, and the results of that discussion are
- summarized in [RFC-2180]. See that reference for a detailed
- explanation and for recommendations.
-
-3.4.7. The Namespace Issue
-
- Namespaces are a very muddy area in IMAP4 implementation right now
- (see [NAMESPACE] for a proposal to clear the water a bit). Until the
- issue is resolved, the important thing for client developers to
- understand is that some servers provide access through IMAP to more
- than just the user's personal mailboxes, and, in fact, the user's
- personal mailboxes may be "hidden" somewhere in the user's default
- hierarchy. The client, therefore, should provide a setting wherein
- the user can specify a prefix to be used when accessing mailboxes. If
- the user's mailboxes are all in "~/mail/", for instance, then the
- user can put that string in the prefix. The client would then put
- the prefix in front of any name pattern in the LIST and LSUB
- commands:
-
- C: 001 LIST "" ~/mail/%
-
- (See also "Reference Names in the LIST Command" below.)
-
-3.4.8. Creating Special-Use Mailboxes
-
- It may seem at first that this is part of the namespace issue; it is
- not, and is only indirectly related to it. A number of clients like
- to create special-use mailboxes with particular names. Most
- commonly, clients with a "trash folder" model of message deletion
- want to create a mailbox with the name "Trash" or "Deleted". Some
-
-
-
-Leiba Informational [Page 16]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
- clients want to create a "Drafts" mailbox, an "Outbox" mailbox, or a
- "Sent Mail" mailbox. And so on. There are two major
- interoperability problems with this practice:
-
- 1. different clients may use different names for mailboxes with
- similar functions (such as "Trash" and "Deleted"), or may manage
- the same mailboxes in different ways, causing problems if a user
- switches between clients and
- 2. there is no guarantee that the server will allow the creation of
- the desired mailbox.
-
- The client developer is, therefore, well advised to consider
- carefully the creation of any special-use mailboxes on the server,
- and, further, the client must not require such mailbox creation -
- that is, if you do decide to do this, you must handle gracefully the
- failure of the CREATE command and behave reasonably when your
- special-use mailboxes do not exist and can not be created.
-
- In addition, the client developer should provide a convenient way for
- the user to select the names for any special-use mailboxes, allowing
- the user to make these names the same in all clients used and to put
- them where the user wants them.
-
-3.4.9. Reference Names in the LIST Command
-
- Many implementers of both clients and servers are confused by the
- "reference name" on the LIST command. The reference name is intended
- to be used in much the way a "cd" (change directory) command is used
- on Unix, PC DOS, Windows, and OS/2 systems. That is, the mailbox
- name is interpreted in much the same way as a file of that name would
- be found if one had done a "cd" command into the directory specified
- by the reference name. For example, in Unix we have the following:
-
- > cd /u/jones/junk
- > vi banana [file is "/u/jones/junk/banana"]
- > vi stuff/banana [file is "/u/jones/junk/stuff/banana"]
- > vi /etc/hosts [file is "/etc/hosts"]
-
- In the past, there have been several interoperability problems with
- this. First, while some IMAP servers are built on Unix or PC file
- systems, many others are not, and the file system semantics do not
- make sense in those configurations. Second, while some IMAP servers
- expose the underlying file system to the clients, others allow access
- only to the user's personal mailboxes, or to some other limited set
- of files, making such file-system-like semantics less meaningful.
- Third, because the IMAP spec leaves the interpretation of the
- reference name as "implementation-dependent", in the past the various
- server implementations handled it in vastly differing ways.
-
-
-
-Leiba Informational [Page 17]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
- The following recommendations are the result of significant
- operational experience, and are intended to maximize
- interoperability.
-
- Server implementations must implement the reference argument in a way
- that matches the intended "change directory" operation as closely as
- possible. As a minimum implementation, the reference argument may be
- prepended to the mailbox name (while suppressing double delimiters;
- see the next paragraph). Even servers that do not provide a way to
- break out of the current hierarchy (see "breakout facility" below)
- must provide a reasonable implementation of the reference argument,
- as described here, so that they will interoperate with clients that
- use it.
-
- Server implementations that prepend the reference argument to the
- mailbox name should insert a hierarchy delimiter between them, and
- must not insert a second if one is already present:
-
- C: A001 LIST ABC DEF
- S: * LIST () "/" ABC/DEF <=== should do this
- S: A001 OK done
-
- C: A002 LIST ABC/ /DEF
- S: * LIST () "/" ABC//DEF <=== must not do this
- S: A002 OK done
-
- On clients, the reference argument is chiefly used to implement a
- "breakout facility", wherein the user may directly access a mailbox
- outside the "current directory" hierarchy. Client implementations
- should have an operational mode that does not use the reference
- argument. This is to interoperate with older servers that did not
- implement the reference argument properly. While it's a good idea to
- give the user access to a breakout facility, clients that do not
- intend to do so should not use the reference argument at all.
-
- Client implementations should always place a trailing hierarchy
- delimiter on the reference argument. This is because some servers
- prepend the reference argument to the mailbox name without inserting
- a hierarchy delimiter, while others do insert a hierarchy delimiter
- if one is not already present. A client that puts the delimiter in
- will work with both varieties of server.
-
- Client implementations that implement a breakout facility should
- allow the user to choose whether or not to use a leading hierarchy
- delimiter on the mailbox argument. This is because the handling of a
- leading mailbox hierarchy delimiter also varies from server to
- server, and even between different mailstores on the same server. In
- some cases, a leading hierarchy delimiter means "discard the
-
-
-
-Leiba Informational [Page 18]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
- reference argument" (implementing the intended breakout facility),
- thus:
-
- C: A001 LIST ABC/ /DEF
- S: * LIST () "/" /DEF
- S: A001 OK done
-
- In other cases, however, the two are catenated and the extra
- hierarchy delimiter is discarded, thus:
-
- C: A001 LIST ABC/ /DEF
- S: * LIST () "/" ABC/DEF
- S: A001 OK done
-
- Client implementations must not assume that the server supports a
- breakout facility, but may provide a way for the user to use one if
- it is available. Any breakout facility should be exported to the
- user interface. Note that there may be other "breakout" characters
- besides the hierarchy delimiter (for instance, UNIX filesystem
- servers are likely to use a leading "~" as well), and that their
- interpretation is server-dependent.
-
-3.4.10. Mailbox Hierarchy Delimiters
-
- The server's selection of what to use as a mailbox hierarchy
- delimiter is a difficult one, involving several issues: What
- characters do users expect to see? What characters can they enter
- for a hierarchy delimiter if it is desired (or required) that the
- user enter it? What character can be used for the hierarchy
- delimiter, noting that the chosen character can not otherwise be used
- in the mailbox name?
-
- Because some interfaces show users the hierarchy delimiters or allow
- users to enter qualified mailbox names containing them, server
- implementations should use delimiter characters that users generally
- expect to see as name separators. The most common characters used
- for this are "/" (as in Unix file names), "\" (as in OS/2 and Windows
- file names), and "." (as in news groups). There is little to choose
- among these apart from what users may expect or what is dictated by
- the underlying file system, if any. One consideration about using
- "\" is that it's also a special character in the IMAP protocol. While
- the use of other hierarchy delimiter characters is permissible, A
- DESIGNER IS WELL ADVISED TO STAY WITH ONE FROM THIS SET unless the
- server is intended for special purposes only. Implementers might be
- thinking about using characters such as "-", "_", ";", "&", "#", "@",
- and "!", but they should be aware of the surprise to the user as well
- as of the effect on URLs and other external specifications (since
- some of these characters have special meanings there). Also, a
-
-
-
-Leiba Informational [Page 19]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
- server that uses "\" (and clients of such a server) must remember to
- escape that character in quoted strings or to send literals instead.
- Literals are recommended over escaped characters in quoted strings in
- order to maintain compatibility with older IMAP versions that did not
- allow escaped characters in quoted strings (but check the grammar to
- see where literals are allowed):
-
- C: 001 LIST "" {13}
- S: + send literal
- C: this\%\%\%\h*
- S: * LIST () "\\" {27}
- S: this\is\a\mailbox\hierarchy
- S: 001 OK LIST complete
-
- In any case, a server should not use normal alpha-numeric characters
- (such as "X" or "0") as delimiters; a user would be very surprised to
- find that "EXPENDITURES" actually represented a two-level hierarchy.
- And a server should not use characters that are non-printable or
- difficult or impossible to enter on a standard US keyboard. Control
- characters, box-drawing characters, and characters from non-US
- alphabets fit into this category. Their use presents
- interoperability problems that are best avoided.
-
- The UTF-7 encoding of mailbox names also raises questions about what
- to do with the hierarchy delimiters in encoded names: do we encode
- each hierarchy level and separate them with delimiters, or do we
- encode the fully qualified name, delimiters and all? The answer for
- IMAP is the former: encode each hierarchy level separately, and
- insert delimiters between. This makes it particularly important not
- to use as a hierarchy delimiter a character that might cause
- confusion with IMAP's modified UTF-7 [UTF-7 and RFC-2060] encoding.
-
- To repeat: a server should use "/", "\", or "." as its hierarchy
- delimiter. The use of any other character is likely to cause
- problems and is STRONGLY DISCOURAGED.
-
-3.4.11. ALERT Response Codes
-
- The protocol spec is very clear on the matter of what to do with
- ALERT response codes, and yet there are many clients that violate it
- so it needs to be said anyway: "The human-readable text contains a
- special alert that must be presented to the user in a fashion that
- calls the user's attention to the message." That should be clear
- enough, but I'll repeat it here: Clients must present ALERT text
- clearly to the user.
-
-
-
-
-
-
-Leiba Informational [Page 20]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
-3.4.12. Deleting Mailboxes
-
- The protocol does not guarantee that a client may delete a mailbox
- that is not empty, though on some servers it is permissible and is,
- in fact, much faster than the alternative or deleting all the
- messages from the client. If the client chooses to try to take
- advantage of this possibility it must be prepared to use the other
- method in the even that the more convenient one fails. Further, a
- client should not try to delete the mailbox that it has selected, but
- should first close that mailbox; some servers do not permit the
- deletion of the selected mailbox.
-
- That said, a server should permit the deletion of a non-empty
- mailbox; there's little reason to pass this work on to the client.
- Moreover, forbidding this prevents the deletion of a mailbox that for
- some reason can not be opened or expunged, leading to possible
- denial-of-service problems.
-
- Example:
-
- [User tells the client to delete mailbox BANANA, which is
- currently selected...]
- C: 008 CLOSE
- S: 008 OK done
- C: 009 DELETE BANANA
- S: 009 NO Delete failed; mailbox is not empty.
- C: 010 SELECT BANANA
- S: * ... untagged SELECT responses
- S: 010 OK done
- C: 011 STORE 1:* +FLAGS.SILENT \DELETED
- S: 011 OK done
- C: 012 CLOSE
- S: 012 OK done
- C: 013 DELETE BANANA
- S: 013 OK done
-
-3.5. A Word About Testing
-
- Since the whole point of IMAP is interoperability, and since
- interoperability can not be tested in a vacuum, the final
- recommendation of this treatise is, "Test against EVERYTHING." Test
- your client against every server you can get an account on. Test
- your server with every client you can get your hands on. Many
- clients make limited test versions available on the Web for the
- downloading. Many server owners will give serious client developers
- guest accounts for testing. Contact them and ask. NEVER assume that
- because your client works with one or two servers, or because your
- server does fine with one or two clients, you will interoperate well
-
-
-
-Leiba Informational [Page 21]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
- in general.
-
- In particular, in addition to everything else, be sure to test
- against the reference implementations: the PINE client, the
- University of Washington server, and the Cyrus server.
-
- See the following URLs on the web for more information here:
-
- IMAP Products and Sources: http://www.imap.org/products.html
- IMC MailConnect: http://www.imc.org/imc-mailconnect
-
-4. Security Considerations
-
- This document describes behaviour of clients and servers that use the
- IMAP4 protocol, and as such, has the same security considerations as
- described in [RFC-2060].
-
-5. References
-
- [RFC-2060] Crispin, M., "Internet Message Access Protocol - Version
- 4rev1", RFC 2060, December 1996.
-
- [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC
- 2180, July 1997.
-
- [UTF-8] Yergeau, F., " UTF-8, a transformation format of Unicode
- and ISO 10646", RFC 2044, October 1996.
-
- [UTF-7] Goldsmith, D. and M. Davis, "UTF-7, a Mail-Safe
- Transformation Format of Unicode", RFC 2152, May 1997.
-
- [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", Work in
- Progress.
-
-6. Author's Address
-
- Barry Leiba
- IBM T.J. Watson Research Center
- 30 Saw Mill River Road
- Hawthorne, NY 10532
-
- Phone: 1-914-784-7941
- EMail: address@hidden
-
-
-
-
-
-Leiba Informational [Page 22]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
-7. Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Leiba Informational [Page 23]
-
diff --git a/doc/rfc/rfc2808.txt b/doc/rfc/rfc2808.txt
deleted file mode 100644
index 231865e..0000000
--- a/doc/rfc/rfc2808.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Nystrom
-Request for Comments: 2808 RSA Laboratories
-Category: Informational April 2000
-
-
- The SecurID(r) SASL Mechanism
-
-Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard of any kind. Distribution of this
- memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-Abstract
-
- SecurID is a hardware token card product (or software emulation
- thereof) produced by RSA Security Inc., which is used for end-user
- authentication. This document defines a SASL [RFC2222] authentication
- mechanism using these tokens, thereby providing a means for such
- tokens to be used in SASL environments. This mechanism is only for
- authentication, and has no effect on the protocol encoding and is not
- designed to provide integrity or confidentiality services.
-
- This memo assumes the reader has basic familiarity with the SecurID
- token, its associated authentication protocol and SASL.
-
-How to read this document
-
- The key words "MUST", "MUST NOT", "SHALL", "SHOULD" and "MAY" in this
- document are to be interpreted as defined in [RFC2119].
-
- In examples, "C:" and "S:" indicate messages sent by the client and
- server respectively.
-
-1. Introduction
-
- The SECURID SASL mechanism is a good choice for usage scenarios where
- a client, acting on behalf of a user, is untrusted, as a one-time
- passcode will only give the client a single opportunity to act
- maliciously. This mechanism provides authentication only.
-
-
-
-
-
-
-
-Nystrom Informational [Page 1]
-
-RFC 2808 The SecurID(r) SASL Mechanism April 2000
-
-
- The SECURID SASL mechanism provides a formal way to integrate the
- existing SecurID authentication method into SASL-enabled protocols
- including IMAP [RFC2060], ACAP [RFC2244], POP3 [RFC1734] and LDAPv3
- [RFC2251].
-
-2. Authentication Model
-
- The SECURID SASL mechanism provides two-factor based user
- authentication as defined below.
-
- There are basically three entities in the authentication mechanism
- described here: A user, possessing a SecurID token, an application
- server, to which the user wants to connect, and an authentication
- server, capable of authenticating the user. Even though the
- application server in practice may function as a client with respect
- to the authentication server, relaying authentication credentials
- etc. as needed, both servers are, unless explicitly mentioned,
- collectively termed "the server" here. The protocol used between the
- application server and the authentication server is outside the scope
- of this memo. The application client, acting on behalf of the user,
- is termed "the client".
-
- The mechanism is based on the use of a shared secret key, or "seed",
- and a personal identification number (PIN), which is known both by
- the user and the authentication server. The secret seed is stored on
- a token that the user possesses, as well as on the authentication
- server. Hence the term "two-factor authentication", a user needs not
- only physical access to the token but also knowledge about the PIN in
- order to perform an authentication. Given the seed, current time of
- day, and the PIN, a "PASSCODE(r)" is generated by the user's token
- and sent to the server.
-
- The SECURID SASL mechanism provides one service:
-
- - User authentication where the user provides information to the
- server, so that the server can authenticate the user.
-
- This mechanism is identified with the SASL key "SECURID".
-
-3. Authentication Procedure
-
- a) The client generates the credentials using local information
- (seed, current time and user PIN/password).
-
-
-
-
-
-
-
-
-Nystrom Informational [Page 2]
-
-RFC 2808 The SecurID(r) SASL Mechanism April 2000
-
-
- b) If the underlying protocol permits, the client sends credentials
- to the server in an initial response message. Otherwise, the
- client sends a request to the server to initiate the
- authentication mechanism, and sends credentials after the server's
- response (see [RFC2222] section 5.1 for more information regarding
- the initial response option).
-
- Unless the server requests a new PIN (see below), the contents of
- the client's initial response SHALL be as follows:
-
- (1) An authorization identity. When this field is empty, it
- defaults to the authentication identity. This field MAY be used
- by system administrators or proxy servers to login with a
- different user identity. This field MUST NOT be longer than 255
- octets, SHALL be terminated by a NUL (0) octet, and MUST consist
- of UTF-8-encoded [RFC2279] printable characters only (US-ASCII
- [X3.4] is a subset of UTF-8).
-
- (2) An authentication identity. The identity whose passcode will
- be used. If this field is empty, it is assumed to have been
- transferred by other means (e.g. if the underlying protocol has
- support for this, like [RFC2251]). This field MUST NOT be longer
- than 255 octets, SHALL be terminated by a NUL (0) octet, and MUST
- consist of UTF-8-encoded printable characters only.
-
- (3) A passcode. The one-time password that will be used to grant
- access. This field MUST NOT be shorter than 4 octets, MUST NOT be
- longer than 32 octets, SHALL be terminated by a NUL (0) octet, and
- MUST consist of UTF-8-encoded printable characters only.
- Passcodes usually consist of 4-8 digits.
-
- The ABNF [RFC2234] form of this message is as follows:
-
- credential-pdu = authorization-id authentication-id passcode [pin]
-
- authorization-id = 0*255VUTF8 %x00
-
- authentication-id = 0*255VUTF8 %x00
-
- passcode = 4*32VUTF8 %x00
-
- pin ::= 4*32VUTF8 %x00
-
- VUTF8 = <Visible (printable) UTF8-encoded characters>
-
- Regarding the <pin> rule, see d) below.
-
-
-
-
-
-Nystrom Informational [Page 3]
-
-RFC 2808 The SecurID(r) SASL Mechanism April 2000
-
-
- c) The server verifies these credentials using its own information.
- If the verification succeeds, the server sends back a response
- indicating success to the client. After receiving this response,
- the client is authenticated. Otherwise, the verification either
- failed or the server needs an additional set of credentials from
- the client in order to authenticate the user.
-
- d) If the server needs an additional set of credentials, it requests
- them now. This request has the following format, described in ABNF
- notation:
-
- server-request = passcode | pin
-
- passcode = "passcode" %x00
-
- pin = "pin" %x00 [suggested-pin]
-
- suggested-pin = 4*32VUTF8 %x00 ; Between 4 and 32 UTF-8 characters
-
- The 'passcode' choice will be sent when the server requests
- another passcode. The 'pin' choice will be sent when the server
- requests a new user PIN. The server will either send an empty
- string or suggest a new user PIN in this message.
-
- e) The client generates a new set of credentials using local
- information and depending on the server's request and sends them
- to the server. Authentication now continues as in c) above.
-
- Note 1: Case d) above may occur e.g. when the clocks on which the
- server and the client relies are not synchronized.
-
- Note 2: If the server requests a new user PIN, the client MUST
- respond with a new user PIN (together with a passcode), encoded as a
- UTF-8 string. If the server supplies the client with a suggested PIN,
- the client accepts this by replying with the same PIN, but MAY
- replace it with another one. The length of the PIN is application-
- dependent as are any other requirements for the PIN, e.g. allowed
- characters. If the server for some reason does not accept the
- received PIN, the client MUST be prepared to receive either a message
- indicating the failure of the authentication or a repeated request
- for a new PIN. Mechanisms for transferring knowledge about PIN
- requirements from the server to the client are outside the scope of
- this memo. However, some information MAY be provided in error
- messages transferred from the server to the client when applicable.
-
-
-
-
-
-
-
-Nystrom Informational [Page 4]
-
-RFC 2808 The SecurID(r) SASL Mechanism April 2000
-
-
-4. Examples
-
-4.1 IMAP4
-
- The following example shows the use of the SECURID SASL mechanism
- with IMAP4. The example is only designed to illustrate the protocol
- interaction but do provide valid encoding examples.
-
- The base64 encoding of the last client response, as well as the "+ "
- preceding the response, is part of the IMAP4 profile, and not a part
- of this specification itself.
-
- S: * OK IMAP4 server ready
- C: A001 CAPABILITY
- S: * CAPABILITY IMAP4 AUTH=CRAM-MD5 AUTH=SECURID
- S: A001 OK done
- C: A002 AUTHENTICATE SECURID
- S: +
- C: AG1hZ251cwAxMjM0NTY3OAA=
- S: A002 OK Welcome, SECURID authenticated user: magnus
-
-4.2 LDAPv3
-
- The following examples show the use of the SECURID SASL mechanism
- with LDAPv3. The examples are only designed to illustrate the
- protocol interaction, but do provide valid encoding examples.
- Usernames, passcodes and PINs are of course fictitious. For
- readability, all messages are shown in the value-notation defined in
- [X680]. <credential-pdu> values are shown hex-encoded in the
- 'credentials' field of LDAP's 'BindRequest' and <server-request>
- values are shown hex-encoded in the 'serverSaslCreds' field of LDAP's
- 'BindResponse'.
-
-4.2.1 LDAPv3 Example 1
-
- Initial response message, successful authentication.
-
- C: { messageID 1,
- protocolOp bindRequest :
- { version 1,
- name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
- authentication sasl :
- { mechanism '53454355524944'H, -- "SECURID"
- credentials '006d61676e757300313233343536373800'H
- }
- }
- }
-
-
-
-
-Nystrom Informational [Page 5]
-
-RFC 2808 The SecurID(r) SASL Mechanism April 2000
-
-
- S: { messageID 1,
- protocolOp bindResponse :
- { resultCode success,
- matchedDN ''H,
- errorMessage ''H,
- }
- }
-
-4.2.2 LDAPv3 Example 2
-
- Initial response message, server requires second passcode.
-
- C: {
- messageID 1,
- protocolOp bindRequest : {
- version 1,
- name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
- authentication sasl : {
- mechanism '53454355524944'H, -- "SECURID"
- credentials '006d61676e757300313233343536373800'H
- }
- }
- }
-
- S: {
- messageID 1,
- protocolOp bindResponse : {
- resultCode saslBindInProgress,
- matchedDN ''H,
- errorMessage ''H,
- serverSaslCreds '70617373636f646500'H
- }
- }
-
- C: {
- messageID 1,
- protocolOp bindRequest : {
- version 1,
- name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
- authentication sasl : {
- mechanism '53454355524944'H, -- "SECURID"
- credentials '006d61676e757300383736353433323100'H
- }
- }
- }
-
- S: {
- messageID 1,
-
-
-
-Nystrom Informational [Page 6]
-
-RFC 2808 The SecurID(r) SASL Mechanism April 2000
-
-
- protocolOp bindResponse : {
- resultCode success,
- matchedDN ''H,
- errorMessage ''H,
- }
- }
-
-4.2.3 LDAPv3 Example 3
-
- Initial response message, server requires new PIN and passcode, and
- supplies client with a suggested new PIN (which the client accepts).
-
- C: {
- messageID 1,
- protocolOp bindRequest : {
- version 1,
- name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
- authentication sasl : {
- mechanism '53454355524944'H, -- "SECURID"
- credentials '006d61676e757300313233343536373800'H
- }
- }
- }
-
- S: {
- messageID 1,
- protocolOp bindResponse : {
- resultCode saslBindInProgress,
- matchedDN ''H,
- errorMessage ''H,
- serverSaslCreds '70696e006b616c6c6500'H
- }
- }
-
- C: {
- messageID 1,
- protocolOp bindRequest : {
- version 1,
- name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
- authentication sasl : {
- mechanism '53454355524944'H, -- "SECURID"
- credentials '006d61676e7573003837343434363734006b616c6c6500'H
- }
- }
- }
-
- S: {
- messageID 1,
-
-
-
-Nystrom Informational [Page 7]
-
-RFC 2808 The SecurID(r) SASL Mechanism April 2000
-
-
- protocolOp bindResponse : {
- resultCode success,
- matchedDN ''H,
- errorMessage ''H,
- }
- }
-
-5. Security Considerations
-
- This mechanism only provides protection against passive eavesdropping
- attacks. It does not provide session privacy, server authentication
- or protection from active attacks. In particular, man-in-the-middle
- attacks, were an attacker acts as an application server in order to
- acquire a valid passcode are possible.
-
- In order to protect against such attacks, the client SHOULD make sure
- that the server is properly authenticated. When user PINs are
- transmitted, user authentication SHOULD take place on a server-
- authenticated and confidentiality-protected connection.
-
- Server implementations MUST protect against replay attacks, since an
- attacker could otherwise gain access by replaying a previous, valid
- request. Clients MUST also protect against replay of PIN-change
- messages.
-
-5.1 The Race Attack
-
- It is possible for an attacker to listen to most of a passcode, guess
- the remainder, and then race the legitimate user to complete the
- authentication. As for OTP [RFC2289], conforming server
- implementations MUST protect against this race condition. One defense
- against this attack is outlined below and borrowed from [RFC2289];
- implementations MAY use this approach or MAY select an alternative
- defense.
-
- One possible defense is to prevent a user from starting multiple
- simultaneous authentication sessions. This means that once the
- legitimate user has initiated authentication, an attacker would be
- blocked until the first authentication process has completed. In
- this approach, a timeout is necessary to thwart a denial of service
- attack.
-
-6. IANA Considerations
-
- By registering the SecurID protocol as a SASL mechanism, implementers
- will have a well-defined way of adding this authentication mechanism
- to their product. Here is the registration template for the SECURID
- SASL mechanism:
-
-
-
-Nystrom Informational [Page 8]
-
-RFC 2808 The SecurID(r) SASL Mechanism April 2000
-
-
- SASL mechanism name: SECURID
- Security Considerations: See corresponding section of this memo
- Published specification: This memo
- Person & email address to
- contact for further
- information: See author's address section below
- Intended usage: COMMON
- Author/Change controller: See author's address section below
-
-7. Intellectual Property Considerations
-
- RSA Security Inc. does not make any claims on the general
- constructions described in this memo, although underlying techniques
- may be covered. Among the underlying techniques, the SecurID
- technology is covered by a number of US patents (and foreign
- counterparts), in particular US patent no. 4,885,778, no. 5,097,505,
- no. 5,168,520, and 5,657,388.
-
- SecurID is a registered trademark, and PASSCODE is a trademark, of
- RSA Security Inc.
-
-8. References
-
- [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,
- December 1994.
-
- [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
- 3", BCP 9, RFC 2026, October 1996.
-
- [RFC2060] Crispin, M., "Internet Message Access Protocol - Version
- 4rev1", RFC 2060, December 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2222] Myers, J., "Simple Authentication and Security Layer", RFC
- 2222, October 1997.
-
- [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [RFC2244] Newman, C. and J. Myers, "ACAP -- Application Configuration
- Access Protocol", RFC 2244, November 1997.
-
- [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
-
-
-
-
-Nystrom Informational [Page 9]
-
-RFC 2808 The SecurID(r) SASL Mechanism April 2000
-
-
- [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
- RFC 2279, January 1998.
-
- [RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time
- Password System", RFC 2289, February 1998.
-
- [X3.4] ANSI, "ANSI X3.4: Information Systems - Coded Character
- Sets - 7-Bit American National Standard Code for
- Information Interchange (7-Bit ASCII)," American National
- Standards Institute.
-
- [X680] ITU-T, "Information Technology - Abstract Syntax Notation
- One (ASN.1): Specification of Basic Notation,"
- International Telecommunication Union, 1997.
-
-9. Acknowledgements
-
- The author gratefully acknowledges the contributions of various
- reviewers of this memo, in particular the ones from John Myers. They
- have significantly clarified and improved the utility of this
- specification.
-
-10. Author's Address
-
- Magnus Nystrom
- RSA Laboratories
- Box 10704
- 121 29 Stockholm
- Sweden
-
- Phone: +46 8 725 0900
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nystrom Informational [Page 10]
-
-RFC 2808 The SecurID(r) SASL Mechanism April 2000
-
-
-11. Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nystrom Informational [Page 11]
-
diff --git a/doc/rfc/rfc2821.txt b/doc/rfc/rfc2821.txt
deleted file mode 100644
index 0eac911..0000000
--- a/doc/rfc/rfc2821.txt
+++ /dev/null
@@ -1,4427 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Klensin, Editor
-Request for Comments: 2821 AT&T Laboratories
-Obsoletes: 821, 974, 1869 April 2001
-Updates: 1123
-Category: Standards Track
-
-
- Simple Mail Transfer Protocol
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
-Abstract
-
- This document is a self-contained specification of the basic protocol
- for the Internet electronic mail transport. It consolidates, updates
- and clarifies, but doesn't add new or change existing functionality
- of the following:
-
- - the original SMTP (Simple Mail Transfer Protocol) specification of
- RFC 821 [30],
-
- - domain name system requirements and implications for mail
- transport from RFC 1035 [22] and RFC 974 [27],
-
- - the clarifications and applicability statements in RFC 1123 [2],
- and
-
- - material drawn from the SMTP Extension mechanisms [19].
-
- It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the
- mail transport materials of RFC 1123). However, RFC 821 specifies
- some features that were not in significant use in the Internet by the
- mid-1990s and (in appendices) some additional transport models.
- Those sections are omitted here in the interest of clarity and
- brevity; readers needing them should refer to RFC 821.
-
-
-
-
-
-
-Klensin Standards Track [Page 1]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- It also includes some additional material from RFC 1123 that required
- amplification. This material has been identified in multiple ways,
- mostly by tracking flaming on various lists and newsgroups and
- problems of unusual readings or interpretations that have appeared as
- the SMTP extensions have been deployed. Where this specification
- moves beyond consolidation and actually differs from earlier
- documents, it supersedes them technically as well as textually.
-
- Although SMTP was designed as a mail transport and delivery protocol,
- this specification also contains information that is important to its
- use as a 'mail submission' protocol, as recommended for POP [3, 26]
- and IMAP [6]. Additional submission issues are discussed in RFC 2476
- [15].
-
- Section 2.3 provides definitions of terms specific to this document.
- Except when the historical terminology is necessary for clarity, this
- document uses the current 'client' and 'server' terminology to
- identify the sending and receiving SMTP processes, respectively.
-
- A companion document [32] discusses message headers, message bodies
- and formats and structures for them, and their relationship.
-
-Table of Contents
-
- 1. Introduction .................................................. 4
- 2. The SMTP Model ................................................ 5
- 2.1 Basic Structure .............................................. 5
- 2.2 The Extension Model .......................................... 7
- 2.2.1 Background ................................................. 7
- 2.2.2 Definition and Registration of Extensions .................. 8
- 2.3 Terminology .................................................. 9
- 2.3.1 Mail Objects ............................................... 10
- 2.3.2 Senders and Receivers ...................................... 10
- 2.3.3 Mail Agents and Message Stores ............................. 10
- 2.3.4 Host ....................................................... 11
- 2.3.5 Domain ..................................................... 11
- 2.3.6 Buffer and State Table ..................................... 11
- 2.3.7 Lines ...................................................... 12
- 2.3.8 Originator, Delivery, Relay, and Gateway Systems ........... 12
- 2.3.9 Message Content and Mail Data .............................. 13
- 2.3.10 Mailbox and Address ....................................... 13
- 2.3.11 Reply ..................................................... 13
- 2.4 General Syntax Principles and Transaction Model .............. 13
- 3. The SMTP Procedures: An Overview .............................. 15
- 3.1 Session Initiation ........................................... 15
- 3.2 Client Initiation ............................................ 16
- 3.3 Mail Transactions ............................................ 16
- 3.4 Forwarding for Address Correction or Updating ................ 19
-
-
-
-Klensin Standards Track [Page 2]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- 3.5 Commands for Debugging Addresses ............................. 20
- 3.5.1 Overview ................................................... 20
- 3.5.2 VRFY Normal Response ....................................... 22
- 3.5.3 Meaning of VRFY or EXPN Success Response ................... 22
- 3.5.4 Semantics and Applications of EXPN ......................... 23
- 3.6 Domains ...................................................... 23
- 3.7 Relaying ..................................................... 24
- 3.8 Mail Gatewaying .............................................. 25
- 3.8.1 Header Fields in Gatewaying ................................ 26
- 3.8.2 Received Lines in Gatewaying ............................... 26
- 3.8.3 Addresses in Gatewaying .................................... 26
- 3.8.4 Other Header Fields in Gatewaying .......................... 27
- 3.8.5 Envelopes in Gatewaying .................................... 27
- 3.9 Terminating Sessions and Connections ......................... 27
- 3.10 Mailing Lists and Aliases ................................... 28
- 3.10.1 Alias ..................................................... 28
- 3.10.2 List ...................................................... 28
- 4. The SMTP Specifications ....................................... 29
- 4.1 SMTP Commands ................................................ 29
- 4.1.1 Command Semantics and Syntax ............................... 29
- 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) ................... 29
- 4.1.1.2 MAIL (MAIL) .............................................. 31
- 4.1.1.3 RECIPIENT (RCPT) ......................................... 31
- 4.1.1.4 DATA (DATA) .............................................. 33
- 4.1.1.5 RESET (RSET) ............................................. 34
- 4.1.1.6 VERIFY (VRFY) ............................................ 35
- 4.1.1.7 EXPAND (EXPN) ............................................ 35
- 4.1.1.8 HELP (HELP) .............................................. 35
- 4.1.1.9 NOOP (NOOP) .............................................. 35
- 4.1.1.10 QUIT (QUIT) ............................................. 36
- 4.1.2 Command Argument Syntax .................................... 36
- 4.1.3 Address Literals ........................................... 38
- 4.1.4 Order of Commands .......................................... 39
- 4.1.5 Private-use Commands ....................................... 40
- 4.2 SMTP Replies ................................................ 40
- 4.2.1 Reply Code Severities and Theory ........................... 42
- 4.2.2 Reply Codes by Function Groups ............................. 44
- 4.2.3 Reply Codes in Numeric Order .............................. 45
- 4.2.4 Reply Code 502 ............................................. 46
- 4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> .... 46
- 4.3 Sequencing of Commands and Replies ........................... 47
- 4.3.1 Sequencing Overview ........................................ 47
- 4.3.2 Command-Reply Sequences .................................... 48
- 4.4 Trace Information ............................................ 49
- 4.5 Additional Implementation Issues ............................. 53
- 4.5.1 Minimum Implementation ..................................... 53
- 4.5.2 Transparency ............................................... 53
- 4.5.3 Sizes and Timeouts ......................................... 54
-
-
-
-Klensin Standards Track [Page 3]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- 4.5.3.1 Size limits and minimums ................................. 54
- 4.5.3.2 Timeouts ................................................. 56
- 4.5.4 Retry Strategies ........................................... 57
- 4.5.4.1 Sending Strategy ......................................... 58
- 4.5.4.2 Receiving Strategy ....................................... 59
- 4.5.5 Messages with a null reverse-path .......................... 59
- 5. Address Resolution and Mail Handling .......................... 60
- 6. Problem Detection and Handling ................................ 62
- 6.1 Reliable Delivery and Replies by Email ....................... 62
- 6.2 Loop Detection ............................................... 63
- 6.3 Compensating for Irregularities .............................. 63
- 7. Security Considerations ....................................... 64
- 7.1 Mail Security and Spoofing ................................... 64
- 7.2 "Blind" Copies ............................................... 65
- 7.3 VRFY, EXPN, and Security ..................................... 65
- 7.4 Information Disclosure in Announcements ...................... 66
- 7.5 Information Disclosure in Trace Fields ....................... 66
- 7.6 Information Disclosure in Message Forwarding ................. 67
- 7.7 Scope of Operation of SMTP Servers ........................... 67
- 8. IANA Considerations ........................................... 67
- 9. References .................................................... 68
- 10. Editor's Address ............................................. 70
- 11. Acknowledgments .............................................. 70
- Appendices ....................................................... 71
- A. TCP Transport Service ......................................... 71
- B. Generating SMTP Commands from RFC 822 Headers ................. 71
- C. Source Routes ................................................. 72
- D. Scenarios ..................................................... 73
- E. Other Gateway Issues .......................................... 76
- F. Deprecated Features of RFC 821 ................................ 76
- Full Copyright Statement ......................................... 79
-
-1. Introduction
-
- The objective of the Simple Mail Transfer Protocol (SMTP) is to
- transfer mail reliably and efficiently.
-
- SMTP is independent of the particular transmission subsystem and
- requires only a reliable ordered data stream channel. While this
- document specifically discusses transport over TCP, other transports
- are possible. Appendices to RFC 821 describe some of them.
-
- An important feature of SMTP is its capability to transport mail
- across networks, usually referred to as "SMTP mail relaying" (see
- section 3.8). A network consists of the mutually-TCP-accessible
- hosts on the public Internet, the mutually-TCP-accessible hosts on a
- firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN
- environment utilizing a non-TCP transport-level protocol. Using
-
-
-
-Klensin Standards Track [Page 4]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- SMTP, a process can transfer mail to another process on the same
- network or to some other network via a relay or gateway process
- accessible to both networks.
-
- In this way, a mail message may pass through a number of intermediate
- relay or gateway hosts on its path from sender to ultimate recipient.
- The Mail eXchanger mechanisms of the domain name system [22, 27] (and
- section 5 of this document) are used to identify the appropriate
- next-hop destination for a message being transported.
-
-2. The SMTP Model
-
-2.1 Basic Structure
-
- The SMTP design can be pictured as:
-
- +----------+ +----------+
- +------+ | | | |
- | User |<-->| | SMTP | |
- +------+ | Client- |Commands/Replies| Server- |
- +------+ | SMTP |<-------------->| SMTP | +------+
- | File |<-->| | and Mail | |<-->| File |
- |System| | | | | |System|
- +------+ +----------+ +----------+ +------+
- SMTP client SMTP server
-
- When an SMTP client has a message to transmit, it establishes a two-
- way transmission channel to an SMTP server. The responsibility of an
- SMTP client is to transfer mail messages to one or more SMTP servers,
- or report its failure to do so.
-
- The means by which a mail message is presented to an SMTP client, and
- how that client determines the domain name(s) to which mail messages
- are to be transferred is a local matter, and is not addressed by this
- document. In some cases, the domain name(s) transferred to, or
- determined by, an SMTP client will identify the final destination(s)
- of the mail message. In other cases, common with SMTP clients
- associated with implementations of the POP [3, 26] or IMAP [6]
- protocols, or when the SMTP client is inside an isolated transport
- service environment, the domain name determined will identify an
- intermediate destination through which all mail messages are to be
- relayed. SMTP clients that transfer all traffic, regardless of the
- target domain names associated with the individual messages, or that
- do not maintain queues for retrying message transmissions that
- initially cannot be completed, may otherwise conform to this
- specification but are not considered fully-capable. Fully-capable
- SMTP implementations, including the relays used by these less capable
-
-
-
-
-Klensin Standards Track [Page 5]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- ones, and their destinations, are expected to support all of the
- queuing, retrying, and alternate address functions discussed in this
- specification.
-
- The means by which an SMTP client, once it has determined a target
- domain name, determines the identity of an SMTP server to which a
- copy of a message is to be transferred, and then performs that
- transfer, is covered by this document. To effect a mail transfer to
- an SMTP server, an SMTP client establishes a two-way transmission
- channel to that SMTP server. An SMTP client determines the address
- of an appropriate host running an SMTP server by resolving a
- destination domain name to either an intermediate Mail eXchanger host
- or a final target host.
-
- An SMTP server may be either the ultimate destination or an
- intermediate "relay" (that is, it may assume the role of an SMTP
- client after receiving the message) or "gateway" (that is, it may
- transport the message further using some protocol other than SMTP).
- SMTP commands are generated by the SMTP client and sent to the SMTP
- server. SMTP replies are sent from the SMTP server to the SMTP
- client in response to the commands.
-
- In other words, message transfer can occur in a single connection
- between the original SMTP-sender and the final SMTP-recipient, or can
- occur in a series of hops through intermediary systems. In either
- case, a formal handoff of responsibility for the message occurs: the
- protocol requires that a server accept responsibility for either
- delivering a message or properly reporting the failure to do so.
-
- Once the transmission channel is established and initial handshaking
- completed, the SMTP client normally initiates a mail transaction.
- Such a transaction consists of a series of commands to specify the
- originator and destination of the mail and transmission of the
- message content (including any headers or other structure) itself.
- When the same message is sent to multiple recipients, this protocol
- encourages the transmission of only one copy of the data for all
- recipients at the same destination (or intermediate relay) host.
-
- The server responds to each command with a reply; replies may
- indicate that the command was accepted, that additional commands are
- expected, or that a temporary or permanent error condition exists.
- Commands specifying the sender or recipients may include server-
- permitted SMTP service extension requests as discussed in section
- 2.2. The dialog is purposely lock-step, one-at-a-time, although this
- can be modified by mutually-agreed extension requests such as command
- pipelining [13].
-
-
-
-
-
-Klensin Standards Track [Page 6]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- Once a given mail message has been transmitted, the client may either
- request that the connection be shut down or may initiate other mail
- transactions. In addition, an SMTP client may use a connection to an
- SMTP server for ancillary services such as verification of email
- addresses or retrieval of mailing list subscriber addresses.
-
- As suggested above, this protocol provides mechanisms for the
- transmission of mail. This transmission normally occurs directly
- from the sending user's host to the receiving user's host when the
- two hosts are connected to the same transport service. When they are
- not connected to the same transport service, transmission occurs via
- one or more relay SMTP servers. An intermediate host that acts as
- either an SMTP relay or as a gateway into some other transmission
- environment is usually selected through the use of the domain name
- service (DNS) Mail eXchanger mechanism.
-
- Usually, intermediate hosts are determined via the DNS MX record, not
- by explicit "source" routing (see section 5 and appendices C and
- F.2).
-
-2.2 The Extension Model
-
-2.2.1 Background
-
- In an effort that started in 1990, approximately a decade after RFC
- 821 was completed, the protocol was modified with a "service
- extensions" model that permits the client and server to agree to
- utilize shared functionality beyond the original SMTP requirements.
- The SMTP extension mechanism defines a means whereby an extended SMTP
- client and server may recognize each other, and the server can inform
- the client as to the service extensions that it supports.
-
- Contemporary SMTP implementations MUST support the basic extension
- mechanisms. For instance, servers MUST support the EHLO command even
- if they do not implement any specific extensions and clients SHOULD
- preferentially utilize EHLO rather than HELO. (However, for
- compatibility with older conforming implementations, SMTP clients and
- servers MUST support the original HELO mechanisms as a fallback.)
- Unless the different characteristics of HELO must be identified for
- interoperability purposes, this document discusses only EHLO.
-
- SMTP is widely deployed and high-quality implementations have proven
- to be very robust. However, the Internet community now considers
- some services to be important that were not anticipated when the
- protocol was first designed. If support for those services is to be
- added, it must be done in a way that permits older implementations to
- continue working acceptably. The extension framework consists of:
-
-
-
-
-Klensin Standards Track [Page 7]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- - The SMTP command EHLO, superseding the earlier HELO,
-
- - a registry of SMTP service extensions,
-
- - additional parameters to the SMTP MAIL and RCPT commands, and
-
- - optional replacements for commands defined in this protocol, such
- as for DATA in non-ASCII transmissions [33].
-
- SMTP's strength comes primarily from its simplicity. Experience with
- many protocols has shown that protocols with few options tend towards
- ubiquity, whereas protocols with many options tend towards obscurity.
-
- Each and every extension, regardless of its benefits, must be
- carefully scrutinized with respect to its implementation, deployment,
- and interoperability costs. In many cases, the cost of extending the
- SMTP service will likely outweigh the benefit.
-
-2.2.2 Definition and Registration of Extensions
-
- The IANA maintains a registry of SMTP service extensions. A
- corresponding EHLO keyword value is associated with each extension.
- Each service extension registered with the IANA must be defined in a
- formal standards-track or IESG-approved experimental protocol
- document. The definition must include:
-
- - the textual name of the SMTP service extension;
-
- - the EHLO keyword value associated with the extension;
-
- - the syntax and possible values of parameters associated with the
- EHLO keyword value;
-
- - any additional SMTP verbs associated with the extension
- (additional verbs will usually be, but are not required to be, the
- same as the EHLO keyword value);
-
- - any new parameters the extension associates with the MAIL or RCPT
- verbs;
-
- - a description of how support for the extension affects the
- behavior of a server and client SMTP; and,
-
- - the increment by which the extension is increasing the maximum
- length of the commands MAIL and/or RCPT, over that specified in
- this standard.
-
-
-
-
-
-Klensin Standards Track [Page 8]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- In addition, any EHLO keyword value starting with an upper or lower
- case "X" refers to a local SMTP service extension used exclusively
- through bilateral agreement. Keywords beginning with "X" MUST NOT be
- used in a registered service extension. Conversely, keyword values
- presented in the EHLO response that do not begin with "X" MUST
- correspond to a standard, standards-track, or IESG-approved
- experimental SMTP service extension registered with IANA. A
- conforming server MUST NOT offer non-"X"-prefixed keyword values that
- are not described in a registered extension.
-
- Additional verbs and parameter names are bound by the same rules as
- EHLO keywords; specifically, verbs beginning with "X" are local
- extensions that may not be registered or standardized. Conversely,
- verbs not beginning with "X" must always be registered.
-
-2.3 Terminology
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described below.
-
- 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that
- the definition is an absolute requirement of the specification.
-
- 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
- definition is an absolute prohibition of the specification.
-
- 3. SHOULD This word, or the adjective "RECOMMENDED", mean 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 This phrase, or the phrase "NOT RECOMMENDED" mean
- 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 This word, or the adjective "OPTIONAL", mean 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, though perhaps with
- reduced functionality. In the same vein an implementation which
-
-
-
-Klensin Standards Track [Page 9]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- does include a particular option MUST be prepared to interoperate
- with another implementation which does not include the option
- (except, of course, for the feature the option provides.)
-
-2.3.1 Mail Objects
-
- SMTP transports a mail object. A mail object contains an envelope
- and content.
-
- The SMTP envelope is sent as a series of SMTP protocol units
- (described in section 3). It consists of an originator address (to
- which error reports should be directed); one or more recipient
- addresses; and optional protocol extension material. Historically,
- variations on the recipient address specification command (RCPT TO)
- could be used to specify alternate delivery modes, such as immediate
- display; those variations have now been deprecated (see appendix F,
- section F.6).
-
- The SMTP content is sent in the SMTP DATA protocol unit and has two
- parts: the headers and the body. If the content conforms to other
- contemporary standards, the headers form a collection of field/value
- pairs structured as in the message format specification [32]; the
- body, if structured, is defined according to MIME [12]. The content
- is textual in nature, expressed using the US-ASCII repertoire [1].
- Although SMTP extensions (such as "8BITMIME" [20]) may relax this
- restriction for the content body, the content headers are always
- encoded using the US-ASCII repertoire. A MIME extension [23] defines
- an algorithm for representing header values outside the US-ASCII
- repertoire, while still encoding them using the US-ASCII repertoire.
-
-2.3.2 Senders and Receivers
-
- In RFC 821, the two hosts participating in an SMTP transaction were
- described as the "SMTP-sender" and "SMTP-receiver". This document
- has been changed to reflect current industry terminology and hence
- refers to them as the "SMTP client" (or sometimes just "the client")
- and "SMTP server" (or just "the server"), respectively. Since a
- given host may act both as server and client in a relay situation,
- "receiver" and "sender" terminology is still used where needed for
- clarity.
-
-2.3.3 Mail Agents and Message Stores
-
- Additional mail system terminology became common after RFC 821 was
- published and, where convenient, is used in this specification. In
- particular, SMTP servers and clients provide a mail transport service
- and therefore act as "Mail Transfer Agents" (MTAs). "Mail User
- Agents" (MUAs or UAs) are normally thought of as the sources and
-
-
-
-Klensin Standards Track [Page 10]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- targets of mail. At the source, an MUA might collect mail to be
- transmitted from a user and hand it off to an MTA; the final
- ("delivery") MTA would be thought of as handing the mail off to an
- MUA (or at least transferring responsibility to it, e.g., by
- depositing the message in a "message store"). However, while these
- terms are used with at least the appearance of great precision in
- other environments, the implied boundaries between MUAs and MTAs
- often do not accurately match common, and conforming, practices with
- Internet mail. Hence, the reader should be cautious about inferring
- the strong relationships and responsibilities that might be implied
- if these terms were used elsewhere.
-
-2.3.4 Host
-
- For the purposes of this specification, a host is a computer system
- attached to the Internet (or, in some cases, to a private TCP/IP
- network) and supporting the SMTP protocol. Hosts are known by names
- (see "domain"); identifying them by numerical address is discouraged.
-
-2.3.5 Domain
-
- A domain (or domain name) consists of one or more dot-separated
- components. These components ("labels" in DNS terminology [22]) are
- restricted for SMTP purposes to consist of a sequence of letters,
- digits, and hyphens drawn from the ASCII character set [1]. Domain
- names are used as names of hosts and of other entities in the domain
- name hierarchy. For example, a domain may refer to an alias (label
- of a CNAME RR) or the label of Mail eXchanger records to be used to
- deliver mail instead of representing a host name. See [22] and
- section 5 of this specification.
-
- The domain name, as described in this document and in [22], is the
- entire, fully-qualified name (often referred to as an "FQDN"). A
- domain name that is not in FQDN form is no more than a local alias.
- Local aliases MUST NOT appear in any SMTP transaction.
-
-2.3.6 Buffer and State Table
-
- SMTP sessions are stateful, with both parties carefully maintaining a
- common view of the current state. In this document we model this
- state by a virtual "buffer" and a "state table" on the server which
- may be used by the client to, for example, "clear the buffer" or
- "reset the state table," causing the information in the buffer to be
- discarded and the state to be returned to some previous state.
-
-
-
-
-
-
-
-Klensin Standards Track [Page 11]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
-2.3.7 Lines
-
- SMTP commands and, unless altered by a service extension, message
- data, are transmitted in "lines". Lines consist of zero or more data
- characters terminated by the sequence ASCII character "CR" (hex value
- 0D) followed immediately by ASCII character "LF" (hex value 0A).
- This termination sequence is denoted as <CRLF> in this document.
- Conforming implementations MUST NOT recognize or generate any other
- character or character sequence as a line terminator. Limits MAY be
- imposed on line lengths by servers (see section 4.5.3).
-
- In addition, the appearance of "bare" "CR" or "LF" characters in text
- (i.e., either without the other) has a long history of causing
- problems in mail implementations and applications that use the mail
- system as a tool. SMTP client implementations MUST NOT transmit
- these characters except when they are intended as line terminators
- and then MUST, as indicated above, transmit them only as a <CRLF>
- sequence.
-
-2.3.8 Originator, Delivery, Relay, and Gateway Systems
-
- This specification makes a distinction among four types of SMTP
- systems, based on the role those systems play in transmitting
- electronic mail. An "originating" system (sometimes called an SMTP
- originator) introduces mail into the Internet or, more generally,
- into a transport service environment. A "delivery" SMTP system is
- one that receives mail from a transport service environment and
- passes it to a mail user agent or deposits it in a message store
- which a mail user agent is expected to subsequently access. A
- "relay" SMTP system (usually referred to just as a "relay") receives
- mail from an SMTP client and transmits it, without modification to
- the message data other than adding trace information, to another SMTP
- server for further relaying or for delivery.
-
- A "gateway" SMTP system (usually referred to just as a "gateway")
- receives mail from a client system in one transport environment and
- transmits it to a server system in another transport environment.
- Differences in protocols or message semantics between the transport
- environments on either side of a gateway may require that the gateway
- system perform transformations to the message that are not permitted
- to SMTP relay systems. For the purposes of this specification,
- firewalls that rewrite addresses should be considered as gateways,
- even if SMTP is used on both sides of them (see [11]).
-
-
-
-
-
-
-
-
-Klensin Standards Track [Page 12]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
-2.3.9 Message Content and Mail Data
-
- The terms "message content" and "mail data" are used interchangeably
- in this document to describe the material transmitted after the DATA
- command is accepted and before the end of data indication is
- transmitted. Message content includes message headers and the
- possibly-structured message body. The MIME specification [12]
- provides the standard mechanisms for structured message bodies.
-
-2.3.10 Mailbox and Address
-
- As used in this specification, an "address" is a character string
- that identifies a user to whom mail will be sent or a location into
- which mail will be deposited. The term "mailbox" refers to that
- depository. The two terms are typically used interchangeably unless
- the distinction between the location in which mail is placed (the
- mailbox) and a reference to it (the address) is important. An
- address normally consists of user and domain specifications. The
- standard mailbox naming convention is defined to be "local-
- address@hidden": contemporary usage permits a much broader set of
- applications than simple "user names". Consequently, and due to a
- long history of problems when intermediate hosts have attempted to
- optimize transport by modifying them, the local-part MUST be
- interpreted and assigned semantics only by the host specified in the
- domain part of the address.
-
-2.3.11 Reply
-
- An SMTP reply is an acknowledgment (positive or negative) sent from
- receiver to sender via the transmission channel in response to a
- command. The general form of a reply is a numeric completion code
- (indicating failure or success) usually followed by a text string.
- The codes are for use by programs and the text is usually intended
- for human users. Recent work [34] has specified further structuring
- of the reply strings, including the use of supplemental and more
- specific completion codes.
-
-2.4 General Syntax Principles and Transaction Model
-
- SMTP commands and replies have a rigid syntax. All commands begin
- with a command verb. All Replies begin with a three digit numeric
- code. In some commands and replies, arguments MUST follow the verb
- or reply code. Some commands do not accept arguments (after the
- verb), and some reply codes are followed, sometimes optionally, by
- free form text. In both cases, where text appears, it is separated
- from the verb or reply code by a space character. Complete
- definitions of commands and replies appear in section 4.
-
-
-
-
-Klensin Standards Track [Page 13]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
- and extension name keywords) are not case sensitive, with the sole
- exception in this specification of a mailbox local-part (SMTP
- Extensions may explicitly specify case-sensitive elements). That is,
- a command verb, an argument value other than a mailbox local-part,
- and free form text MAY be encoded in upper case, lower case, or any
- mixture of upper and lower case with no impact on its meaning. This
- is NOT true of a mailbox local-part. The local-part of a mailbox
- MUST BE treated as case sensitive. Therefore, SMTP implementations
- MUST take care to preserve the case of mailbox local-parts. Mailbox
- domains are not case sensitive. In particular, for some hosts the
- user "smith" is different from the user "Smith". However, exploiting
- the case sensitivity of mailbox local-parts impedes interoperability
- and is discouraged.
-
- A few SMTP servers, in violation of this specification (and RFC 821)
- require that command verbs be encoded by clients in upper case.
- Implementations MAY wish to employ this encoding to accommodate those
- servers.
-
- The argument field consists of a variable length character string
- ending with the end of the line, i.e., with the character sequence
- <CRLF>. The receiver will take no action until this sequence is
- received.
-
- The syntax for each command is shown with the discussion of that
- command. Common elements and parameters are shown in section 4.1.2.
-
- Commands and replies are composed of characters from the ASCII
- character set [1]. When the transport service provides an 8-bit byte
- (octet) transmission channel, each 7-bit character is transmitted
- right justified in an octet with the high order bit cleared to zero.
- More specifically, the unextended SMTP service provides seven bit
- transport only. An originating SMTP client which has not
- successfully negotiated an appropriate extension with a particular
- server MUST NOT transmit messages with information in the high-order
- bit of octets. If such messages are transmitted in violation of this
- rule, receiving SMTP servers MAY clear the high-order bit or reject
- the message as invalid. In general, a relay SMTP SHOULD assume that
- the message content it has received is valid and, assuming that the
- envelope permits doing so, relay it without inspecting that content.
- Of course, if the content is mislabeled and the data path cannot
- accept the actual content, this may result in ultimate delivery of a
- severely garbled message to the recipient. Delivery SMTP systems MAY
- reject ("bounce") such messages rather than deliver them. No sending
- SMTP system is permitted to send envelope commands in any character
-
-
-
-
-
-Klensin Standards Track [Page 14]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- set other than US-ASCII; receiving systems SHOULD reject such
- commands, normally using "500 syntax error - invalid character"
- replies.
-
- Eight-bit message content transmission MAY be requested of the server
- by a client using extended SMTP facilities, notably the "8BITMIME"
- extension [20]. 8BITMIME SHOULD be supported by SMTP servers.
- However, it MUST not be construed as authorization to transmit
- unrestricted eight bit material. 8BITMIME MUST NOT be requested by
- senders for material with the high bit on that is not in MIME format
- with an appropriate content-transfer encoding; servers MAY reject
- such messages.
-
- The metalinguistic notation used in this document corresponds to the
- "Augmented BNF" used in other Internet mail system documents. The
- reader who is not familiar with that syntax should consult the ABNF
- specification [8]. Metalanguage terms used in running text are
- surrounded by pointed brackets (e.g., <CRLF>) for clarity.
-
-3. The SMTP Procedures: An Overview
-
- This section contains descriptions of the procedures used in SMTP:
- session initiation, the mail transaction, forwarding mail, verifying
- mailbox names and expanding mailing lists, and the opening and
- closing exchanges. Comments on relaying, a note on mail domains, and
- a discussion of changing roles are included at the end of this
- section. Several complete scenarios are presented in appendix D.
-
-3.1 Session Initiation
-
- An SMTP session is initiated when a client opens a connection to a
- server and the server responds with an opening message.
-
- SMTP server implementations MAY include identification of their
- software and version information in the connection greeting reply
- after the 220 code, a practice that permits more efficient isolation
- and repair of any problems. Implementations MAY make provision for
- SMTP servers to disable the software and version announcement where
- it causes security concerns. While some systems also identify their
- contact point for mail problems, this is not a substitute for
- maintaining the required "postmaster" address (see section 4.5.1).
-
- The SMTP protocol allows a server to formally reject a transaction
- while still allowing the initial connection as follows: a 554
- response MAY be given in the initial connection opening message
- instead of the 220. A server taking this approach MUST still wait
- for the client to send a QUIT (see section 4.1.1.10) before closing
- the connection and SHOULD respond to any intervening commands with
-
-
-
-Klensin Standards Track [Page 15]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- "503 bad sequence of commands". Since an attempt to make an SMTP
- connection to such a system is probably in error, a server returning
- a 554 response on connection opening SHOULD provide enough
- information in the reply text to facilitate debugging of the sending
- system.
-
-3.2 Client Initiation
-
- Once the server has sent the welcoming message and the client has
- received it, the client normally sends the EHLO command to the
- server, indicating the client's identity. In addition to opening the
- session, use of EHLO indicates that the client is able to process
- service extensions and requests that the server provide a list of the
- extensions it supports. Older SMTP systems which are unable to
- support service extensions and contemporary clients which do not
- require service extensions in the mail session being initiated, MAY
- use HELO instead of EHLO. Servers MUST NOT return the extended
- EHLO-style response to a HELO command. For a particular connection
- attempt, if the server returns a "command not recognized" response to
- EHLO, the client SHOULD be able to fall back and send HELO.
-
- In the EHLO command the host sending the command identifies itself;
- the command may be interpreted as saying "Hello, I am <domain>" (and,
- in the case of EHLO, "and I support service extension requests").
-
-3.3 Mail Transactions
-
- There are three steps to SMTP mail transactions. The transaction
- starts with a MAIL command which gives the sender identification.
- (In general, the MAIL command may be sent only when no mail
- transaction is in progress; see section 4.1.4.) A series of one or
- more RCPT commands follows giving the receiver information. Then a
- DATA command initiates transfer of the mail data and is terminated by
- the "end of mail" data indicator, which also confirms the
- transaction.
-
- The first step in the procedure is the MAIL command.
-
- MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
-
- This command tells the SMTP-receiver that a new mail transaction is
- starting and to reset all its state tables and buffers, including any
- recipients or mail data. The <reverse-path> portion of the first or
- only argument contains the source mailbox (between "<" and ">"
- brackets), which can be used to report errors (see section 4.2 for a
- discussion of error reporting). If accepted, the SMTP server returns
- a 250 OK reply. If the mailbox specification is not acceptable for
- some reason, the server MUST return a reply indicating whether the
-
-
-
-Klensin Standards Track [Page 16]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- failure is permanent (i.e., will occur again if the client tries to
- send the same address again) or temporary (i.e., the address might be
- accepted if the client tries again later). Despite the apparent
- scope of this requirement, there are circumstances in which the
- acceptability of the reverse-path may not be determined until one or
- more forward-paths (in RCPT commands) can be examined. In those
- cases, the server MAY reasonably accept the reverse-path (with a 250
- reply) and then report problems after the forward-paths are received
- and examined. Normally, failures produce 550 or 553 replies.
-
- Historically, the <reverse-path> can contain more than just a
- mailbox, however, contemporary systems SHOULD NOT use source routing
- (see appendix C).
-
- The optional <mail-parameters> are associated with negotiated SMTP
- service extensions (see section 2.2).
-
- The second step in the procedure is the RCPT command.
-
- RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
-
- The first or only argument to this command includes a forward-path
- (normally a mailbox and domain, always surrounded by "<" and ">"
- brackets) identifying one recipient. If accepted, the SMTP server
- returns a 250 OK reply and stores the forward-path. If the recipient
- is known not to be a deliverable address, the SMTP server returns a
- 550 reply, typically with a string such as "no such user - " and the
- mailbox name (other circumstances and reply codes are possible).
- This step of the procedure can be repeated any number of times.
-
- The <forward-path> can contain more than just a mailbox.
- Historically, the <forward-path> can be a source routing list of
- hosts and the destination mailbox, however, contemporary SMTP clients
- SHOULD NOT utilize source routes (see appendix C). Servers MUST be
- prepared to encounter a list of source routes in the forward path,
- but SHOULD ignore the routes or MAY decline to support the relaying
- they imply. Similarly, servers MAY decline to accept mail that is
- destined for other hosts or systems. These restrictions make a
- server useless as a relay for clients that do not support full SMTP
- functionality. Consequently, restricted-capability clients MUST NOT
- assume that any SMTP server on the Internet can be used as their mail
- processing (relaying) site. If a RCPT command appears without a
- previous MAIL command, the server MUST return a 503 "Bad sequence of
- commands" response. The optional <rcpt-parameters> are associated
- with negotiated SMTP service extensions (see section 2.2).
-
- The third step in the procedure is the DATA command (or some
- alternative specified in a service extension).
-
-
-
-Klensin Standards Track [Page 17]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- DATA <CRLF>
-
- If accepted, the SMTP server returns a 354 Intermediate reply and
- considers all succeeding lines up to but not including the end of
- mail data indicator to be the message text. When the end of text is
- successfully received and stored the SMTP-receiver sends a 250 OK
- reply.
-
- Since the mail data is sent on the transmission channel, the end of
- mail data must be indicated so that the command and reply dialog can
- be resumed. SMTP indicates the end of the mail data by sending a
- line containing only a "." (period or full stop). A transparency
- procedure is used to prevent this from interfering with the user's
- text (see section 4.5.2).
-
- The end of mail data indicator also confirms the mail transaction and
- tells the SMTP server to now process the stored recipients and mail
- data. If accepted, the SMTP server returns a 250 OK reply. The DATA
- command can fail at only two points in the protocol exchange:
-
- - If there was no MAIL, or no RCPT, command, or all such commands
- were rejected, the server MAY return a "command out of sequence"
- (503) or "no valid recipients" (554) reply in response to the DATA
- command. If one of those replies (or any other 5yz reply) is
- received, the client MUST NOT send the message data; more
- generally, message data MUST NOT be sent unless a 354 reply is
- received.
-
- - If the verb is initially accepted and the 354 reply issued, the
- DATA command should fail only if the mail transaction was
- incomplete (for example, no recipients), or if resources were
- unavailable (including, of course, the server unexpectedly
- becoming unavailable), or if the server determines that the
- message should be rejected for policy or other reasons.
-
- However, in practice, some servers do not perform recipient
- verification until after the message text is received. These servers
- SHOULD treat a failure for one or more recipients as a "subsequent
- failure" and return a mail message as discussed in section 6. Using
- a "550 mailbox not found" (or equivalent) reply code after the data
- are accepted makes it difficult or impossible for the client to
- determine which recipients failed.
-
- When RFC 822 format [7, 32] is being used, the mail data include the
- memo header items such as Date, Subject, To, Cc, From. Server SMTP
- systems SHOULD NOT reject messages based on perceived defects in the
- RFC 822 or MIME [12] message header or message body. In particular,
-
-
-
-
-Klensin Standards Track [Page 18]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- they MUST NOT reject messages in which the numbers of Resent-fields
- do not match or Resent-to appears without Resent-from and/or Resent-
- date.
-
- Mail transaction commands MUST be used in the order discussed above.
-
-3.4 Forwarding for Address Correction or Updating
-
- Forwarding support is most often required to consolidate and simplify
- addresses within, or relative to, some enterprise and less frequently
- to establish addresses to link a person's prior address with current
- one. Silent forwarding of messages (without server notification to
- the sender), for security or non-disclosure purposes, is common in
- the contemporary Internet.
-
- In both the enterprise and the "new address" cases, information
- hiding (and sometimes security) considerations argue against exposure
- of the "final" address through the SMTP protocol as a side-effect of
- the forwarding activity. This may be especially important when the
- final address may not even be reachable by the sender. Consequently,
- the "forwarding" mechanisms described in section 3.2 of RFC 821, and
- especially the 251 (corrected destination) and 551 reply codes from
- RCPT must be evaluated carefully by implementers and, when they are
- available, by those configuring systems.
-
- In particular:
-
- * Servers MAY forward messages when they are aware of an address
- change. When they do so, they MAY either provide address-updating
- information with a 251 code, or may forward "silently" and return
- a 250 code. But, if a 251 code is used, they MUST NOT assume that
- the client will actually update address information or even return
- that information to the user.
-
- Alternately,
-
- * Servers MAY reject or bounce messages when they are not
- deliverable when addressed. When they do so, they MAY either
- provide address-updating information with a 551 code, or may
- reject the message as undeliverable with a 550 code and no
- address-specific information. But, if a 551 code is used, they
- MUST NOT assume that the client will actually update address
- information or even return that information to the user.
-
- SMTP server implementations that support the 251 and/or 551 reply
- codes are strongly encouraged to provide configuration mechanisms so
- that sites which conclude that they would undesirably disclose
- information can disable or restrict their use.
-
-
-
-Klensin Standards Track [Page 19]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
-3.5 Commands for Debugging Addresses
-
-3.5.1 Overview
-
- SMTP provides commands to verify a user name or obtain the content of
- a mailing list. This is done with the VRFY and EXPN commands, which
- have character string arguments. Implementations SHOULD support VRFY
- and EXPN (however, see section 3.5.2 and 7.3).
-
- For the VRFY command, the string is a user name or a user name and
- domain (see below). If a normal (i.e., 250) response is returned,
- the response MAY include the full name of the user and MUST include
- the mailbox of the user. It MUST be in either of the following
- forms:
-
- User Name <address@hidden>
- address@hidden
-
- When a name that is the argument to VRFY could identify more than one
- mailbox, the server MAY either note the ambiguity or identify the
- alternatives. In other words, any of the following are legitimate
- response to VRFY:
-
- 553 User ambiguous
-
- or
-
- 553- Ambiguous; Possibilities are
- 553-Joe Smith <address@hidden>
- 553-Harry Smith <address@hidden>
- 553 Melvin Smith <address@hidden>
-
- or
-
- 553-Ambiguous; Possibilities
- 553- <address@hidden>
- 553- <address@hidden>
- 553 <address@hidden>
-
- Under normal circumstances, a client receiving a 553 reply would be
- expected to expose the result to the user. Use of exactly the forms
- given, and the "user ambiguous" or "ambiguous" keywords, possibly
- supplemented by extended reply codes such as those described in [34],
- will facilitate automated translation into other languages as needed.
- Of course, a client that was highly automated or that was operating
- in another language than English, might choose to try to translate
- the response, to return some other indication to the user than the
-
-
-
-
-Klensin Standards Track [Page 20]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- literal text of the reply, or to take some automated action such as
- consulting a directory service for additional information before
- reporting to the user.
-
- For the EXPN command, the string identifies a mailing list, and the
- successful (i.e., 250) multiline response MAY include the full name
- of the users and MUST give the mailboxes on the mailing list.
-
- In some hosts the distinction between a mailing list and an alias for
- a single mailbox is a bit fuzzy, since a common data structure may
- hold both types of entries, and it is possible to have mailing lists
- containing only one mailbox. If a request is made to apply VRFY to a
- mailing list, a positive response MAY be given if a message so
- addressed would be delivered to everyone on the list, otherwise an
- error SHOULD be reported (e.g., "550 That is a mailing list, not a
- user" or "252 Unable to verify members of mailing list"). If a
- request is made to expand a user name, the server MAY return a
- positive response consisting of a list containing one name, or an
- error MAY be reported (e.g., "550 That is a user name, not a mailing
- list").
-
- In the case of a successful multiline reply (normal for EXPN) exactly
- one mailbox is to be specified on each line of the reply. The case
- of an ambiguous request is discussed above.
-
- "User name" is a fuzzy term and has been used deliberately. An
- implementation of the VRFY or EXPN commands MUST include at least
- recognition of local mailboxes as "user names". However, since
- current Internet practice often results in a single host handling
- mail for multiple domains, hosts, especially hosts that provide this
- functionality, SHOULD accept the "address@hidden" form as a "user
- name"; hosts MAY also choose to recognize other strings as "user
- names".
-
- The case of expanding a mailbox list requires a multiline reply, such
- as:
-
- C: EXPN Example-People
- S: 250-Jon Postel <address@hidden>
- S: 250-Fred Fonebone <address@hidden>
- S: 250 Sam Q. Smith <address@hidden>
-
- or
-
- C: EXPN Executive-Washroom-List
- S: 550 Access Denied to You.
-
-
-
-
-
-Klensin Standards Track [Page 21]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- The character string arguments of the VRFY and EXPN commands cannot
- be further restricted due to the variety of implementations of the
- user name and mailbox list concepts. On some systems it may be
- appropriate for the argument of the EXPN command to be a file name
- for a file containing a mailing list, but again there are a variety
- of file naming conventions in the Internet. Similarly, historical
- variations in what is returned by these commands are such that the
- response SHOULD be interpreted very carefully, if at all, and SHOULD
- generally only be used for diagnostic purposes.
-
-3.5.2 VRFY Normal Response
-
- When normal (2yz or 551) responses are returned from a VRFY or EXPN
- request, the reply normally includes the mailbox name, i.e.,
- "<address@hidden>", where "domain" is a fully qualified domain
- name, MUST appear in the syntax. In circumstances exceptional enough
- to justify violating the intent of this specification, free-form text
- MAY be returned. In order to facilitate parsing by both computers
- and people, addresses SHOULD appear in pointed brackets. When
- addresses, rather than free-form debugging information, are returned,
- EXPN and VRFY MUST return only valid domain addresses that are usable
- in SMTP RCPT commands. Consequently, if an address implies delivery
- to a program or other system, the mailbox name used to reach that
- target MUST be given. Paths (explicit source routes) MUST NOT be
- returned by VRFY or EXPN.
-
- Server implementations SHOULD support both VRFY and EXPN. For
- security reasons, implementations MAY provide local installations a
- way to disable either or both of these commands through configuration
- options or the equivalent. When these commands are supported, they
- are not required to work across relays when relaying is supported.
- Since they were both optional in RFC 821, they MUST be listed as
- service extensions in an EHLO response, if they are supported.
-
-3.5.3 Meaning of VRFY or EXPN Success Response
-
- A server MUST NOT return a 250 code in response to a VRFY or EXPN
- command unless it has actually verified the address. In particular,
- a server MUST NOT return 250 if all it has done is to verify that the
- syntax given is valid. In that case, 502 (Command not implemented)
- or 500 (Syntax error, command unrecognized) SHOULD be returned. As
- stated elsewhere, implementation (in the sense of actually validating
- addresses and returning information) of VRFY and EXPN are strongly
- recommended. Hence, implementations that return 500 or 502 for VRFY
- are not in full compliance with this specification.
-
-
-
-
-
-
-Klensin Standards Track [Page 22]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- There may be circumstances where an address appears to be valid but
- cannot reasonably be verified in real time, particularly when a
- server is acting as a mail exchanger for another server or domain.
- "Apparent validity" in this case would normally involve at least
- syntax checking and might involve verification that any domains
- specified were ones to which the host expected to be able to relay
- mail. In these situations, reply code 252 SHOULD be returned. These
- cases parallel the discussion of RCPT verification discussed in
- section 2.1. Similarly, the discussion in section 3.4 applies to the
- use of reply codes 251 and 551 with VRFY (and EXPN) to indicate
- addresses that are recognized but that would be forwarded or bounced
- were mail received for them. Implementations generally SHOULD be
- more aggressive about address verification in the case of VRFY than
- in the case of RCPT, even if it takes a little longer to do so.
-
-3.5.4 Semantics and Applications of EXPN
-
- EXPN is often very useful in debugging and understanding problems
- with mailing lists and multiple-target-address aliases. Some systems
- have attempted to use source expansion of mailing lists as a means of
- eliminating duplicates. The propagation of aliasing systems with
- mail on the Internet, for hosts (typically with MX and CNAME DNS
- records), for mailboxes (various types of local host aliases), and in
- various proxying arrangements, has made it nearly impossible for
- these strategies to work consistently, and mail systems SHOULD NOT
- attempt them.
-
-3.6 Domains
-
- Only resolvable, fully-qualified, domain names (FQDNs) are permitted
- when domain names are used in SMTP. In other words, names that can
- be resolved to MX RRs or A RRs (as discussed in section 5) are
- permitted, as are CNAME RRs whose targets can be resolved, in turn,
- to MX or A RRs. Local nicknames or unqualified names MUST NOT be
- used. There are two exceptions to the rule requiring FQDNs:
-
- - The domain name given in the EHLO command MUST BE either a primary
- host name (a domain name that resolves to an A RR) or, if the host
- has no name, an address literal as described in section 4.1.1.1.
-
- - The reserved mailbox name "postmaster" may be used in a RCPT
- command without domain qualification (see section 4.1.1.3) and
- MUST be accepted if so used.
-
-
-
-
-
-
-
-
-Klensin Standards Track [Page 23]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
-3.7 Relaying
-
- In general, the availability of Mail eXchanger records in the domain
- name system [22, 27] makes the use of explicit source routes in the
- Internet mail system unnecessary. Many historical problems with
- their interpretation have made their use undesirable. SMTP clients
- SHOULD NOT generate explicit source routes except under unusual
- circumstances. SMTP servers MAY decline to act as mail relays or to
- accept addresses that specify source routes. When route information
- is encountered, SMTP servers are also permitted to ignore the route
- information and simply send to the final destination specified as the
- last element in the route and SHOULD do so. There has been an
- invalid practice of using names that do not appear in the DNS as
- destination names, with the senders counting on the intermediate
- hosts specified in source routing to resolve any problems. If source
- routes are stripped, this practice will cause failures. This is one
- of several reasons why SMTP clients MUST NOT generate invalid source
- routes or depend on serial resolution of names.
-
- When source routes are not used, the process described in RFC 821 for
- constructing a reverse-path from the forward-path is not applicable
- and the reverse-path at the time of delivery will simply be the
- address that appeared in the MAIL command.
-
- A relay SMTP server is usually the target of a DNS MX record that
- designates it, rather than the final delivery system. The relay
- server may accept or reject the task of relaying the mail in the same
- way it accepts or rejects mail for a local user. If it accepts the
- task, it then becomes an SMTP client, establishes a transmission
- channel to the next SMTP server specified in the DNS (according to
- the rules in section 5), and sends it the mail. If it declines to
- relay mail to a particular address for policy reasons, a 550 response
- SHOULD be returned.
-
- Many mail-sending clients exist, especially in conjunction with
- facilities that receive mail via POP3 or IMAP, that have limited
- capability to support some of the requirements of this specification,
- such as the ability to queue messages for subsequent delivery
- attempts. For these clients, it is common practice to make private
- arrangements to send all messages to a single server for processing
- and subsequent distribution. SMTP, as specified here, is not ideally
- suited for this role, and work is underway on standardized mail
- submission protocols that might eventually supercede the current
- practices. In any event, because these arrangements are private and
- fall outside the scope of this specification, they are not described
- here.
-
-
-
-
-
-Klensin Standards Track [Page 24]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- It is important to note that MX records can point to SMTP servers
- which act as gateways into other environments, not just SMTP relays
- and final delivery systems; see sections 3.8 and 5.
-
- If an SMTP server has accepted the task of relaying the mail and
- later finds that the destination is incorrect or that the mail cannot
- be delivered for some other reason, then it MUST construct an
- "undeliverable mail" notification message and send it to the
- originator of the undeliverable mail (as indicated by the reverse-
- path). Formats specified for non-delivery reports by other standards
- (see, for example, [24, 25]) SHOULD be used if possible.
-
- This notification message must be from the SMTP server at the relay
- host or the host that first determines that delivery cannot be
- accomplished. Of course, SMTP servers MUST NOT send notification
- messages about problems transporting notification messages. One way
- to prevent loops in error reporting is to specify a null reverse-path
- in the MAIL command of a notification message. When such a message
- is transmitted the reverse-path MUST be set to null (see section
- 4.5.5 for additional discussion). A MAIL command with a null
- reverse-path appears as follows:
-
- MAIL FROM:<>
-
- As discussed in section 2.4.1, a relay SMTP has no need to inspect or
- act upon the headers or body of the message data and MUST NOT do so
- except to add its own "Received:" header (section 4.4) and,
- optionally, to attempt to detect looping in the mail system (see
- section 6.2).
-
-3.8 Mail Gatewaying
-
- While the relay function discussed above operates within the Internet
- SMTP transport service environment, MX records or various forms of
- explicit routing may require that an intermediate SMTP server perform
- a translation function between one transport service and another. As
- discussed in section 2.3.8, when such a system is at the boundary
- between two transport service environments, we refer to it as a
- "gateway" or "gateway SMTP".
-
- Gatewaying mail between different mail environments, such as
- different mail formats and protocols, is complex and does not easily
- yield to standardization. However, some general requirements may be
- given for a gateway between the Internet and another mail
- environment.
-
-
-
-
-
-
-Klensin Standards Track [Page 25]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
-3.8.1 Header Fields in Gatewaying
-
- Header fields MAY be rewritten when necessary as messages are
- gatewayed across mail environment boundaries. This may involve
- inspecting the message body or interpreting the local-part of the
- destination address in spite of the prohibitions in section 2.4.1.
-
- Other mail systems gatewayed to the Internet often use a subset of
- RFC 822 headers or provide similar functionality with a different
- syntax, but some of these mail systems do not have an equivalent to
- the SMTP envelope. Therefore, when a message leaves the Internet
- environment, it may be necessary to fold the SMTP envelope
- information into the message header. A possible solution would be to
- create new header fields to carry the envelope information (e.g.,
- "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would require
- changes in mail programs in foreign environments and might risk
- disclosure of private information (see section 7.2).
-
-3.8.2 Received Lines in Gatewaying
-
- When forwarding a message into or out of the Internet environment, a
- gateway MUST prepend a Received: line, but it MUST NOT alter in any
- way a Received: line that is already in the header.
-
- "Received:" fields of messages originating from other environments
- may not conform exactly to this specification. However, the most
- important use of Received: lines is for debugging mail faults, and
- this debugging can be severely hampered by well-meaning gateways that
- try to "fix" a Received: line. As another consequence of trace
- fields arising in non-SMTP environments, receiving systems MUST NOT
- reject mail based on the format of a trace field and SHOULD be
- extremely robust in the light of unexpected information or formats in
- those fields.
-
- The gateway SHOULD indicate the environment and protocol in the "via"
- clauses of Received field(s) that it supplies.
-
-3.8.3 Addresses in Gatewaying
-
- From the Internet side, the gateway SHOULD accept all valid address
- formats in SMTP commands and in RFC 822 headers, and all valid RFC
- 822 messages. Addresses and headers generated by gateways MUST
- conform to applicable Internet standards (including this one and RFC
- 822). Gateways are, of course, subject to the same rules for
- handling source routes as those described for other SMTP systems in
- section 3.3.
-
-
-
-
-
-Klensin Standards Track [Page 26]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
-3.8.4 Other Header Fields in Gatewaying
-
- The gateway MUST ensure that all header fields of a message that it
- forwards into the Internet mail environment meet the requirements for
- Internet mail. In particular, all addresses in "From:", "To:",
- "Cc:", etc., fields MUST be transformed (if necessary) to satisfy RFC
- 822 syntax, MUST reference only fully-qualified domain names, and
- MUST be effective and useful for sending replies. The translation
- algorithm used to convert mail from the Internet protocols to another
- environment's protocol SHOULD ensure that error messages from the
- foreign mail environment are delivered to the return path from the
- SMTP envelope, not to the sender listed in the "From:" field (or
- other fields) of the RFC 822 message.
-
-3.8.5 Envelopes in Gatewaying
-
- Similarly, when forwarding a message from another environment into
- the Internet, the gateway SHOULD set the envelope return path in
- accordance with an error message return address, if supplied by the
- foreign environment. If the foreign environment has no equivalent
- concept, the gateway must select and use a best approximation, with
- the message originator's address as the default of last resort.
-
-3.9 Terminating Sessions and Connections
-
- An SMTP connection is terminated when the client sends a QUIT
- command. The server responds with a positive reply code, after which
- it closes the connection.
-
- An SMTP server MUST NOT intentionally close the connection except:
-
- - After receiving a QUIT command and responding with a 221 reply.
-
- - After detecting the need to shut down the SMTP service and
- returning a 421 response code. This response code can be issued
- after the server receives any command or, if necessary,
- asynchronously from command receipt (on the assumption that the
- client will receive it after the next command is issued).
-
- In particular, a server that closes connections in response to
- commands that are not understood is in violation of this
- specification. Servers are expected to be tolerant of unknown
- commands, issuing a 500 reply and awaiting further instructions from
- the client.
-
-
-
-
-
-
-
-Klensin Standards Track [Page 27]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- An SMTP server which is forcibly shut down via external means SHOULD
- attempt to send a line containing a 421 response code to the SMTP
- client before exiting. The SMTP client will normally read the 421
- response code after sending its next command.
-
- SMTP clients that experience a connection close, reset, or other
- communications failure due to circumstances not under their control
- (in violation of the intent of this specification but sometimes
- unavoidable) SHOULD, to maintain the robustness of the mail system,
- treat the mail transaction as if a 451 response had been received and
- act accordingly.
-
-3.10 Mailing Lists and Aliases
-
- An SMTP-capable host SHOULD support both the alias and the list
- models of address expansion for multiple delivery. When a message is
- delivered or forwarded to each address of an expanded list form, the
- return address in the envelope ("MAIL FROM:") MUST be changed to be
- the address of a person or other entity who administers the list.
- However, in this case, the message header [32] MUST be left
- unchanged; in particular, the "From" field of the message header is
- unaffected.
-
- An important mail facility is a mechanism for multi-destination
- delivery of a single message, by transforming (or "expanding" or
- "exploding") a pseudo-mailbox address into a list of destination
- mailbox addresses. When a message is sent to such a pseudo-mailbox
- (sometimes called an "exploder"), copies are forwarded or
- redistributed to each mailbox in the expanded list. Servers SHOULD
- simply utilize the addresses on the list; application of heuristics
- or other matching rules to eliminate some addresses, such as that of
- the originator, is strongly discouraged. We classify such a pseudo-
- mailbox as an "alias" or a "list", depending upon the expansion
- rules.
-
-3.10.1 Alias
-
- To expand an alias, the recipient mailer simply replaces the pseudo-
- mailbox address in the envelope with each of the expanded addresses
- in turn; the rest of the envelope and the message body are left
- unchanged. The message is then delivered or forwarded to each
- expanded address.
-
-3.10.2 List
-
- A mailing list may be said to operate by "redistribution" rather than
- by "forwarding". To expand a list, the recipient mailer replaces the
- pseudo-mailbox address in the envelope with all of the expanded
-
-
-
-Klensin Standards Track [Page 28]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- addresses. The return address in the envelope is changed so that all
- error messages generated by the final deliveries will be returned to
- a list administrator, not to the message originator, who generally
- has no control over the contents of the list and will typically find
- error messages annoying.
-
-4. The SMTP Specifications
-
-4.1 SMTP Commands
-
-4.1.1 Command Semantics and Syntax
-
- The SMTP commands define the mail transfer or the mail system
- function requested by the user. SMTP commands are character strings
- terminated by <CRLF>. The commands themselves are alphabetic
- characters terminated by <SP> if parameters follow and <CRLF>
- otherwise. (In the interest of improved interoperability, SMTP
- receivers are encouraged to tolerate trailing white space before the
- terminating <CRLF>.) The syntax of the local part of a mailbox must
- conform to receiver site conventions and the syntax specified in
- section 4.1.2. The SMTP commands are discussed below. The SMTP
- replies are discussed in section 4.2.
-
- A mail transaction involves several data objects which are
- communicated as arguments to different commands. The reverse-path is
- the argument of the MAIL command, the forward-path is the argument of
- the RCPT command, and the mail data is the argument of the DATA
- command. These arguments or data objects must be transmitted and
- held pending the confirmation communicated by the end of mail data
- indication which finalizes the transaction. The model for this is
- that distinct buffers are provided to hold the types of data objects,
- that is, there is a reverse-path buffer, a forward-path buffer, and a
- mail data buffer. Specific commands cause information to be appended
- to a specific buffer, or cause one or more buffers to be cleared.
-
- Several commands (RSET, DATA, QUIT) are specified as not permitting
- parameters. In the absence of specific extensions offered by the
- server and accepted by the client, clients MUST NOT send such
- parameters and servers SHOULD reject commands containing them as
- having invalid syntax.
-
-4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
-
- These commands are used to identify the SMTP client to the SMTP
- server. The argument field contains the fully-qualified domain name
- of the SMTP client if one is available. In situations in which the
- SMTP client system does not have a meaningful domain name (e.g., when
- its address is dynamically allocated and no reverse mapping record is
-
-
-
-Klensin Standards Track [Page 29]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- available), the client SHOULD send an address literal (see section
- 4.1.3), optionally followed by information that will help to identify
- the client system. y The SMTP server identifies itself to the SMTP
- client in the connection greeting reply and in the response to this
- command.
-
- A client SMTP SHOULD start an SMTP session by issuing the EHLO
- command. If the SMTP server supports the SMTP service extensions it
- will give a successful response, a failure response, or an error
- response. If the SMTP server, in violation of this specification,
- does not support any SMTP service extensions it will generate an
- error response. Older client SMTP systems MAY, as discussed above,
- use HELO (as specified in RFC 821) instead of EHLO, and servers MUST
- support the HELO command and reply properly to it. In any event, a
- client MUST issue HELO or EHLO before starting a mail transaction.
-
- These commands, and a "250 OK" reply to one of them, confirm that
- both the SMTP client and the SMTP server are in the initial state,
- that is, there is no transaction in progress and all state tables and
- buffers are cleared.
-
- Syntax:
-
- ehlo = "EHLO" SP Domain CRLF
- helo = "HELO" SP Domain CRLF
-
- Normally, the response to EHLO will be a multiline reply. Each line
- of the response contains a keyword and, optionally, one or more
- parameters. Following the normal syntax for multiline replies, these
- keyworks follow the code (250) and a hyphen for all but the last
- line, and the code and a space for the last line. The syntax for a
- positive response, using the ABNF notation and terminal symbols of
- [8], is:
-
- ehlo-ok-rsp = ( "250" domain [ SP ehlo-greet ] CRLF )
- / ( "250-" domain [ SP ehlo-greet ] CRLF
- *( "250-" ehlo-line CRLF )
- "250" SP ehlo-line CRLF )
-
- ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127)
- ; string of any characters other than CR or LF
-
- ehlo-line = ehlo-keyword *( SP ehlo-param )
-
- ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
- ; additional syntax of ehlo-params depends on
- ; ehlo-keyword
-
-
-
-
-Klensin Standards Track [Page 30]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- ehlo-param = 1*(%d33-127)
- ; any CHAR excluding <SP> and all
- ; control characters (US-ASCII 0-31 inclusive)
-
- Although EHLO keywords may be specified in upper, lower, or mixed
- case, they MUST always be recognized and processed in a case-
- insensitive manner. This is simply an extension of practices
- specified in RFC 821 and section 2.4.1.
-
-4.1.1.2 MAIL (MAIL)
-
- This command is used to initiate a mail transaction in which the mail
- data is delivered to an SMTP server which may, in turn, deliver it to
- one or more mailboxes or pass it on to another system (possibly using
- SMTP). The argument field contains a reverse-path and may contain
- optional parameters. In general, the MAIL command may be sent only
- when no mail transaction is in progress, see section 4.1.4.
-
- The reverse-path consists of the sender mailbox. Historically, that
- mailbox might optionally have been preceded by a list of hosts, but
- that behavior is now deprecated (see appendix C). In some types of
- reporting messages for which a reply is likely to cause a mail loop
- (for example, mail delivery and nondelivery notifications), the
- reverse-path may be null (see section 3.7).
-
- This command clears the reverse-path buffer, the forward-path buffer,
- and the mail data buffer; and inserts the reverse-path information
- from this command into the reverse-path buffer.
-
- If service extensions were negotiated, the MAIL command may also
- carry parameters associated with a particular service extension.
-
- Syntax:
-
- "MAIL FROM:" ("<>" / Reverse-Path)
- [SP Mail-parameters] CRLF
-
-4.1.1.3 RECIPIENT (RCPT)
-
- This command is used to identify an individual recipient of the mail
- data; multiple recipients are specified by multiple use of this
- command. The argument field contains a forward-path and may contain
- optional parameters.
-
- The forward-path normally consists of the required destination
- mailbox. Sending systems SHOULD not generate the optional list of
- hosts known as a source route. Receiving systems MUST recognize
-
-
-
-
-Klensin Standards Track [Page 31]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- source route syntax but SHOULD strip off the source route
- specification and utilize the domain name associated with the mailbox
- as if the source route had not been provided.
-
- Similarly, relay hosts SHOULD strip or ignore source routes, and
- names MUST NOT be copied into the reverse-path. When mail reaches
- its ultimate destination (the forward-path contains only a
- destination mailbox), the SMTP server inserts it into the destination
- mailbox in accordance with its host mail conventions.
-
- For example, mail received at relay host xyz.com with envelope
- commands
-
- MAIL FROM:<address@hidden>
- RCPT TO:<@hosta.int,@jkl.org:address@hidden>
-
- will normally be sent directly on to host d.bar.org with envelope
- commands
-
- MAIL FROM:<address@hidden>
- RCPT TO:<address@hidden>
-
- As provided in appendix C, xyz.com MAY also choose to relay the
- message to hosta.int, using the envelope commands
-
- MAIL FROM:<address@hidden>
- RCPT TO:<@hosta.int,@jkl.org:address@hidden>
-
- or to jkl.org, using the envelope commands
-
- MAIL FROM:<address@hidden>
- RCPT TO:<@jkl.org:address@hidden>
-
- Of course, since hosts are not required to relay mail at all, xyz.com
- may also reject the message entirely when the RCPT command is
- received, using a 550 code (since this is a "policy reason").
-
- If service extensions were negotiated, the RCPT command may also
- carry parameters associated with a particular service extension
- offered by the server. The client MUST NOT transmit parameters other
- than those associated with a service extension offered by the server
- in its EHLO response.
-
-Syntax:
- "RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>" / Forward-Path)
- [SP Rcpt-parameters] CRLF
-
-
-
-
-
-Klensin Standards Track [Page 32]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
-4.1.1.4 DATA (DATA)
-
- The receiver normally sends a 354 response to DATA, and then treats
- the lines (strings ending in <CRLF> sequences, as described in
- section 2.3.7) following the command as mail data from the sender.
- This command causes the mail data to be appended to the mail data
- buffer. The mail data may contain any of the 128 ASCII character
- codes, although experience has indicated that use of control
- characters other than SP, HT, CR, and LF may cause problems and
- SHOULD be avoided when possible.
-
- The mail data is terminated by a line containing only a period, that
- is, the character sequence "<CRLF>.<CRLF>" (see section 4.5.2). This
- is the end of mail data indication. Note that the first <CRLF> of
- this terminating sequence is also the <CRLF> that ends the final line
- of the data (message text) or, if there was no data, ends the DATA
- command itself. An extra <CRLF> MUST NOT be added, as that would
- cause an empty line to be added to the message. The only exception
- to this rule would arise if the message body were passed to the
- originating SMTP-sender with a final "line" that did not end in
- <CRLF>; in that case, the originating SMTP system MUST either reject
- the message as invalid or add <CRLF> in order to have the receiving
- SMTP server recognize the "end of data" condition.
-
- The custom of accepting lines ending only in <LF>, as a concession to
- non-conforming behavior on the part of some UNIX systems, has proven
- to cause more interoperability problems than it solves, and SMTP
- server systems MUST NOT do this, even in the name of improved
- robustness. In particular, the sequence "<LF>.<LF>" (bare line
- feeds, without carriage returns) MUST NOT be treated as equivalent to
- <CRLF>.<CRLF> as the end of mail data indication.
-
- Receipt of the end of mail data indication requires the server to
- process the stored mail transaction information. This processing
- consumes the information in the reverse-path buffer, the forward-path
- buffer, and the mail data buffer, and on the completion of this
- command these buffers are cleared. If the processing is successful,
- the receiver MUST send an OK reply. If the processing fails the
- receiver MUST send a failure reply. The SMTP model does not allow
- for partial failures at this point: either the message is accepted by
- the server for delivery and a positive response is returned or it is
- not accepted and a failure reply is returned. In sending a positive
- completion reply to the end of data indication, the receiver takes
- full responsibility for the message (see section 6.1). Errors that
- are diagnosed subsequently MUST be reported in a mail message, as
- discussed in section 4.4.
-
-
-
-
-
-Klensin Standards Track [Page 33]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- When the SMTP server accepts a message either for relaying or for
- final delivery, it inserts a trace record (also referred to
- interchangeably as a "time stamp line" or "Received" line) at the top
- of the mail data. This trace record indicates the identity of the
- host that sent the message, the identity of the host that received
- the message (and is inserting this time stamp), and the date and time
- the message was received. Relayed messages will have multiple time
- stamp lines. Details for formation of these lines, including their
- syntax, is specified in section 4.4.
-
- Additional discussion about the operation of the DATA command appears
- in section 3.3.
-
- Syntax:
- "DATA" CRLF
-
-4.1.1.5 RESET (RSET)
-
- This command specifies that the current mail transaction will be
- aborted. Any stored sender, recipients, and mail data MUST be
- discarded, and all buffers and state tables cleared. The receiver
- MUST send a "250 OK" reply to a RSET command with no arguments. A
- reset command may be issued by the client at any time. It is
- effectively equivalent to a NOOP (i.e., if has no effect) if issued
- immediately after EHLO, before EHLO is issued in the session, after
- an end-of-data indicator has been sent and acknowledged, or
- immediately before a QUIT. An SMTP server MUST NOT close the
- connection as the result of receiving a RSET; that action is reserved
- for QUIT (see section 4.1.1.10).
-
- Since EHLO implies some additional processing and response by the
- server, RSET will normally be more efficient than reissuing that
- command, even though the formal semantics are the same.
-
- There are circumstances, contrary to the intent of this
- specification, in which an SMTP server may receive an indication that
- the underlying TCP connection has been closed or reset. To preserve
- the robustness of the mail system, SMTP servers SHOULD be prepared
- for this condition and SHOULD treat it as if a QUIT had been received
- before the connection disappeared.
-
- Syntax:
- "RSET" CRLF
-
-
-
-
-
-
-
-
-Klensin Standards Track [Page 34]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
-4.1.1.6 VERIFY (VRFY)
-
- This command asks the receiver to confirm that the argument
- identifies a user or mailbox. If it is a user name, information is
- returned as specified in section 3.5.
-
- This command has no effect on the reverse-path buffer, the forward-
- path buffer, or the mail data buffer.
-
- Syntax:
- "VRFY" SP String CRLF
-
-4.1.1.7 EXPAND (EXPN)
-
- This command asks the receiver to confirm that the argument
- identifies a mailing list, and if so, to return the membership of
- that list. If the command is successful, a reply is returned
- containing information as described in section 3.5. This reply will
- have multiple lines except in the trivial case of a one-member list.
-
- This command has no effect on the reverse-path buffer, the forward-
- path buffer, or the mail data buffer and may be issued at any time.
-
- Syntax:
- "EXPN" SP String CRLF
-
-4.1.1.8 HELP (HELP)
-
- This command causes the server to send helpful information to the
- client. The command MAY take an argument (e.g., any command name)
- and return more specific information as a response.
-
- This command has no effect on the reverse-path buffer, the forward-
- path buffer, or the mail data buffer and may be issued at any time.
-
- SMTP servers SHOULD support HELP without arguments and MAY support it
- with arguments.
-
- Syntax:
- "HELP" [ SP String ] CRLF
-
-4.1.1.9 NOOP (NOOP)
-
- This command does not affect any parameters or previously entered
- commands. It specifies no action other than that the receiver send
- an OK reply.
-
-
-
-
-
-Klensin Standards Track [Page 35]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- This command has no effect on the reverse-path buffer, the forward-
- path buffer, or the mail data buffer and may be issued at any time.
- If a parameter string is specified, servers SHOULD ignore it.
-
- Syntax:
- "NOOP" [ SP String ] CRLF
-
-4.1.1.10 QUIT (QUIT)
-
- This command specifies that the receiver MUST send an OK reply, and
- then close the transmission channel.
-
- The receiver MUST NOT intentionally close the transmission channel
- until it receives and replies to a QUIT command (even if there was an
- error). The sender MUST NOT intentionally close the transmission
- channel until it sends a QUIT command and SHOULD wait until it
- receives the reply (even if there was an error response to a previous
- command). If the connection is closed prematurely due to violations
- of the above or system or network failure, the server MUST cancel any
- pending transaction, but not undo any previously completed
- transaction, and generally MUST act as if the command or transaction
- in progress had received a temporary error (i.e., a 4yz response).
-
- The QUIT command may be issued at any time.
-
- Syntax:
- "QUIT" CRLF
-
-4.1.2 Command Argument Syntax
-
- The syntax of the argument fields of the above commands (using the
- syntax specified in [8] where applicable) is given below. Some of
- the productions given below are used only in conjunction with source
- routes as described in appendix C. Terminals not defined in this
- document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in
- the "core" syntax [8 (section 6)] or in the message format syntax
- [32].
-
- Reverse-path = Path
- Forward-path = Path
- Path = "<" [ A-d-l ":" ] Mailbox ">"
- A-d-l = At-domain *( "," A-d-l )
- ; Note that this form, the so-called "source route",
- ; MUST BE accepted, SHOULD NOT be generated, and SHOULD be
- ; ignored.
- At-domain = "@" domain
- Mail-parameters = esmtp-param *(SP esmtp-param)
- Rcpt-parameters = esmtp-param *(SP esmtp-param)
-
-
-
-Klensin Standards Track [Page 36]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- esmtp-param = esmtp-keyword ["=" esmtp-value]
- esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
- esmtp-value = 1*(%d33-60 / %d62-127)
- ; any CHAR excluding "=", SP, and control characters
- Keyword = Ldh-str
- Argument = Atom
- Domain = (sub-domain 1*("." sub-domain)) / address-literal
- sub-domain = Let-dig [Ldh-str]
-
- address-literal = "[" IPv4-address-literal /
- IPv6-address-literal /
- General-address-literal "]"
- ; See section 4.1.3
-
- Mailbox = Local-part "@" Domain
-
- Local-part = Dot-string / Quoted-string
- ; MAY be case-sensitive
-
- Dot-string = Atom *("." Atom)
-
- Atom = 1*atext
-
- Quoted-string = DQUOTE *qcontent DQUOTE
-
- String = Atom / Quoted-string
-
- While the above definition for Local-part is relatively permissive,
- for maximum interoperability, a host that expects to receive mail
- SHOULD avoid defining mailboxes where the Local-part requires (or
- uses) the Quoted-string form or where the Local-part is case-
- sensitive. For any purposes that require generating or comparing
- Local-parts (e.g., to specific mailbox names), all quoted forms MUST
- be treated as equivalent and the sending system SHOULD transmit the
- form that uses the minimum quoting possible.
-
- Systems MUST NOT define mailboxes in such a way as to require the use
- in SMTP of non-ASCII characters (octets with the high order bit set
- to one) or ASCII "control characters" (decimal value 0-31 and 127).
- These characters MUST NOT be used in MAIL or RCPT commands or other
- commands that require mailbox names.
-
- Note that the backslash, "\", is a quote character, which is used to
- indicate that the next character is to be used literally (instead of
- its normal interpretation). For example, "Joe\,Smith" indicates a
- single nine character user field with the comma being the fourth
- character of the field.
-
-
-
-
-Klensin Standards Track [Page 37]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- To promote interoperability and consistent with long-standing
- guidance about conservative use of the DNS in naming and applications
- (e.g., see section 2.3.1 of the base DNS document, RFC1035 [22]),
- characters outside the set of alphas, digits, and hyphen MUST NOT
- appear in domain name labels for SMTP clients or servers. In
- particular, the underscore character is not permitted. SMTP servers
- that receive a command in which invalid character codes have been
- employed, and for which there are no other reasons for rejection,
- MUST reject that command with a 501 response.
-
-4.1.3 Address Literals
-
- Sometimes a host is not known to the domain name system and
- communication (and, in particular, communication to report and repair
- the error) is blocked. To bypass this barrier a special literal form
- of the address is allowed as an alternative to a domain name. For
- IPv4 addresses, this form uses four small decimal integers separated
- by dots and enclosed by brackets such as [123.255.37.2], which
- indicates an (IPv4) Internet Address in sequence-of-octets form. For
- IPv6 and other forms of addressing that might eventually be
- standardized, the form consists of a standardized "tag" that
- identifies the address syntax, a colon, and the address itself, in a
- format specified as part of the IPv6 standards [17].
-
- Specifically:
-
- IPv4-address-literal = Snum 3("." Snum)
- IPv6-address-literal = "IPv6:" IPv6-addr
- General-address-literal = Standardized-tag ":" 1*dcontent
- Standardized-tag = Ldh-str
- ; MUST be specified in a standards-track RFC
- ; and registered with IANA
-
- Snum = 1*3DIGIT ; representing a decimal integer
- ; value in the range 0 through 255
- Let-dig = ALPHA / DIGIT
- Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
-
- IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
- IPv6-hex = 1*4HEXDIG
- IPv6-full = IPv6-hex 7(":" IPv6-hex)
- IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":"
- IPv6-hex)]
- ; The "::" represents at least 2 16-bit groups of zeros
- ; No more than 6 groups in addition to the "::" may be
- ; present
- IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
- IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"
-
-
-
-Klensin Standards Track [Page 38]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- [IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal
- ; The "::" represents at least 2 16-bit groups of zeros
- ; No more than 4 groups in addition to the "::" and
- ; IPv4-address-literal may be present
-
-4.1.4 Order of Commands
-
- There are restrictions on the order in which these commands may be
- used.
-
- A session that will contain mail transactions MUST first be
- initialized by the use of the EHLO command. An SMTP server SHOULD
- accept commands for non-mail transactions (e.g., VRFY or EXPN)
- without this initialization.
-
- An EHLO command MAY be issued by a client later in the session. If
- it is issued after the session begins, the SMTP server MUST clear all
- buffers and reset the state exactly as if a RSET command had been
- issued. In other words, the sequence of RSET followed immediately by
- EHLO is redundant, but not harmful other than in the performance cost
- of executing unnecessary commands.
-
- If the EHLO command is not acceptable to the SMTP server, 501, 500,
- or 502 failure replies MUST be returned as appropriate. The SMTP
- server MUST stay in the same state after transmitting these replies
- that it was in before the EHLO was received.
-
- The SMTP client MUST, if possible, ensure that the domain parameter
- to the EHLO command is a valid principal host name (not a CNAME or MX
- name) for its host. If this is not possible (e.g., when the client's
- address is dynamically assigned and the client does not have an
- obvious name), an address literal SHOULD be substituted for the
- domain name and supplemental information provided that will assist in
- identifying the client.
-
- An SMTP server MAY verify that the domain name parameter in the EHLO
- command actually corresponds to the IP address of the client.
- However, the server MUST NOT refuse to accept a message for this
- reason if the verification fails: the information about verification
- failure is for logging and tracing only.
-
- The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time
- during a session, or without previously initializing a session. SMTP
- servers SHOULD process these normally (that is, not return a 503
- code) even if no EHLO command has yet been received; clients SHOULD
- open a session with EHLO before sending these commands.
-
-
-
-
-
-Klensin Standards Track [Page 39]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- If these rules are followed, the example in RFC 821 that shows "550
- access denied to you" in response to an EXPN command is incorrect
- unless an EHLO command precedes the EXPN or the denial of access is
- based on the client's IP address or other authentication or
- authorization-determining mechanisms.
-
- The MAIL command (or the obsolete SEND, SOML, or SAML commands)
- begins a mail transaction. Once started, a mail transaction consists
- of a transaction beginning command, one or more RCPT commands, and a
- DATA command, in that order. A mail transaction may be aborted by
- the RSET (or a new EHLO) command. There may be zero or more
- transactions in a session. MAIL (or SEND, SOML, or SAML) MUST NOT be
- sent if a mail transaction is already open, i.e., it should be sent
- only if no mail transaction had been started in the session, or it
- the previous one successfully concluded with a successful DATA
- command, or if the previous one was aborted with a RSET.
-
- If the transaction beginning command argument is not acceptable, a
- 501 failure reply MUST be returned and the SMTP server MUST stay in
- the same state. If the commands in a transaction are out of order to
- the degree that they cannot be processed by the server, a 503 failure
- reply MUST be returned and the SMTP server MUST stay in the same
- state.
-
- The last command in a session MUST be the QUIT command. The QUIT
- command cannot be used at any other time in a session, but SHOULD be
- used by the client SMTP to request connection closure, even when no
- session opening command was sent and accepted.
-
-4.1.5 Private-use Commands
-
- As specified in section 2.2.2, commands starting in "X" may be used
- by bilateral agreement between the client (sending) and server
- (receiving) SMTP agents. An SMTP server that does not recognize such
- a command is expected to reply with "500 Command not recognized". An
- extended SMTP server MAY list the feature names associated with these
- private commands in the response to the EHLO command.
-
- Commands sent or accepted by SMTP systems that do not start with "X"
- MUST conform to the requirements of section 2.2.2.
-
-4.2 SMTP Replies
-
- Replies to SMTP commands serve to ensure the synchronization of
- requests and actions in the process of mail transfer and to guarantee
- that the SMTP client always knows the state of the SMTP server.
- Every command MUST generate exactly one reply.
-
-
-
-
-Klensin Standards Track [Page 40]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- The details of the command-reply sequence are described in section
- 4.3.
-
- An SMTP reply consists of a three digit number (transmitted as three
- numeric characters) followed by some text unless specified otherwise
- in this document. The number is for use by automata to determine
- what state to enter next; the text is for the human user. The three
- digits contain enough encoded information that the SMTP client need
- not examine the text and may either discard it or pass it on to the
- user, as appropriate. Exceptions are as noted elsewhere in this
- document. In particular, the 220, 221, 251, 421, and 551 reply codes
- are associated with message text that must be parsed and interpreted
- by machines. In the general case, the text may be receiver dependent
- and context dependent, so there are likely to be varying texts for
- each reply code. A discussion of the theory of reply codes is given
- in section 4.2.1. Formally, a reply is defined to be the sequence: a
- three-digit code, <SP>, one line of text, and <CRLF>, or a multiline
- reply (as defined in section 4.2.1). Since, in violation of this
- specification, the text is sometimes not sent, clients which do not
- receive it SHOULD be prepared to process the code alone (with or
- without a trailing space character). Only the EHLO, EXPN, and HELP
- commands are expected to result in multiline replies in normal
- circumstances, however, multiline replies are allowed for any
- command.
-
- In ABNF, server responses are:
-
- Greeting = "220 " Domain [ SP text ] CRLF
- Reply-line = Reply-code [ SP text ] CRLF
-
- where "Greeting" appears only in the 220 response that announces that
- the server is opening its part of the connection.
-
- An SMTP server SHOULD send only the reply codes listed in this
- document. An SMTP server SHOULD use the text shown in the examples
- whenever appropriate.
-
- An SMTP client MUST determine its actions only by the reply code, not
- by the text (except for the "change of address" 251 and 551 and, if
- necessary, 220, 221, and 421 replies); in the general case, any text,
- including no text at all (although senders SHOULD NOT send bare
- codes), MUST be acceptable. The space (blank) following the reply
- code is considered part of the text. Whenever possible, a receiver-
- SMTP SHOULD test the first digit (severity indication) of the reply
- code.
-
-
-
-
-
-
-Klensin Standards Track [Page 41]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- The list of codes that appears below MUST NOT be construed as
- permanent. While the addition of new codes should be a rare and
- significant activity, with supplemental information in the textual
- part of the response being preferred, new codes may be added as the
- result of new Standards or Standards-track specifications.
- Consequently, a sender-SMTP MUST be prepared to handle codes not
- specified in this document and MUST do so by interpreting the first
- digit only.
-
-4.2.1 Reply Code Severities and Theory
-
- The three digits of the reply each have a special significance. The
- first digit denotes whether the response is good, bad or incomplete.
- An unsophisticated SMTP client, or one that receives an unexpected
- code, will be able to determine its next action (proceed as planned,
- redo, retrench, etc.) by examining this first digit. An SMTP client
- that wants to know approximately what kind of error occurred (e.g.,
- mail system error, command syntax error) may examine the second
- digit. The third digit and any supplemental information that may be
- present is reserved for the finest gradation of information.
-
- There are five values for the first digit of the reply code:
-
- 1yz Positive Preliminary reply
- The command has been accepted, but the requested action is being
- held in abeyance, pending confirmation of the information in this
- reply. The SMTP client should send another command specifying
- whether to continue or abort the action. Note: unextended SMTP
- does not have any commands that allow this type of reply, and so
- does not have continue or abort commands.
-
- 2yz Positive Completion reply
- The requested action has been successfully completed. A new
- request may be initiated.
-
- 3yz Positive Intermediate reply
- The command has been accepted, but the requested action is being
- held in abeyance, pending receipt of further information. The
- SMTP client should send another command specifying this
- information. This reply is used in command sequence groups (i.e.,
- in DATA).
-
- 4yz Transient Negative Completion reply
- The command was not accepted, and the requested action did not
- occur. However, the error condition is temporary and the action
- may be requested again. The sender should return to the beginning
- of the command sequence (if any). It is difficult to assign a
- meaning to "transient" when two different sites (receiver- and
-
-
-
-Klensin Standards Track [Page 42]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- sender-SMTP agents) must agree on the interpretation. Each reply
- in this category might have a different time value, but the SMTP
- client is encouraged to try again. A rule of thumb to determine
- whether a reply fits into the 4yz or the 5yz category (see below)
- is that replies are 4yz if they can be successful if repeated
- without any change in command form or in properties of the sender
- or receiver (that is, the command is repeated identically and the
- receiver does not put up a new implementation.)
-
- 5yz Permanent Negative Completion reply
- The command was not accepted and the requested action did not
- occur. The SMTP client is discouraged from repeating the exact
- request (in the same sequence). Even some "permanent" error
- conditions can be corrected, so the human user may want to direct
- the SMTP client to reinitiate the command sequence by direct
- action at some point in the future (e.g., after the spelling has
- been changed, or the user has altered the account status).
-
- The second digit encodes responses in specific categories:
-
- x0z Syntax: These replies refer to syntax errors, syntactically
- correct commands that do not fit any functional category, and
- unimplemented or superfluous commands.
-
- x1z Information: These are replies to requests for information,
- such as status or help.
-
- x2z Connections: These are replies referring to the transmission
- channel.
-
- x3z Unspecified.
-
- x4z Unspecified.
-
- x5z Mail system: These replies indicate the status of the receiver
- mail system vis-a-vis the requested transfer or other mail system
- action.
-
- The third digit gives a finer gradation of meaning in each category
- specified by the second digit. The list of replies illustrates this.
- Each reply text is recommended rather than mandatory, and may even
- change according to the command with which it is associated. On the
- other hand, the reply codes must strictly follow the specifications
- in this section. Receiver implementations should not invent new
- codes for slightly different situations from the ones described here,
- but rather adapt codes already defined.
-
-
-
-
-
-Klensin Standards Track [Page 43]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- For example, a command such as NOOP, whose successful execution does
- not offer the SMTP client any new information, will return a 250
- reply. The reply is 502 when the command requests an unimplemented
- non-site-specific action. A refinement of that is the 504 reply for
- a command that is implemented, but that requests an unimplemented
- parameter.
-
- The reply text may be longer than a single line; in these cases the
- complete text must be marked so the SMTP client knows when it can
- stop reading the reply. This requires a special format to indicate a
- multiple line reply.
-
- The format for multiline replies requires that every line, except the
- last, begin with the reply code, followed immediately by a hyphen,
- "-" (also known as minus), followed by text. The last line will
- begin with the reply code, followed immediately by <SP>, optionally
- some text, and <CRLF>. As noted above, servers SHOULD send the <SP>
- if subsequent text is not sent, but clients MUST be prepared for it
- to be omitted.
-
- For example:
-
- 123-First line
- 123-Second line
- 123-234 text beginning with numbers
- 123 The last line
-
- In many cases the SMTP client then simply needs to search for a line
- beginning with the reply code followed by <SP> or <CRLF> and ignore
- all preceding lines. In a few cases, there is important data for the
- client in the reply "text". The client will be able to identify
- these cases from the current context.
-
-4.2.2 Reply Codes by Function Groups
-
- 500 Syntax error, command unrecognized
- (This may include errors such as command line too long)
- 501 Syntax error in parameters or arguments
- 502 Command not implemented (see section 4.2.4)
- 503 Bad sequence of commands
- 504 Command parameter not implemented
-
- 211 System status, or system help reply
- 214 Help message
- (Information on how to use the receiver or the meaning of a
- particular non-standard command; this reply is useful only
- to the human user)
-
-
-
-
-Klensin Standards Track [Page 44]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- 220 <domain> Service ready
- 221 <domain> Service closing transmission channel
- 421 <domain> Service not available, closing transmission channel
- (This may be a reply to any command if the service knows it
- must shut down)
-
- 250 Requested mail action okay, completed
- 251 User not local; will forward to <forward-path>
- (See section 3.4)
- 252 Cannot VRFY user, but will accept message and attempt
- delivery
- (See section 3.5.3)
- 450 Requested mail action not taken: mailbox unavailable
- (e.g., mailbox busy)
- 550 Requested action not taken: mailbox unavailable
- (e.g., mailbox not found, no access, or command rejected
- for policy reasons)
- 451 Requested action aborted: error in processing
- 551 User not local; please try <forward-path>
- (See section 3.4)
- 452 Requested action not taken: insufficient system storage
- 552 Requested mail action aborted: exceeded storage allocation
- 553 Requested action not taken: mailbox name not allowed
- (e.g., mailbox syntax incorrect)
- 354 Start mail input; end with <CRLF>.<CRLF>
- 554 Transaction failed (Or, in the case of a connection-opening
- response, "No SMTP service here")
-
-4.2.3 Reply Codes in Numeric Order
-
- 211 System status, or system help reply
- 214 Help message
- (Information on how to use the receiver or the meaning of a
- particular non-standard command; this reply is useful only
- to the human user)
- 220 <domain> Service ready
- 221 <domain> Service closing transmission channel
- 250 Requested mail action okay, completed
- 251 User not local; will forward to <forward-path>
- (See section 3.4)
- 252 Cannot VRFY user, but will accept message and attempt
- delivery
- (See section 3.5.3)
-
- 354 Start mail input; end with <CRLF>.<CRLF>
-
-
-
-
-
-
-Klensin Standards Track [Page 45]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- 421 <domain> Service not available, closing transmission channel
- (This may be a reply to any command if the service knows it
- must shut down)
- 450 Requested mail action not taken: mailbox unavailable
- (e.g., mailbox busy)
- 451 Requested action aborted: local error in processing
- 452 Requested action not taken: insufficient system storage
- 500 Syntax error, command unrecognized
- (This may include errors such as command line too long)
- 501 Syntax error in parameters or arguments
- 502 Command not implemented (see section 4.2.4)
- 503 Bad sequence of commands
- 504 Command parameter not implemented
- 550 Requested action not taken: mailbox unavailable
- (e.g., mailbox not found, no access, or command rejected
- for policy reasons)
- 551 User not local; please try <forward-path>
- (See section 3.4)
- 552 Requested mail action aborted: exceeded storage allocation
- 553 Requested action not taken: mailbox name not allowed
- (e.g., mailbox syntax incorrect)
- 554 Transaction failed (Or, in the case of a connection-opening
- response, "No SMTP service here")
-
-4.2.4 Reply Code 502
-
- Questions have been raised as to when reply code 502 (Command not
- implemented) SHOULD be returned in preference to other codes. 502
- SHOULD be used when the command is actually recognized by the SMTP
- server, but not implemented. If the command is not recognized, code
- 500 SHOULD be returned. Extended SMTP systems MUST NOT list
- capabilities in response to EHLO for which they will return 502 (or
- 500) replies.
-
-4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
-
- When an SMTP server returns a positive completion status (2yz code)
- after the DATA command is completed with <CRLF>.<CRLF>, it accepts
- responsibility for:
-
- - delivering the message (if the recipient mailbox exists), or
-
- - if attempts to deliver the message fail due to transient
- conditions, retrying delivery some reasonable number of times at
- intervals as specified in section 4.5.4.
-
-
-
-
-
-
-Klensin Standards Track [Page 46]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- - if attempts to deliver the message fail due to permanent
- conditions, or if repeated attempts to deliver the message fail
- due to transient conditions, returning appropriate notification to
- the sender of the original message (using the address in the SMTP
- MAIL command).
-
- When an SMTP server returns a permanent error status (5yz) code after
- the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
- any subsequent attempt to deliver that message. The SMTP client
- retains responsibility for delivery of that message and may either
- return it to the user or requeue it for a subsequent attempt (see
- section 4.5.4.1).
-
- The user who originated the message SHOULD be able to interpret the
- return of a transient failure status (by mail message or otherwise)
- as a non-delivery indication, just as a permanent failure would be
- interpreted. I.e., if the client SMTP successfully handles these
- conditions, the user will not receive such a reply.
-
- When an SMTP server returns a permanent error status (5yz) code after
- the DATA command is completely with <CRLF>.<CRLF>, it MUST NOT make
- any subsequent attempt to deliver the message. As with temporary
- error status codes, the SMTP client retains responsibility for the
- message, but SHOULD not again attempt delivery to the same server
- without user review and intervention of the message.
-
-4.3 Sequencing of Commands and Replies
-
-4.3.1 Sequencing Overview
-
- The communication between the sender and receiver is an alternating
- dialogue, controlled by the sender. As such, the sender issues a
- command and the receiver responds with a reply. Unless other
- arrangements are negotiated through service extensions, the sender
- MUST wait for this response before sending further commands.
-
- One important reply is the connection greeting. Normally, a receiver
- will send a 220 "Service ready" reply when the connection is
- completed. The sender SHOULD wait for this greeting message before
- sending any commands.
-
- Note: all the greeting-type replies have the official name (the
- fully-qualified primary domain name) of the server host as the first
- word following the reply code. Sometimes the host will have no
- meaningful name. See 4.1.3 for a discussion of alternatives in these
- situations.
-
-
-
-
-
-Klensin Standards Track [Page 47]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- For example,
-
- 220 ISIF.USC.EDU Service ready
- or
- 220 mail.foo.com SuperSMTP v 6.1.2 Service ready
- or
- 220 [10.0.0.1] Clueless host service ready
-
- The table below lists alternative success and failure replies for
- each command. These SHOULD be strictly adhered to: a receiver may
- substitute text in the replies, but the meaning and action implied by
- the code numbers and by the specific command reply sequence cannot be
- altered.
-
-4.3.2 Command-Reply Sequences
-
- Each command is listed with its usual possible replies. The prefixes
- used before the possible replies are "I" for intermediate, "S" for
- success, and "E" for error. Since some servers may generate other
- replies under special circumstances, and to allow for future
- extension, SMTP clients SHOULD, when possible, interpret only the
- first digit of the reply and MUST be prepared to deal with
- unrecognized reply codes by interpreting the first digit only.
- Unless extended using the mechanisms described in section 2.2, SMTP
- servers MUST NOT transmit reply codes to an SMTP client that are
- other than three digits or that do not start in a digit between 2 and
- 5 inclusive.
-
- These sequencing rules and, in principle, the codes themselves, can
- be extended or modified by SMTP extensions offered by the server and
- accepted (requested) by the client.
-
- In addition to the codes listed below, any SMTP command can return
- any of the following codes if the corresponding unusual circumstances
- are encountered:
-
- 500 For the "command line too long" case or if the command name was
- not recognized. Note that producing a "command not recognized"
- error in response to the required subset of these commands is a
- violation of this specification.
-
- 501 Syntax error in command or arguments. In order to provide for
- future extensions, commands that are specified in this document as
- not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501
- message if arguments are supplied in the absence of EHLO-
- advertised extensions.
-
- 421 Service shutting down and closing transmission channel
-
-
-
-Klensin Standards Track [Page 48]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- Specific sequences are:
-
- CONNECTION ESTABLISHMENT
- S: 220
- E: 554
- EHLO or HELO
- S: 250
- E: 504, 550
- MAIL
- S: 250
- E: 552, 451, 452, 550, 553, 503
- RCPT
- S: 250, 251 (but see section 3.4 for discussion of 251 and 551)
- E: 550, 551, 552, 553, 450, 451, 452, 503, 550
- DATA
- I: 354 -> data -> S: 250
- E: 552, 554, 451, 452
- E: 451, 554, 503
- RSET
- S: 250
- VRFY
- S: 250, 251, 252
- E: 550, 551, 553, 502, 504
- EXPN
- S: 250, 252
- E: 550, 500, 502, 504
- HELP
- S: 211, 214
- E: 502, 504
- NOOP
- S: 250
- QUIT
- S: 221
-
-4.4 Trace Information
-
- When an SMTP server receives a message for delivery or further
- processing, it MUST insert trace ("time stamp" or "Received")
- information at the beginning of the message content, as discussed in
- section 4.1.1.4.
-
- This line MUST be structured as follows:
-
- - The FROM field, which MUST be supplied in an SMTP environment,
- SHOULD contain both (1) the name of the source host as presented
- in the EHLO command and (2) an address literal containing the IP
- address of the source, determined from the TCP connection.
-
-
-
-
-Klensin Standards Track [Page 49]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- - The ID field MAY contain an "@" as suggested in RFC 822, but this
- is not required.
-
- - The FOR field MAY contain a list of <path> entries when multiple
- RCPT commands have been given. This may raise some security
- issues and is usually not desirable; see section 7.2.
-
- An Internet mail program MUST NOT change a Received: line that was
- previously added to the message header. SMTP servers MUST prepend
- Received lines to messages; they MUST NOT change the order of
- existing lines or insert Received lines in any other location.
-
- As the Internet grows, comparability of Received fields is important
- for detecting problems, especially slow relays. SMTP servers that
- create Received fields SHOULD use explicit offsets in the dates
- (e.g., -0800), rather than time zone names of any type. Local time
- (with an offset) is preferred to UT when feasible. This formulation
- allows slightly more information about local circumstances to be
- specified. If UT is needed, the receiver need merely do some simple
- arithmetic to convert the values. Use of UT loses information about
- the time zone-location of the server. If it is desired to supply a
- time zone name, it SHOULD be included in a comment.
-
- When the delivery SMTP server makes the "final delivery" of a
- message, it inserts a return-path line at the beginning of the mail
- data. This use of return-path is required; mail systems MUST support
- it. The return-path line preserves the information in the <reverse-
- path> from the MAIL command. Here, final delivery means the message
- has left the SMTP environment. Normally, this would mean it had been
- delivered to the destination user or an associated mail drop, but in
- some cases it may be further processed and transmitted by another
- mail system.
-
- It is possible for the mailbox in the return path to be different
- from the actual sender's mailbox, for example, if error responses are
- to be delivered to a special error handling mailbox rather than to
- the message sender. When mailing lists are involved, this
- arrangement is common and useful as a means of directing errors to
- the list maintainer rather than the message originator.
-
- The text above implies that the final mail data will begin with a
- return path line, followed by one or more time stamp lines. These
- lines will be followed by the mail data headers and body [32].
-
- It is sometimes difficult for an SMTP server to determine whether or
- not it is making final delivery since forwarding or other operations
- may occur after the message is accepted for delivery. Consequently,
-
-
-
-
-Klensin Standards Track [Page 50]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- any further (forwarding, gateway, or relay) systems MAY remove the
- return path and rebuild the MAIL command as needed to ensure that
- exactly one such line appears in a delivered message.
-
- A message-originating SMTP system SHOULD NOT send a message that
- already contains a Return-path header. SMTP servers performing a
- relay function MUST NOT inspect the message data, and especially not
- to the extent needed to determine if Return-path headers are present.
- SMTP servers making final delivery MAY remove Return-path headers
- before adding their own.
-
- The primary purpose of the Return-path is to designate the address to
- which messages indicating non-delivery or other mail system failures
- are to be sent. For this to be unambiguous, exactly one return path
- SHOULD be present when the message is delivered. Systems using RFC
- 822 syntax with non-SMTP transports SHOULD designate an unambiguous
- address, associated with the transport envelope, to which error
- reports (e.g., non-delivery messages) should be sent.
-
- Historical note: Text in RFC 822 that appears to contradict the use
- of the Return-path header (or the envelope reverse path address from
- the MAIL command) as the destination for error messages is not
- applicable on the Internet. The reverse path address (as copied into
- the Return-path) MUST be used as the target of any mail containing
- delivery error messages.
-
- In particular:
-
- - a gateway from SMTP->elsewhere SHOULD insert a return-path header,
- unless it is known that the "elsewhere" transport also uses
- Internet domain addresses and maintains the envelope sender
- address separately.
-
- - a gateway from elsewhere->SMTP SHOULD delete any return-path
- header present in the message, and either copy that information to
- the SMTP envelope or combine it with information present in the
- envelope of the other transport system to construct the reverse
- path argument to the MAIL command in the SMTP envelope.
-
- The server must give special treatment to cases in which the
- processing following the end of mail data indication is only
- partially successful. This could happen if, after accepting several
- recipients and the mail data, the SMTP server finds that the mail
- data could be successfully delivered to some, but not all, of the
- recipients. In such cases, the response to the DATA command MUST be
- an OK reply. However, the SMTP server MUST compose and send an
- "undeliverable mail" notification message to the originator of the
- message.
-
-
-
-Klensin Standards Track [Page 51]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- A single notification listing all of the failed recipients or
- separate notification messages MUST be sent for each failed
- recipient. For economy of processing by the sender, the former is
- preferred when possible. All undeliverable mail notification
- messages are sent using the MAIL command (even if they result from
- processing the obsolete SEND, SOML, or SAML commands) and use a null
- return path as discussed in section 3.7.
-
- The time stamp line and the return path line are formally defined as
- follows:
-
-Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
-
-Time-stamp-line = "Received:" FWS Stamp <CRLF>
-
-Stamp = From-domain By-domain Opt-info ";" FWS date-time
-
- ; where "date-time" is as defined in [32]
- ; but the "obs-" forms, especially two-digit
- ; years, are prohibited in SMTP and MUST NOT be used.
-
-From-domain = "FROM" FWS Extended-Domain CFWS
-
-By-domain = "BY" FWS Extended-Domain CFWS
-
-Extended-Domain = Domain /
- ( Domain FWS "(" TCP-info ")" ) /
- ( Address-literal FWS "(" TCP-info ")" )
-
-TCP-info = Address-literal / ( Domain FWS Address-literal )
- ; Information derived by server from TCP connection
- ; not client EHLO.
-
-Opt-info = [Via] [With] [ID] [For]
-
-Via = "VIA" FWS Link CFWS
-
-With = "WITH" FWS Protocol CFWS
-
-ID = "ID" FWS String / msg-id CFWS
-
-For = "FOR" FWS 1*( Path / Mailbox ) CFWS
-
-Link = "TCP" / Addtl-Link
-Addtl-Link = Atom
- ; Additional standard names for links are registered with the
- ; Internet Assigned Numbers Authority (IANA). "Via" is
- ; primarily of value with non-Internet transports. SMTP
-
-
-
-Klensin Standards Track [Page 52]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- ; servers SHOULD NOT use unregistered names.
-Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
-Attdl-Protocol = Atom
- ; Additional standard names for protocols are registered with the
- ; Internet Assigned Numbers Authority (IANA). SMTP servers
- ; SHOULD NOT use unregistered names.
-
-4.5 Additional Implementation Issues
-
-4.5.1 Minimum Implementation
-
- In order to make SMTP workable, the following minimum implementation
- is required for all receivers. The following commands MUST be
- supported to conform to this specification:
-
- EHLO
- HELO
- MAIL
- RCPT
- DATA
- RSET
- NOOP
- QUIT
- VRFY
-
- Any system that includes an SMTP server supporting mail relaying or
- delivery MUST support the reserved mailbox "postmaster" as a case-
- insensitive local name. This postmaster address is not strictly
- necessary if the server always returns 554 on connection opening (as
- described in section 3.1). The requirement to accept mail for
- postmaster implies that RCPT commands which specify a mailbox for
- postmaster at any of the domains for which the SMTP server provides
- mail service, as well as the special case of "RCPT TO:<Postmaster>"
- (with no domain specification), MUST be supported.
-
- SMTP systems are expected to make every reasonable effort to accept
- mail directed to Postmaster from any other system on the Internet.
- In extreme cases --such as to contain a denial of service attack or
- other breach of security-- an SMTP server may block mail directed to
- Postmaster. However, such arrangements SHOULD be narrowly tailored
- so as to avoid blocking messages which are not part of such attacks.
-
-4.5.2 Transparency
-
- Without some provision for data transparency, the character sequence
- "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user.
- In general, users are not aware of such "forbidden" sequences. To
-
-
-
-
-Klensin Standards Track [Page 53]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- allow all user composed text to be transmitted transparently, the
- following procedures are used:
-
- - Before sending a line of mail text, the SMTP client checks the
- first character of the line. If it is a period, one additional
- period is inserted at the beginning of the line.
-
- - When a line of mail text is received by the SMTP server, it checks
- the line. If the line is composed of a single period, it is
- treated as the end of mail indicator. If the first character is a
- period and there are other characters on the line, the first
- character is deleted.
-
- The mail data may contain any of the 128 ASCII characters. All
- characters are to be delivered to the recipient's mailbox, including
- spaces, vertical and horizontal tabs, and other control characters.
- If the transmission channel provides an 8-bit byte (octet) data
- stream, the 7-bit ASCII codes are transmitted right justified in the
- octets, with the high order bits cleared to zero. See 3.7 for
- special treatment of these conditions in SMTP systems serving a relay
- function.
-
- In some systems it may be necessary to transform the data as it is
- received and stored. This may be necessary for hosts that use a
- different character set than ASCII as their local character set, that
- store data in records rather than strings, or which use special
- character sequences as delimiters inside mailboxes. If such
- transformations are necessary, they MUST be reversible, especially if
- they are applied to mail being relayed.
-
-4.5.3 Sizes and Timeouts
-
-4.5.3.1 Size limits and minimums
-
- There are several objects that have required minimum/maximum sizes.
- Every implementation MUST be able to receive objects of at least
- these sizes. Objects larger than these sizes SHOULD be avoided when
- possible. However, some Internet mail constructs such as encoded
- X.400 addresses [16] will often require larger objects: clients MAY
- attempt to transmit these, but MUST be prepared for a server to
- reject them if they cannot be handled by it. To the maximum extent
- possible, implementation techniques which impose no limits on the
- length of these objects should be used.
-
- local-part
- The maximum total length of a user name or other local-part is 64
- characters.
-
-
-
-
-Klensin Standards Track [Page 54]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- domain
- The maximum total length of a domain name or number is 255
- characters.
-
- path
- The maximum total length of a reverse-path or forward-path is 256
- characters (including the punctuation and element separators).
-
- command line
- The maximum total length of a command line including the command
- word and the <CRLF> is 512 characters. SMTP extensions may be
- used to increase this limit.
-
- reply line
- The maximum total length of a reply line including the reply code
- and the <CRLF> is 512 characters. More information may be
- conveyed through multiple-line replies.
-
- text line
- The maximum total length of a text line including the <CRLF> is
- 1000 characters (not counting the leading dot duplicated for
- transparency). This number may be increased by the use of SMTP
- Service Extensions.
-
- message content
- The maximum total length of a message content (including any
- message headers as well as the message body) MUST BE at least 64K
- octets. Since the introduction of Internet standards for
- multimedia mail [12], message lengths on the Internet have grown
- dramatically, and message size restrictions should be avoided if
- at all possible. SMTP server systems that must impose
- restrictions SHOULD implement the "SIZE" service extension [18],
- and SMTP client systems that will send large messages SHOULD
- utilize it when possible.
-
- recipients buffer
- The minimum total number of recipients that must be buffered is
- 100 recipients. Rejection of messages (for excessive recipients)
- with fewer than 100 RCPT commands is a violation of this
- specification. The general principle that relaying SMTP servers
- MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation
- tests on message headers suggests that rejecting a message based
- on the total number of recipients shown in header fields is to be
- discouraged. A server which imposes a limit on the number of
- recipients MUST behave in an orderly fashion, such as to reject
- additional addresses over its limit rather than silently
- discarding addresses previously accepted. A client that needs to
-
-
-
-
-Klensin Standards Track [Page 55]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- deliver a message containing over 100 RCPT commands SHOULD be
- prepared to transmit in 100-recipient "chunks" if the server
- declines to accept more than 100 recipients in a single message.
-
- Errors due to exceeding these limits may be reported by using the
- reply codes. Some examples of reply codes are:
-
- 500 Line too long.
- or
- 501 Path too long
- or
- 452 Too many recipients (see below)
- or
- 552 Too much mail data.
-
- RFC 821 [30] incorrectly listed the error where an SMTP server
- exhausts its implementation limit on the number of RCPT commands
- ("too many recipients") as having reply code 552. The correct reply
- code for this condition is 452. Clients SHOULD treat a 552 code in
- this case as a temporary, rather than permanent, failure so the logic
- below works.
-
- When a conforming SMTP server encounters this condition, it has at
- least 100 successful RCPT commands in its recipients buffer. If the
- server is able to accept the message, then at least these 100
- addresses will be removed from the SMTP client's queue. When the
- client attempts retransmission of those addresses which received 452
- responses, at least 100 of these will be able to fit in the SMTP
- server's recipients buffer. Each retransmission attempt which is
- able to deliver anything will be able to dispose of at least 100 of
- these recipients.
-
- If an SMTP server has an implementation limit on the number of RCPT
- commands and this limit is exhausted, it MUST use a response code of
- 452 (but the client SHOULD also be prepared for a 552, as noted
- above). If the server has a configured site-policy limitation on the
- number of RCPT commands, it MAY instead use a 5XX response code.
- This would be most appropriate if the policy limitation was intended
- to apply if the total recipient count for a particular message body
- were enforced even if that message body was sent in multiple mail
- transactions.
-
-4.5.3.2 Timeouts
-
- An SMTP client MUST provide a timeout mechanism. It MUST use per-
- command timeouts rather than somehow trying to time the entire mail
- transaction. Timeouts SHOULD be easily reconfigurable, preferably
- without recompiling the SMTP code. To implement this, a timer is set
-
-
-
-Klensin Standards Track [Page 56]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- for each SMTP command and for each buffer of the data transfer. The
- latter means that the overall timeout is inherently proportional to
- the size of the message.
-
- Based on extensive experience with busy mail-relay hosts, the minimum
- per-command timeout values SHOULD be as follows:
-
- Initial 220 Message: 5 minutes
- An SMTP client process needs to distinguish between a failed TCP
- connection and a delay in receiving the initial 220 greeting
- message. Many SMTP servers accept a TCP connection but delay
- delivery of the 220 message until their system load permits more
- mail to be processed.
-
- MAIL Command: 5 minutes
-
- RCPT Command: 5 minutes
- A longer timeout is required if processing of mailing lists and
- aliases is not deferred until after the message was accepted.
-
- DATA Initiation: 2 minutes
- This is while awaiting the "354 Start Input" reply to a DATA
- command.
-
- Data Block: 3 minutes
- This is while awaiting the completion of each TCP SEND call
- transmitting a chunk of data.
-
- DATA Termination: 10 minutes.
- This is while awaiting the "250 OK" reply. When the receiver gets
- the final period terminating the message data, it typically
- performs processing to deliver the message to a user mailbox. A
- spurious timeout at this point would be very wasteful and would
- typically result in delivery of multiple copies of the message,
- since it has been successfully sent and the server has accepted
- responsibility for delivery. See section 6.1 for additional
- discussion.
-
- An SMTP server SHOULD have a timeout of at least 5 minutes while it
- is awaiting the next command from the sender.
-
-4.5.4 Retry Strategies
-
- The common structure of a host SMTP implementation includes user
- mailboxes, one or more areas for queuing messages in transit, and one
- or more daemon processes for sending and receiving mail. The exact
- structure will vary depending on the needs of the users on the host
-
-
-
-
-Klensin Standards Track [Page 57]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- and the number and size of mailing lists supported by the host. We
- describe several optimizations that have proved helpful, particularly
- for mailers supporting high traffic levels.
-
- Any queuing strategy MUST include timeouts on all activities on a
- per-command basis. A queuing strategy MUST NOT send error messages
- in response to error messages under any circumstances.
-
-4.5.4.1 Sending Strategy
-
- The general model for an SMTP client is one or more processes that
- periodically attempt to transmit outgoing mail. In a typical system,
- the program that composes a message has some method for requesting
- immediate attention for a new piece of outgoing mail, while mail that
- cannot be transmitted immediately MUST be queued and periodically
- retried by the sender. A mail queue entry will include not only the
- message itself but also the envelope information.
-
- The sender MUST delay retrying a particular destination after one
- attempt has failed. In general, the retry interval SHOULD be at
- least 30 minutes; however, more sophisticated and variable strategies
- will be beneficial when the SMTP client can determine the reason for
- non-delivery.
-
- Retries continue until the message is transmitted or the sender gives
- up; the give-up time generally needs to be at least 4-5 days. The
- parameters to the retry algorithm MUST be configurable.
-
- A client SHOULD keep a list of hosts it cannot reach and
- corresponding connection timeouts, rather than just retrying queued
- mail items.
-
- Experience suggests that failures are typically transient (the target
- system or its connection has crashed), favoring a policy of two
- connection attempts in the first hour the message is in the queue,
- and then backing off to one every two or three hours.
-
- The SMTP client can shorten the queuing delay in cooperation with the
- SMTP server. For example, if mail is received from a particular
- address, it is likely that mail queued for that host can now be sent.
- Application of this principle may, in many cases, eliminate the
- requirement for an explicit "send queues now" function such as ETRN
- [9].
-
- The strategy may be further modified as a result of multiple
- addresses per host (see below) to optimize delivery time vs. resource
- usage.
-
-
-
-
-Klensin Standards Track [Page 58]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- An SMTP client may have a large queue of messages for each
- unavailable destination host. If all of these messages were retried
- in every retry cycle, there would be excessive Internet overhead and
- the sending system would be blocked for a long period. Note that an
- SMTP client can generally determine that a delivery attempt has
- failed only after a timeout of several minutes and even a one-minute
- timeout per connection will result in a very large delay if retries
- are repeated for dozens, or even hundreds, of queued messages to the
- same host.
-
- At the same time, SMTP clients SHOULD use great care in caching
- negative responses from servers. In an extreme case, if EHLO is
- issued multiple times during the same SMTP connection, different
- answers may be returned by the server. More significantly, 5yz
- responses to the MAIL command MUST NOT be cached.
-
- When a mail message is to be delivered to multiple recipients, and
- the SMTP server to which a copy of the message is to be sent is the
- same for multiple recipients, then only one copy of the message
- SHOULD be transmitted. That is, the SMTP client SHOULD use the
- command sequence: MAIL, RCPT, RCPT,... RCPT, DATA instead of the
- sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA. However, if there
- are very many addresses, a limit on the number of RCPT commands per
- MAIL command MAY be imposed. Implementation of this efficiency
- feature is strongly encouraged.
-
- Similarly, to achieve timely delivery, the SMTP client MAY support
- multiple concurrent outgoing mail transactions. However, some limit
- may be appropriate to protect the host from devoting all its
- resources to mail.
-
-4.5.4.2 Receiving Strategy
-
- The SMTP server SHOULD attempt to keep a pending listen on the SMTP
- port at all times. This requires the support of multiple incoming
- TCP connections for SMTP. Some limit MAY be imposed but servers that
- cannot handle more than one SMTP transaction at a time are not in
- conformance with the intent of this specification.
-
- As discussed above, when the SMTP server receives mail from a
- particular host address, it could activate its own SMTP queuing
- mechanisms to retry any mail pending for that host address.
-
-4.5.5 Messages with a null reverse-path
-
- There are several types of notification messages which are required
- by existing and proposed standards to be sent with a null reverse
- path, namely non-delivery notifications as discussed in section 3.7,
-
-
-
-Klensin Standards Track [Page 59]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- other kinds of Delivery Status Notifications (DSNs) [24], and also
- Message Disposition Notifications (MDNs) [10]. All of these kinds of
- messages are notifications about a previous message, and they are
- sent to the reverse-path of the previous mail message. (If the
- delivery of such a notification message fails, that usually indicates
- a problem with the mail system of the host to which the notification
- message is addressed. For this reason, at some hosts the MTA is set
- up to forward such failed notification messages to someone who is
- able to fix problems with the mail system, e.g., via the postmaster
- alias.)
-
- All other types of messages (i.e., any message which is not required
- by a standards-track RFC to have a null reverse-path) SHOULD be sent
- with with a valid, non-null reverse-path.
-
- Implementors of automated email processors should be careful to make
- sure that the various kinds of messages with null reverse-path are
- handled correctly, in particular such systems SHOULD NOT reply to
- messages with null reverse-path.
-
-5. Address Resolution and Mail Handling
-
- Once an SMTP client lexically identifies a domain to which mail will
- be delivered for processing (as described in sections 3.6 and 3.7), a
- DNS lookup MUST be performed to resolve the domain name [22]. The
- names are expected to be fully-qualified domain names (FQDNs):
- mechanisms for inferring FQDNs from partial names or local aliases
- are outside of this specification and, due to a history of problems,
- are generally discouraged. The lookup first attempts to locate an MX
- record associated with the name. If a CNAME record is found instead,
- the resulting name is processed as if it were the initial name. If
- no MX records are found, but an A RR is found, the A RR is treated as
- if it was associated with an implicit MX RR, with a preference of 0,
- pointing to that host. If one or more MX RRs are found for a given
- name, SMTP systems MUST NOT utilize any A RRs associated with that
- name unless they are located using the MX RRs; the "implicit MX" rule
- above applies only if there are no MX records present. If MX records
- are present, but none of them are usable, this situation MUST be
- reported as an error.
-
- When the lookup succeeds, the mapping can result in a list of
- alternative delivery addresses rather than a single address, because
- of multiple MX records, multihoming, or both. To provide reliable
- mail transmission, the SMTP client MUST be able to try (and retry)
- each of the relevant addresses in this list in order, until a
- delivery attempt succeeds. However, there MAY also be a configurable
- limit on the number of alternate addresses that can be tried. In any
- case, the SMTP client SHOULD try at least two addresses.
-
-
-
-Klensin Standards Track [Page 60]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- Two types of information is used to rank the host addresses: multiple
- MX records, and multihomed hosts.
-
- Multiple MX records contain a preference indication that MUST be used
- in sorting (see below). Lower numbers are more preferred than higher
- ones. If there are multiple destinations with the same preference
- and there is no clear reason to favor one (e.g., by recognition of an
- easily-reached address), then the sender-SMTP MUST randomize them to
- spread the load across multiple mail exchangers for a specific
- organization.
-
- The destination host (perhaps taken from the preferred MX record) may
- be multihomed, in which case the domain name resolver will return a
- list of alternative IP addresses. It is the responsibility of the
- domain name resolver interface to have ordered this list by
- decreasing preference if necessary, and SMTP MUST try them in the
- order presented.
-
- Although the capability to try multiple alternative addresses is
- required, specific installations may want to limit or disable the use
- of alternative addresses. The question of whether a sender should
- attempt retries using the different addresses of a multihomed host
- has been controversial. The main argument for using the multiple
- addresses is that it maximizes the probability of timely delivery,
- and indeed sometimes the probability of any delivery; the counter-
- argument is that it may result in unnecessary resource use. Note
- that resource use is also strongly determined by the sending strategy
- discussed in section 4.5.4.1.
-
- If an SMTP server receives a message with a destination for which it
- is a designated Mail eXchanger, it MAY relay the message (potentially
- after having rewritten the MAIL FROM and/or RCPT TO addresses), make
- final delivery of the message, or hand it off using some mechanism
- outside the SMTP-provided transport environment. Of course, neither
- of the latter require that the list of MX records be examined
- further.
-
- If it determines that it should relay the message without rewriting
- the address, it MUST sort the MX records to determine candidates for
- delivery. The records are first ordered by preference, with the
- lowest-numbered records being most preferred. The relay host MUST
- then inspect the list for any of the names or addresses by which it
- might be known in mail transactions. If a matching record is found,
- all records at that preference level and higher-numbered ones MUST be
- discarded from consideration. If there are no records left at that
- point, it is an error condition, and the message MUST be returned as
- undeliverable. If records do remain, they SHOULD be tried, best
- preference first, as described above.
-
-
-
-Klensin Standards Track [Page 61]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
-6. Problem Detection and Handling
-
-6.1 Reliable Delivery and Replies by Email
-
- When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
- message in response to DATA), it is accepting responsibility for
- delivering or relaying the message. It must take this responsibility
- seriously. It MUST NOT lose the message for frivolous reasons, such
- as because the host later crashes or because of a predictable
- resource shortage.
-
- If there is a delivery failure after acceptance of a message, the
- receiver-SMTP MUST formulate and mail a notification message. This
- notification MUST be sent using a null ("<>") reverse path in the
- envelope. The recipient of this notification MUST be the address
- from the envelope return path (or the Return-Path: line). However,
- if this address is null ("<>"), the receiver-SMTP MUST NOT send a
- notification. Obviously, nothing in this section can or should
- prohibit local decisions (i.e., as part of the same system
- environment as the receiver-SMTP) to log or otherwise transmit
- information about null address events locally if that is desired. If
- the address is an explicit source route, it MUST be stripped down to
- its final hop.
-
- For example, suppose that an error notification must be sent for a
- message that arrived with:
-
- MAIL FROM:<@a,@b:address@hidden>
-
- The notification message MUST be sent using:
-
- RCPT TO:<address@hidden>
-
- Some delivery failures after the message is accepted by SMTP will be
- unavoidable. For example, it may be impossible for the receiving
- SMTP server to validate all the delivery addresses in RCPT command(s)
- due to a "soft" domain system error, because the target is a mailing
- list (see earlier discussion of RCPT), or because the server is
- acting as a relay and has no immediate access to the delivering
- system.
-
- To avoid receiving duplicate messages as the result of timeouts, a
- receiver-SMTP MUST seek to minimize the time required to respond to
- the final <CRLF>.<CRLF> end of data indicator. See RFC 1047 [28] for
- a discussion of this problem.
-
-
-
-
-
-
-Klensin Standards Track [Page 62]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
-6.2 Loop Detection
-
- Simple counting of the number of "Received:" headers in a message has
- proven to be an effective, although rarely optimal, method of
- detecting loops in mail systems. SMTP servers using this technique
- SHOULD use a large rejection threshold, normally at least 100
- Received entries. Whatever mechanisms are used, servers MUST contain
- provisions for detecting and stopping trivial loops.
-
-6.3 Compensating for Irregularities
-
- Unfortunately, variations, creative interpretations, and outright
- violations of Internet mail protocols do occur; some would suggest
- that they occur quite frequently. The debate as to whether a well-
- behaved SMTP receiver or relay should reject a malformed message,
- attempt to pass it on unchanged, or attempt to repair it to increase
- the odds of successful delivery (or subsequent reply) began almost
- with the dawn of structured network mail and shows no signs of
- abating. Advocates of rejection claim that attempted repairs are
- rarely completely adequate and that rejection of bad messages is the
- only way to get the offending software repaired. Advocates of
- "repair" or "deliver no matter what" argue that users prefer that
- mail go through it if at all possible and that there are significant
- market pressures in that direction. In practice, these market
- pressures may be more important to particular vendors than strict
- conformance to the standards, regardless of the preference of the
- actual developers.
-
- The problems associated with ill-formed messages were exacerbated by
- the introduction of the split-UA mail reading protocols [3, 26, 5,
- 21]. These protocols have encouraged the use of SMTP as a posting
- protocol, and SMTP servers as relay systems for these client hosts
- (which are often only intermittently connected to the Internet).
- Historically, many of those client machines lacked some of the
- mechanisms and information assumed by SMTP (and indeed, by the mail
- format protocol [7]). Some could not keep adequate track of time;
- others had no concept of time zones; still others could not identify
- their own names or addresses; and, of course, none could satisfy the
- assumptions that underlay RFC 822's conception of authenticated
- addresses.
-
- In response to these weak SMTP clients, many SMTP systems now
- complete messages that are delivered to them in incomplete or
- incorrect form. This strategy is generally considered appropriate
- when the server can identify or authenticate the client, and there
- are prior agreements between them. By contrast, there is at best
- great concern about fixes applied by a relay or delivery SMTP server
- that has little or no knowledge of the user or client machine.
-
-
-
-Klensin Standards Track [Page 63]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- The following changes to a message being processed MAY be applied
- when necessary by an originating SMTP server, or one used as the
- target of SMTP as an initial posting protocol:
-
- - Addition of a message-id field when none appears
-
- - Addition of a date, time or time zone when none appears
-
- - Correction of addresses to proper FQDN format
-
- The less information the server has about the client, the less likely
- these changes are to be correct and the more caution and conservatism
- should be applied when considering whether or not to perform fixes
- and how. These changes MUST NOT be applied by an SMTP server that
- provides an intermediate relay function.
-
- In all cases, properly-operating clients supplying correct
- information are preferred to corrections by the SMTP server. In all
- cases, documentation of actions performed by the servers (in trace
- fields and/or header comments) is strongly encouraged.
-
-7. Security Considerations
-
-7.1 Mail Security and Spoofing
-
- SMTP mail is inherently insecure in that it is feasible for even
- fairly casual users to negotiate directly with receiving and relaying
- SMTP servers and create messages that will trick a naive recipient
- into believing that they came from somewhere else. Constructing such
- a message so that the "spoofed" behavior cannot be detected by an
- expert is somewhat more difficult, but not sufficiently so as to be a
- deterrent to someone who is determined and knowledgeable.
- Consequently, as knowledge of Internet mail increases, so does the
- knowledge that SMTP mail inherently cannot be authenticated, or
- integrity checks provided, at the transport level. Real mail
- security lies only in end-to-end methods involving the message
- bodies, such as those which use digital signatures (see [14] and,
- e.g., PGP [4] or S/MIME [31]).
-
- Various protocol extensions and configuration options that provide
- authentication at the transport level (e.g., from an SMTP client to
- an SMTP server) improve somewhat on the traditional situation
- described above. However, unless they are accompanied by careful
- handoffs of responsibility in a carefully-designed trust environment,
- they remain inherently weaker than end-to-end mechanisms which use
- digitally signed messages rather than depending on the integrity of
- the transport system.
-
-
-
-
-Klensin Standards Track [Page 64]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- Efforts to make it more difficult for users to set envelope return
- path and header "From" fields to point to valid addresses other than
- their own are largely misguided: they frustrate legitimate
- applications in which mail is sent by one user on behalf of another
- or in which error (or normal) replies should be directed to a special
- address. (Systems that provide convenient ways for users to alter
- these fields on a per-message basis should attempt to establish a
- primary and permanent mailbox address for the user so that Sender
- fields within the message data can be generated sensibly.)
-
- This specification does not further address the authentication issues
- associated with SMTP other than to advocate that useful functionality
- not be disabled in the hope of providing some small margin of
- protection against an ignorant user who is trying to fake mail.
-
-7.2 "Blind" Copies
-
- Addresses that do not appear in the message headers may appear in the
- RCPT commands to an SMTP server for a number of reasons. The two
- most common involve the use of a mailing address as a "list exploder"
- (a single address that resolves into multiple addresses) and the
- appearance of "blind copies". Especially when more than one RCPT
- command is present, and in order to avoid defeating some of the
- purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy
- the full set of RCPT command arguments into the headers, either as
- part of trace headers or as informational or private-extension
- headers. Since this rule is often violated in practice, and cannot
- be enforced, sending SMTP systems that are aware of "bcc" use MAY
- find it helpful to send each blind copy as a separate message
- transaction containing only a single RCPT command.
-
- There is no inherent relationship between either "reverse" (from
- MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP
- transaction ("envelope") and the addresses in the headers. Receiving
- systems SHOULD NOT attempt to deduce such relationships and use them
- to alter the headers of the message for delivery. The popular
- "Apparently-to" header is a violation of this principle as well as a
- common source of unintended information disclosure and SHOULD NOT be
- used.
-
-7.3 VRFY, EXPN, and Security
-
- As discussed in section 3.5, individual sites may want to disable
- either or both of VRFY or EXPN for security reasons. As a corollary
- to the above, implementations that permit this MUST NOT appear to
- have verified addresses that are not, in fact, verified. If a site
-
-
-
-
-
-Klensin Standards Track [Page 65]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- disables these commands for security reasons, the SMTP server MUST
- return a 252 response, rather than a code that could be confused with
- successful or unsuccessful verification.
-
- Returning a 250 reply code with the address listed in the VRFY
- command after having checked it only for syntax violates this rule.
- Of course, an implementation that "supports" VRFY by always returning
- 550 whether or not the address is valid is equally not in
- conformance.
-
- Within the last few years, the contents of mailing lists have become
- popular as an address information source for so-called "spammers."
- The use of EXPN to "harvest" addresses has increased as list
- administrators have installed protections against inappropriate uses
- of the lists themselves. Implementations SHOULD still provide
- support for EXPN, but sites SHOULD carefully evaluate the tradeoffs.
- As authentication mechanisms are introduced into SMTP, some sites may
- choose to make EXPN available only to authenticated requestors.
-
-7.4 Information Disclosure in Announcements
-
- There has been an ongoing debate about the tradeoffs between the
- debugging advantages of announcing server type and version (and,
- sometimes, even server domain name) in the greeting response or in
- response to the HELP command and the disadvantages of exposing
- information that might be useful in a potential hostile attack. The
- utility of the debugging information is beyond doubt. Those who
- argue for making it available point out that it is far better to
- actually secure an SMTP server rather than hope that trying to
- conceal known vulnerabilities by hiding the server's precise identity
- will provide more protection. Sites are encouraged to evaluate the
- tradeoff with that issue in mind; implementations are strongly
- encouraged to minimally provide for making type and version
- information available in some way to other network hosts.
-
-7.5 Information Disclosure in Trace Fields
-
- In some circumstances, such as when mail originates from within a LAN
- whose hosts are not directly on the public Internet, trace
- ("Received") fields produced in conformance with this specification
- may disclose host names and similar information that would not
- normally be available. This ordinarily does not pose a problem, but
- sites with special concerns about name disclosure should be aware of
- it. Also, the optional FOR clause should be supplied with caution or
- not at all when multiple recipients are involved lest it
- inadvertently disclose the identities of "blind copy" recipients to
- others.
-
-
-
-
-Klensin Standards Track [Page 66]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
-7.6 Information Disclosure in Message Forwarding
-
- As discussed in section 3.4, use of the 251 or 551 reply codes to
- identify the replacement address associated with a mailbox may
- inadvertently disclose sensitive information. Sites that are
- concerned about those issues should ensure that they select and
- configure servers appropriately.
-
-7.7 Scope of Operation of SMTP Servers
-
- It is a well-established principle that an SMTP server may refuse to
- accept mail for any operational or technical reason that makes sense
- to the site providing the server. However, cooperation among sites
- and installations makes the Internet possible. If sites take
- excessive advantage of the right to reject traffic, the ubiquity of
- email availability (one of the strengths of the Internet) will be
- threatened; considerable care should be taken and balance maintained
- if a site decides to be selective about the traffic it will accept
- and process.
-
- In recent years, use of the relay function through arbitrary sites
- has been used as part of hostile efforts to hide the actual origins
- of mail. Some sites have decided to limit the use of the relay
- function to known or identifiable sources, and implementations SHOULD
- provide the capability to perform this type of filtering. When mail
- is rejected for these or other policy reasons, a 550 code SHOULD be
- used in response to EHLO, MAIL, or RCPT as appropriate.
-
-8. IANA Considerations
-
- IANA will maintain three registries in support of this specification.
- The first consists of SMTP service extensions with the associated
- keywords, and, as needed, parameters and verbs. As specified in
- section 2.2.2, no entry may be made in this registry that starts in
- an "X". Entries may be made only for service extensions (and
- associated keywords, parameters, or verbs) that are defined in
- standards-track or experimental RFCs specifically approved by the
- IESG for this purpose.
-
- The second registry consists of "tags" that identify forms of domain
- literals other than those for IPv4 addresses (specified in RFC 821
- and in this document) and IPv6 addresses (specified in this
- document). Additional literal types require standardization before
- being used; none are anticipated at this time.
-
- The third, established by RFC 821 and renewed by this specification,
- is a registry of link and protocol identifiers to be used with the
- "via" and "with" subclauses of the time stamp ("Received: header")
-
-
-
-Klensin Standards Track [Page 67]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- described in section 4.4. Link and protocol identifiers in addition
- to those specified in this document may be registered only by
- standardization or by way of an RFC-documented, IESG-approved,
- Experimental protocol extension.
-
-9. References
-
- [1] American National Standards Institute (formerly United States of
- America Standards Institute), X3.4, 1968, "USA Code for
- Information Interchange". ANSI X3.4-1968 has been replaced by
- newer versions with slight modifications, but the 1968 version
- remains definitive for the Internet.
-
- [2] Braden, R., "Requirements for Internet hosts - application and
- support", STD 3, RFC 1123, October 1989.
-
- [3] Butler, M., Chase, D., Goldberger, J., Postel, J. and J.
- Reynolds, "Post Office Protocol - version 2", RFC 937, February
- 1985.
-
- [4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
- Message Format", RFC 2440, November 1998.
-
- [5] Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC
- 1176, August 1990.
-
- [6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC
- 2060, December 1996.
-
- [7] Crocker, D., "Standard for the Format of ARPA Internet Text
- Messages", RFC 822, August 1982.
-
- [8] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [9] De Winter, J., "SMTP Service Extension for Remote Message Queue
- Starting", RFC 1985, August 1996.
-
- [10] Fajman, R., "An Extensible Message Format for Message
- Disposition Notifications", RFC 2298, March 1998.
-
- [11] Freed, N, "Behavior of and Requirements for Internet Firewalls",
- RFC 2979, October 2000.
-
- [12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message Bodies",
- RFC 2045, December 1996.
-
-
-
-
-Klensin Standards Track [Page 68]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- [13] Freed, N., "SMTP Service Extension for Command Pipelining", RFC
- 2920, September 2000.
-
- [14] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
- Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
- RFC 1847, October 1995.
-
- [15] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
- December 1998.
-
- [16] Kille, S., "Mapping between X.400 and RFC822/MIME", RFC 2156,
- January 1998.
-
- [17] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
- [18] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension for
- Message Size Declaration", STD 10, RFC 1870, November 1995.
-
- [19] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
- "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
-
- [20] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
- "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July
- 1994.
-
- [21] Lambert, M., "PCMAIL: A distributed mail system for personal
- computers", RFC 1056, July 1988.
-
- [22] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
- [23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
- Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
- December 1996.
-
- [24] Moore, K., "SMTP Service Extension for Delivery Status
- Notifications", RFC 1891, January 1996.
-
- [25] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
- Delivery Status Notifications", RFC 1894, January 1996.
-
- [26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
- 53, RFC 1939, May 1996.
-
-
-
-
-Klensin Standards Track [Page 69]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- [27] Partridge, C., "Mail routing and the domain system", RFC 974,
- January 1986.
-
- [28] Partridge, C., "Duplicate messages and SMTP", RFC 1047, February
- 1988.
-
- [29] Postel, J., ed., "Transmission Control Protocol - DARPA Internet
- Program Protocol Specification", STD 7, RFC 793, September 1981.
-
- [30] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August
- 1982.
-
- [31] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC
- 2633, June 1999.
-
- [32] Resnick, P., Ed., "Internet Message Format", RFC 2822, April
- 2001.
-
- [33] Vaudreuil, G., "SMTP Service Extensions for Transmission of
- Large and Binary MIME Messages", RFC 1830, August 1995.
-
- [34] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
- January 1996.
-
-10. Editor's Address
-
- John C. Klensin
- AT&T Laboratories
- 99 Bedford St
- Boston, MA 02111 USA
-
- Phone: 617-574-3076
- EMail: address@hidden
-
-11. Acknowledgments
-
- Many people worked long and hard on the many iterations of this
- document. There was wide-ranging debate in the IETF DRUMS Working
- Group, both on its mailing list and in face to face discussions,
- about many technical issues and the role of a revised standard for
- Internet mail transport, and many contributors helped form the
- wording in this specification. The hundreds of participants in the
- many discussions since RFC 821 was produced are too numerous to
- mention, but they all helped this document become what it is.
-
-
-
-
-
-
-
-Klensin Standards Track [Page 70]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
-APPENDICES
-
-A. TCP Transport Service
-
- The TCP connection supports the transmission of 8-bit bytes. The
- SMTP data is 7-bit ASCII characters. Each character is transmitted
- as an 8-bit byte with the high-order bit cleared to zero. Service
- extensions may modify this rule to permit transmission of full 8-bit
- data bytes as part of the message body, but not in SMTP commands or
- responses.
-
-B. Generating SMTP Commands from RFC 822 Headers
-
- Some systems use RFC 822 headers (only) in a mail submission
- protocol, or otherwise generate SMTP commands from RFC 822 headers
- when such a message is handed to an MTA from a UA. While the MTA-UA
- protocol is a private matter, not covered by any Internet Standard,
- there are problems with this approach. For example, there have been
- repeated problems with proper handling of "bcc" copies and
- redistribution lists when information that conceptually belongs to a
- mail envelopes is not separated early in processing from header
- information (and kept separate).
-
- It is recommended that the UA provide its initial ("submission
- client") MTA with an envelope separate from the message itself.
- However, if the envelope is not supplied, SMTP commands SHOULD be
- generated as follows:
-
- 1. Each recipient address from a TO, CC, or BCC header field SHOULD
- be copied to a RCPT command (generating multiple message copies if
- that is required for queuing or delivery). This includes any
- addresses listed in a RFC 822 "group". Any BCC fields SHOULD then
- be removed from the headers. Once this process is completed, the
- remaining headers SHOULD be checked to verify that at least one
- To:, Cc:, or Bcc: header remains. If none do, then a bcc: header
- with no additional information SHOULD be inserted as specified in
- [32].
-
- 2. The return address in the MAIL command SHOULD, if possible, be
- derived from the system's identity for the submitting (local)
- user, and the "From:" header field otherwise. If there is a
- system identity available, it SHOULD also be copied to the Sender
- header field if it is different from the address in the From
- header field. (Any Sender field that was already there SHOULD be
- removed.) Systems may provide a way for submitters to override
- the envelope return address, but may want to restrict its use to
- privileged users. This will not prevent mail forgery, but may
- lessen its incidence; see section 7.1.
-
-
-
-Klensin Standards Track [Page 71]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- When an MTA is being used in this way, it bears responsibility for
- ensuring that the message being transmitted is valid. The mechanisms
- for checking that validity, and for handling (or returning) messages
- that are not valid at the time of arrival, are part of the MUA-MTA
- interface and not covered by this specification.
-
- A submission protocol based on Standard RFC 822 information alone
- MUST NOT be used to gateway a message from a foreign (non-SMTP) mail
- system into an SMTP environment. Additional information to construct
- an envelope must come from some source in the other environment,
- whether supplemental headers or the foreign system's envelope.
-
- Attempts to gateway messages using only their header "to" and "cc"
- fields have repeatedly caused mail loops and other behavior adverse
- to the proper functioning of the Internet mail environment. These
- problems have been especially common when the message originates from
- an Internet mailing list and is distributed into the foreign
- environment using envelope information. When these messages are then
- processed by a header-only remailer, loops back to the Internet
- environment (and the mailing list) are almost inevitable.
-
-C. Source Routes
-
- Historically, the <reverse-path> was a reverse source routing list of
- hosts and a source mailbox. The first host in the <reverse-path>
- SHOULD be the host sending the MAIL command. Similarly, the
- <forward-path> may be a source routing lists of hosts and a
- destination mailbox. However, in general, the <forward-path> SHOULD
- contain only a mailbox and domain name, relying on the domain name
- system to supply routing information if required. The use of source
- routes is deprecated; while servers MUST be prepared to receive and
- handle them as discussed in section 3.3 and F.2, clients SHOULD NOT
- transmit them and this section was included only to provide context.
-
- For relay purposes, the forward-path may be a source route of the
- form "@ONE,@TWO:address@hidden", where ONE, TWO, and THREE MUST BE fully-
- qualified domain names. This form is used to emphasize the
- distinction between an address and a route. The mailbox is an
- absolute address, and the route is information about how to get
- there. The two concepts should not be confused.
-
- If source routes are used, RFC 821 and the text below should be
- consulted for the mechanisms for constructing and updating the
- forward- and reverse-paths.
-
-
-
-
-
-
-
-Klensin Standards Track [Page 72]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- The SMTP server transforms the command arguments by moving its own
- identifier (its domain name or that of any domain for which it is
- acting as a mail exchanger), if it appears, from the forward-path to
- the beginning of the reverse-path.
-
- Notice that the forward-path and reverse-path appear in the SMTP
- commands and replies, but not necessarily in the message. That is,
- there is no need for these paths and especially this syntax to appear
- in the "To:" , "From:", "CC:", etc. fields of the message header.
- Conversely, SMTP servers MUST NOT derive final message delivery
- information from message header fields.
-
- When the list of hosts is present, it is a "reverse" source route and
- indicates that the mail was relayed through each host on the list
- (the first host in the list was the most recent relay). This list is
- used as a source route to return non-delivery notices to the sender.
- As each relay host adds itself to the beginning of the list, it MUST
- use its name as known in the transport environment to which it is
- relaying the mail rather than that of the transport environment from
- which the mail came (if they are different).
-
-D. Scenarios
-
- This section presents complete scenarios of several types of SMTP
- sessions. In the examples, "C:" indicates what is said by the SMTP
- client, and "S:" indicates what is said by the SMTP server.
-
-D.1 A Typical SMTP Transaction Scenario
-
- This SMTP example shows mail sent by Smith at host bar.com, to Jones,
- Green, and Brown at host foo.com. Here we assume that host bar.com
- contacts host foo.com directly. The mail is accepted for Jones and
- Brown. Green does not have a mailbox at host foo.com.
-
- S: 220 foo.com Simple Mail Transfer Service Ready
- C: EHLO bar.com
- S: 250-foo.com greets bar.com
- S: 250-8BITMIME
- S: 250-SIZE
- S: 250-DSN
- S: 250 HELP
- C: MAIL FROM:<address@hidden>
- S: 250 OK
- C: RCPT TO:<address@hidden>
- S: 250 OK
- C: RCPT TO:<address@hidden>
- S: 550 No such user here
- C: RCPT TO:<address@hidden>
-
-
-
-Klensin Standards Track [Page 73]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- S: 250 OK
- C: DATA
- S: 354 Start mail input; end with <CRLF>.<CRLF>
- C: Blah blah blah...
- C: ...etc. etc. etc.
- C: .
- S: 250 OK
- C: QUIT
- S: 221 foo.com Service closing transmission channel
-
-D.2 Aborted SMTP Transaction Scenario
-
- S: 220 foo.com Simple Mail Transfer Service Ready
- C: EHLO bar.com
- S: 250-foo.com greets bar.com
- S: 250-8BITMIME
- S: 250-SIZE
- S: 250-DSN
- S: 250 HELP
- C: MAIL FROM:<address@hidden>
- S: 250 OK
- C: RCPT TO:<address@hidden>
- S: 250 OK
- C: RCPT TO:<address@hidden>
- S: 550 No such user here
- C: RSET
- S: 250 OK
- C: QUIT
- S: 221 foo.com Service closing transmission channel
-
-D.3 Relayed Mail Scenario
-
- Step 1 -- Source Host to Relay Host
-
- S: 220 foo.com Simple Mail Transfer Service Ready
- C: EHLO bar.com
- S: 250-foo.com greets bar.com
- S: 250-8BITMIME
- S: 250-SIZE
- S: 250-DSN
- S: 250 HELP
- C: MAIL FROM:<address@hidden>
- S: 250 OK
- C: RCPT TO:<@foo.com:address@hidden>
- S: 250 OK
- C: DATA
- S: 354 Start mail input; end with <CRLF>.<CRLF>
- C: Date: Thu, 21 May 1998 05:33:29 -0700
-
-
-
-Klensin Standards Track [Page 74]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- C: From: John Q. Public <address@hidden>
- C: Subject: The Next Meeting of the Board
- C: To: address@hidden
- C:
- C: Bill:
- C: The next meeting of the board of directors will be
- C: on Tuesday.
- C: John.
- C: .
- S: 250 OK
- C: QUIT
- S: 221 foo.com Service closing transmission channel
-
- Step 2 -- Relay Host to Destination Host
-
- S: 220 xyz.com Simple Mail Transfer Service Ready
- C: EHLO foo.com
- S: 250 xyz.com is on the air
- C: MAIL FROM:<@foo.com:address@hidden>
- S: 250 OK
- C: RCPT TO:<address@hidden>
- S: 250 OK
- C: DATA
- S: 354 Start mail input; end with <CRLF>.<CRLF>
- C: Received: from bar.com by foo.com ; Thu, 21 May 1998
- C: 05:33:29 -0700
- C: Date: Thu, 21 May 1998 05:33:22 -0700
- C: From: John Q. Public <address@hidden>
- C: Subject: The Next Meeting of the Board
- C: To: address@hidden
- C:
- C: Bill:
- C: The next meeting of the board of directors will be
- C: on Tuesday.
- C: John.
- C: .
- S: 250 OK
- C: QUIT
- S: 221 foo.com Service closing transmission channel
-
-D.4 Verifying and Sending Scenario
-
- S: 220 foo.com Simple Mail Transfer Service Ready
- C: EHLO bar.com
- S: 250-foo.com greets bar.com
- S: 250-8BITMIME
- S: 250-SIZE
- S: 250-DSN
-
-
-
-Klensin Standards Track [Page 75]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
- S: 250-VRFY
- S: 250 HELP
- C: VRFY Crispin
- S: 250 Mark Crispin <address@hidden>
- C: SEND FROM:<address@hidden>
- S: 250 OK
- C: RCPT TO:<address@hidden>
- S: 250 OK
- C: DATA
- S: 354 Start mail input; end with <CRLF>.<CRLF>
- C: Blah blah blah...
- C: ...etc. etc. etc.
- C: .
- S: 250 OK
- C: QUIT
- S: 221 foo.com Service closing transmission channel
-
-E. Other Gateway Issues
-
- In general, gateways between the Internet and other mail systems
- SHOULD attempt to preserve any layering semantics across the
- boundaries between the two mail systems involved. Gateway-
- translation approaches that attempt to take shortcuts by mapping,
- (such as envelope information from one system to the message headers
- or body of another) have generally proven to be inadequate in
- important ways. Systems translating between environments that do not
- support both envelopes and headers and Internet mail must be written
- with the understanding that some information loss is almost
- inevitable.
-
-F. Deprecated Features of RFC 821
-
- A few features of RFC 821 have proven to be problematic and SHOULD
- NOT be used in Internet mail.
-
-F.1 TURN
-
- This command, described in RFC 821, raises important security issues
- since, in the absence of strong authentication of the host requesting
- that the client and server switch roles, it can easily be used to
- divert mail from its correct destination. Its use is deprecated;
- SMTP systems SHOULD NOT use it unless the server can authenticate the
- client.
-
-
-
-
-
-
-
-
-Klensin Standards Track [Page 76]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
-F.2 Source Routing
-
- RFC 821 utilized the concept of explicit source routing to get mail
- from one host to another via a series of relays. The requirement to
- utilize source routes in regular mail traffic was eliminated by the
- introduction of the domain name system "MX" record and the last
- significant justification for them was eliminated by the
- introduction, in RFC 1123, of a clear requirement that addresses
- following an "@" must all be fully-qualified domain names.
- Consequently, the only remaining justifications for the use of source
- routes are support for very old SMTP clients or MUAs and in mail
- system debugging. They can, however, still be useful in the latter
- circumstance and for routing mail around serious, but temporary,
- problems such as problems with the relevant DNS records.
-
- SMTP servers MUST continue to accept source route syntax as specified
- in the main body of this document and in RFC 1123. They MAY, if
- necessary, ignore the routes and utilize only the target domain in
- the address. If they do utilize the source route, the message MUST
- be sent to the first domain shown in the address. In particular, a
- server MUST NOT guess at shortcuts within the source route.
-
- Clients SHOULD NOT utilize explicit source routing except under
- unusual circumstances, such as debugging or potentially relaying
- around firewall or mail system configuration errors.
-
-F.3 HELO
-
- As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to
- HELO when the server will accept the former. Servers must continue
- to accept and process HELO in order to support older clients.
-
-F.4 #-literals
-
- RFC 821 provided for specifying an Internet address as a decimal
- integer host number prefixed by a pound sign, "#". In practice, that
- form has been obsolete since the introduction of TCP/IP. It is
- deprecated and MUST NOT be used.
-
-F.5 Dates and Years
-
- When dates are inserted into messages by SMTP clients or servers
- (e.g., in trace fields), four-digit years MUST BE used. Two-digit
- years are deprecated; three-digit years were never permitted in the
- Internet mail system.
-
-
-
-
-
-
-Klensin Standards Track [Page 77]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
-F.6 Sending versus Mailing
-
- In addition to specifying a mechanism for delivering messages to
- user's mailboxes, RFC 821 provided additional, optional, commands to
- deliver messages directly to the user's terminal screen. These
- commands (SEND, SAML, SOML) were rarely implemented, and changes in
- workstation technology and the introduction of other protocols may
- have rendered them obsolete even where they are implemented.
-
- Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers
- MAY implement them. If they are implemented by servers, the
- implementation model specified in RFC 821 MUST be used and the
- command names MUST be published in the response to the EHLO command.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin Standards Track [Page 78]
-
-RFC 2821 Simple Mail Transfer Protocol April 2001
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin Standards Track [Page 79]
-
diff --git a/doc/rfc/rfc2822.txt b/doc/rfc/rfc2822.txt
deleted file mode 100644
index 9f698f7..0000000
--- a/doc/rfc/rfc2822.txt
+++ /dev/null
@@ -1,2859 +0,0 @@
-
-
-
-
-
-
-Network Working Group P. Resnick, Editor
-Request for Comments: 2822 QUALCOMM Incorporated
-Obsoletes: 822 April 2001
-Category: Standards Track
-
-
- Internet Message Format
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
-Abstract
-
- This standard specifies a syntax for text messages that are sent
- between computer users, within the framework of "electronic mail"
- messages. This standard supersedes the one specified in Request For
- Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
- Messages", updating it to reflect current practice and incorporating
- incremental changes that were specified in other RFCs.
-
-Table of Contents
-
- 1. Introduction ............................................... 3
- 1.1. Scope .................................................... 3
- 1.2. Notational conventions ................................... 4
- 1.2.1. Requirements notation .................................. 4
- 1.2.2. Syntactic notation ..................................... 4
- 1.3. Structure of this document ............................... 4
- 2. Lexical Analysis of Messages ............................... 5
- 2.1. General Description ...................................... 5
- 2.1.1. Line Length Limits ..................................... 6
- 2.2. Header Fields ............................................ 7
- 2.2.1. Unstructured Header Field Bodies ....................... 7
- 2.2.2. Structured Header Field Bodies ......................... 7
- 2.2.3. Long Header Fields ..................................... 7
- 2.3. Body ..................................................... 8
- 3. Syntax ..................................................... 9
- 3.1. Introduction ............................................. 9
- 3.2. Lexical Tokens ........................................... 9
-
-
-
-Resnick Standards Track [Page 1]
-
-RFC 2822 Internet Message Format April 2001
-
-
- 3.2.1. Primitive Tokens ....................................... 9
- 3.2.2. Quoted characters ......................................10
- 3.2.3. Folding white space and comments .......................11
- 3.2.4. Atom ...................................................12
- 3.2.5. Quoted strings .........................................13
- 3.2.6. Miscellaneous tokens ...................................13
- 3.3. Date and Time Specification ..............................14
- 3.4. Address Specification ....................................15
- 3.4.1. Addr-spec specification ................................16
- 3.5 Overall message syntax ....................................17
- 3.6. Field definitions ........................................18
- 3.6.1. The origination date field .............................20
- 3.6.2. Originator fields ......................................21
- 3.6.3. Destination address fields .............................22
- 3.6.4. Identification fields ..................................23
- 3.6.5. Informational fields ...................................26
- 3.6.6. Resent fields ..........................................26
- 3.6.7. Trace fields ...........................................28
- 3.6.8. Optional fields ........................................29
- 4. Obsolete Syntax ............................................29
- 4.1. Miscellaneous obsolete tokens ............................30
- 4.2. Obsolete folding white space .............................31
- 4.3. Obsolete Date and Time ...................................31
- 4.4. Obsolete Addressing ......................................33
- 4.5. Obsolete header fields ...................................33
- 4.5.1. Obsolete origination date field ........................34
- 4.5.2. Obsolete originator fields .............................34
- 4.5.3. Obsolete destination address fields ....................34
- 4.5.4. Obsolete identification fields .........................35
- 4.5.5. Obsolete informational fields ..........................35
- 4.5.6. Obsolete resent fields .................................35
- 4.5.7. Obsolete trace fields ..................................36
- 4.5.8. Obsolete optional fields ...............................36
- 5. Security Considerations ....................................36
- 6. Bibliography ...............................................37
- 7. Editor's Address ...........................................38
- 8. Acknowledgements ...........................................39
- Appendix A. Example messages ..................................41
- A.1. Addressing examples ......................................41
- A.1.1. A message from one person to another with simple
- addressing .............................................41
- A.1.2. Different types of mailboxes ...........................42
- A.1.3. Group addresses ........................................43
- A.2. Reply messages ...........................................43
- A.3. Resent messages ..........................................44
- A.4. Messages with trace fields ...............................46
- A.5. White space, comments, and other oddities ................47
- A.6. Obsoleted forms ..........................................47
-
-
-
-Resnick Standards Track [Page 2]
-
-RFC 2822 Internet Message Format April 2001
-
-
- A.6.1. Obsolete addressing ....................................48
- A.6.2. Obsolete dates .........................................48
- A.6.3. Obsolete white space and comments ......................48
- Appendix B. Differences from earlier standards ................49
- Appendix C. Notices ...........................................50
- Full Copyright Statement ......................................51
-
-1. Introduction
-
-1.1. Scope
-
- This standard specifies a syntax for text messages that are sent
- between computer users, within the framework of "electronic mail"
- messages. This standard supersedes the one specified in Request For
- Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
- Messages" [RFC822], updating it to reflect current practice and
- incorporating incremental changes that were specified in other RFCs
- [STD3].
-
- This standard specifies a syntax only for text messages. In
- particular, it makes no provision for the transmission of images,
- audio, or other sorts of structured data in electronic mail messages.
- There are several extensions published, such as the MIME document
- series [RFC2045, RFC2046, RFC2049], which describe mechanisms for the
- transmission of such data through electronic mail, either by
- extending the syntax provided here or by structuring such messages to
- conform to this syntax. Those mechanisms are outside of the scope of
- this standard.
-
- In the context of electronic mail, messages are viewed as having an
- envelope and contents. The envelope contains whatever information is
- needed to accomplish transmission and delivery. (See [RFC2821] for a
- discussion of the envelope.) The contents comprise the object to be
- delivered to the recipient. This standard applies only to the format
- and some of the semantics of message contents. It contains no
- specification of the information in the envelope.
-
- However, some message systems may use information from the contents
- to create the envelope. It is intended that this standard facilitate
- the acquisition of such information by programs.
-
- This specification is intended as a definition of what message
- content format is to be passed between systems. Though some message
- systems locally store messages in this format (which eliminates the
- need for translation between formats) and others use formats that
- differ from the one specified in this standard, local storage is
- outside of the scope of this standard.
-
-
-
-
-Resnick Standards Track [Page 3]
-
-RFC 2822 Internet Message Format April 2001
-
-
- Note: This standard is not intended to dictate the internal formats
- used by sites, the specific message system features that they are
- expected to support, or any of the characteristics of user interface
- programs that create or read messages. In addition, this standard
- does not specify an encoding of the characters for either transport
- or storage; that is, it does not specify the number of bits used or
- how those bits are specifically transferred over the wire or stored
- on disk.
-
-1.2. Notational conventions
-
-1.2.1. Requirements notation
-
- This document occasionally uses terms that appear in capital letters.
- When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
- NOT", and "MAY" appear capitalized, they are being used to indicate
- particular requirements of this specification. A discussion of the
- meanings of these terms appears in [RFC2119].
-
-1.2.2. Syntactic notation
-
- This standard uses the Augmented Backus-Naur Form (ABNF) notation
- specified in [RFC2234] for the formal definitions of the syntax of
- messages. Characters will be specified either by a decimal value
- (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by
- a case-insensitive literal value enclosed in quotation marks (e.g.,
- "A" for either uppercase or lowercase A). See [RFC2234] for the full
- description of the notation.
-
-1.3. Structure of this document
-
- This document is divided into several sections.
-
- This section, section 1, is a short introduction to the document.
-
- Section 2 lays out the general description of a message and its
- constituent parts. This is an overview to help the reader understand
- some of the general principles used in the later portions of this
- document. Any examples in this section MUST NOT be taken as
- specification of the formal syntax of any part of a message.
-
- Section 3 specifies formal ABNF rules for the structure of each part
- of a message (the syntax) and describes the relationship between
- those parts and their meaning in the context of a message (the
- semantics). That is, it describes the actual rules for the structure
- of each part of a message (the syntax) as well as a description of
- the parts and instructions on how they ought to be interpreted (the
- semantics). This includes analysis of the syntax and semantics of
-
-
-
-Resnick Standards Track [Page 4]
-
-RFC 2822 Internet Message Format April 2001
-
-
- subparts of messages that have specific structure. The syntax
- included in section 3 represents messages as they MUST be created.
- There are also notes in section 3 to indicate if any of the options
- specified in the syntax SHOULD be used over any of the others.
-
- Both sections 2 and 3 describe messages that are legal to generate
- for purposes of this standard.
-
- Section 4 of this document specifies an "obsolete" syntax. There are
- references in section 3 to these obsolete syntactic elements. The
- rules of the obsolete syntax are elements that have appeared in
- earlier revisions of this standard or have previously been widely
- used in Internet messages. As such, these elements MUST be
- interpreted by parsers of messages in order to be conformant to this
- standard. However, since items in this syntax have been determined
- to be non-interoperable or to cause significant problems for
- recipients of messages, they MUST NOT be generated by creators of
- conformant messages.
-
- Section 5 details security considerations to take into account when
- implementing this standard.
-
- Section 6 is a bibliography of references in this document.
-
- Section 7 contains the editor's address.
-
- Section 8 contains acknowledgements.
-
- Appendix A lists examples of different sorts of messages. These
- examples are not exhaustive of the types of messages that appear on
- the Internet, but give a broad overview of certain syntactic forms.
-
- Appendix B lists the differences between this standard and earlier
- standards for Internet messages.
-
- Appendix C has copyright and intellectual property notices.
-
-2. Lexical Analysis of Messages
-
-2.1. General Description
-
- At the most basic level, a message is a series of characters. A
- message that is conformant with this standard is comprised of
- characters with values in the range 1 through 127 and interpreted as
- US-ASCII characters [ASCII]. For brevity, this document sometimes
- refers to this range of characters as simply "US-ASCII characters".
-
-
-
-
-
-Resnick Standards Track [Page 5]
-
-RFC 2822 Internet Message Format April 2001
-
-
- Note: This standard specifies that messages are made up of characters
- in the US-ASCII range of 1 through 127. There are other documents,
- specifically the MIME document series [RFC2045, RFC2046, RFC2047,
- RFC2048, RFC2049], that extend this standard to allow for values
- outside of that range. Discussion of those mechanisms is not within
- the scope of this standard.
-
- Messages are divided into lines of characters. A line is a series of
- characters that is delimited with the two characters carriage-return
- and line-feed; that is, the carriage return (CR) character (ASCII
- value 13) followed immediately by the line feed (LF) character (ASCII
- value 10). (The carriage-return/line-feed pair is usually written in
- this document as "CRLF".)
-
- A message consists of header fields (collectively called "the header
- of the message") followed, optionally, by a body. The header is a
- sequence of lines of characters with special syntax as defined in
- this standard. The body is simply a sequence of characters that
- follows the header and is separated from the header by an empty line
- (i.e., a line with nothing preceding the CRLF).
-
-2.1.1. Line Length Limits
-
- There are two limits that this standard places on the number of
- characters in a line. Each line of characters MUST be no more than
- 998 characters, and SHOULD be no more than 78 characters, excluding
- the CRLF.
-
- The 998 character limit is due to limitations in many implementations
- which send, receive, or store Internet Message Format messages that
- simply cannot handle more than 998 characters on a line. Receiving
- implementations would do well to handle an arbitrarily large number
- of characters in a line for robustness sake. However, there are so
- many implementations which (in compliance with the transport
- requirements of [RFC2821]) do not accept messages containing more
- than 1000 character including the CR and LF per line, it is important
- for implementations not to create such messages.
-
- The more conservative 78 character recommendation is to accommodate
- the many implementations of user interfaces that display these
- messages which may truncate, or disastrously wrap, the display of
- more than 78 characters per line, in spite of the fact that such
- implementations are non-conformant to the intent of this
- specification (and that of [RFC2821] if they actually cause
- information to be lost). Again, even though this limitation is put on
- messages, it is encumbant upon implementations which display messages
-
-
-
-
-
-Resnick Standards Track [Page 6]
-
-RFC 2822 Internet Message Format April 2001
-
-
- to handle an arbitrarily large number of characters in a line
- (certainly at least up to the 998 character limit) for the sake of
- robustness.
-
-2.2. Header Fields
-
- Header fields are lines composed of a field name, followed by a colon
- (":"), followed by a field body, and terminated by CRLF. A field
- name MUST be composed of printable US-ASCII characters (i.e.,
- characters that have values between 33 and 126, inclusive), except
- colon. A field body may be composed of any US-ASCII characters,
- except for CR and LF. However, a field body may contain CRLF when
- used in header "folding" and "unfolding" as described in section
- 2.2.3. All field bodies MUST conform to the syntax described in
- sections 3 and 4 of this standard.
-
-2.2.1. Unstructured Header Field Bodies
-
- Some field bodies in this standard are defined simply as
- "unstructured" (which is specified below as any US-ASCII characters,
- except for CR and LF) with no further restrictions. These are
- referred to as unstructured field bodies. Semantically, unstructured
- field bodies are simply to be treated as a single line of characters
- with no further processing (except for header "folding" and
- "unfolding" as described in section 2.2.3).
-
-2.2.2. Structured Header Field Bodies
-
- Some field bodies in this standard have specific syntactical
- structure more restrictive than the unstructured field bodies
- described above. These are referred to as "structured" field bodies.
- Structured field bodies are sequences of specific lexical tokens as
- described in sections 3 and 4 of this standard. Many of these tokens
- are allowed (according to their syntax) to be introduced or end with
- comments (as described in section 3.2.3) as well as the space (SP,
- ASCII value 32) and horizontal tab (HTAB, ASCII value 9) characters
- (together known as the white space characters, WSP), and those WSP
- characters are subject to header "folding" and "unfolding" as
- described in section 2.2.3. Semantic analysis of structured field
- bodies is given along with their syntax.
-
-2.2.3. Long Header Fields
-
- Each header field is logically a single line of characters comprising
- the field name, the colon, and the field body. For convenience
- however, and to deal with the 998/78 character limitations per line,
- the field body portion of a header field can be split into a multiple
- line representation; this is called "folding". The general rule is
-
-
-
-Resnick Standards Track [Page 7]
-
-RFC 2822 Internet Message Format April 2001
-
-
- that wherever this standard allows for folding white space (not
- simply WSP characters), a CRLF may be inserted before any WSP. For
- example, the header field:
-
- Subject: This is a test
-
- can be represented as:
-
- Subject: This
- is a test
-
- Note: Though structured field bodies are defined in such a way that
- folding can take place between many of the lexical tokens (and even
- within some of the lexical tokens), folding SHOULD be limited to
- placing the CRLF at higher-level syntactic breaks. For instance, if
- a field body is defined as comma-separated values, it is recommended
- that folding occur after the comma separating the structured items in
- preference to other places where the field could be folded, even if
- it is allowed elsewhere.
-
- The process of moving from this folded multiple-line representation
- of a header field to its single line representation is called
- "unfolding". Unfolding is accomplished by simply removing any CRLF
- that is immediately followed by WSP. Each header field should be
- treated in its unfolded form for further syntactic and semantic
- evaluation.
-
-2.3. Body
-
- The body of a message is simply lines of US-ASCII characters. The
- only two limitations on the body are as follows:
-
- - CR and LF MUST only occur together as CRLF; they MUST NOT appear
- independently in the body.
-
- - Lines of characters in the body MUST be limited to 998 characters,
- and SHOULD be limited to 78 characters, excluding the CRLF.
-
- Note: As was stated earlier, there are other standards documents,
- specifically the MIME documents [RFC2045, RFC2046, RFC2048, RFC2049]
- that extend this standard to allow for different sorts of message
- bodies. Again, these mechanisms are beyond the scope of this
- document.
-
-
-
-
-
-
-
-
-Resnick Standards Track [Page 8]
-
-RFC 2822 Internet Message Format April 2001
-
-
-3. Syntax
-
-3.1. Introduction
-
- The syntax as given in this section defines the legal syntax of
- Internet messages. Messages that are conformant to this standard
- MUST conform to the syntax in this section. If there are options in
- this section where one option SHOULD be generated, that is indicated
- either in the prose or in a comment next to the syntax.
-
- For the defined expressions, a short description of the syntax and
- use is given, followed by the syntax in ABNF, followed by a semantic
- analysis. Primitive tokens that are used but otherwise unspecified
- come from [RFC2234].
-
- In some of the definitions, there will be nonterminals whose names
- start with "obs-". These "obs-" elements refer to tokens defined in
- the obsolete syntax in section 4. In all cases, these productions
- are to be ignored for the purposes of generating legal Internet
- messages and MUST NOT be used as part of such a message. However,
- when interpreting messages, these tokens MUST be honored as part of
- the legal syntax. In this sense, section 3 defines a grammar for
- generation of messages, with "obs-" elements that are to be ignored,
- while section 4 adds grammar for interpretation of messages.
-
-3.2. Lexical Tokens
-
- The following rules are used to define an underlying lexical
- analyzer, which feeds tokens to the higher-level parsers. This
- section defines the tokens used in structured header field bodies.
-
- Note: Readers of this standard need to pay special attention to how
- these lexical tokens are used in both the lower-level and
- higher-level syntax later in the document. Particularly, the white
- space tokens and the comment tokens defined in section 3.2.3 get used
- in the lower-level tokens defined here, and those lower-level tokens
- are in turn used as parts of the higher-level tokens defined later.
- Therefore, the white space and comments may be allowed in the
- higher-level tokens even though they may not explicitly appear in a
- particular definition.
-
-3.2.1. Primitive Tokens
-
- The following are primitive tokens referred to elsewhere in this
- standard, but not otherwise defined in [RFC2234]. Some of them will
- not appear anywhere else in the syntax, but they are convenient to
- refer to in other parts of this document.
-
-
-
-
-Resnick Standards Track [Page 9]
-
-RFC 2822 Internet Message Format April 2001
-
-
- Note: The "specials" below are just such an example. Though the
- specials token does not appear anywhere else in this standard, it is
- useful for implementers who use tools that lexically analyze
- messages. Each of the characters in specials can be used to indicate
- a tokenization point in lexical analysis.
-
-NO-WS-CTL = %d1-8 / ; US-ASCII control characters
- %d11 / ; that do not include the
- %d12 / ; carriage return, line feed,
- %d14-31 / ; and white space characters
- %d127
-
-text = %d1-9 / ; Characters excluding CR and LF
- %d11 /
- %d12 /
- %d14-127 /
- obs-text
-
-specials = "(" / ")" / ; Special characters used in
- "<" / ">" / ; other parts of the syntax
- "[" / "]" /
- ":" / ";" /
- "@" / "\" /
- "," / "." /
- DQUOTE
-
- No special semantics are attached to these tokens. They are simply
- single characters.
-
-3.2.2. Quoted characters
-
- Some characters are reserved for special interpretation, such as
- delimiting lexical tokens. To permit use of these characters as
- uninterpreted data, a quoting mechanism is provided.
-
-quoted-pair = ("\" text) / obs-qp
-
- Where any quoted-pair appears, it is to be interpreted as the text
- character alone. That is to say, the "\" character that appears as
- part of a quoted-pair is semantically "invisible".
-
- Note: The "\" character may appear in a message where it is not part
- of a quoted-pair. A "\" character that does not appear in a
- quoted-pair is not semantically invisible. The only places in this
- standard where quoted-pair currently appears are ccontent, qcontent,
- dcontent, no-fold-quote, and no-fold-literal.
-
-
-
-
-
-Resnick Standards Track [Page 10]
-
-RFC 2822 Internet Message Format April 2001
-
-
-3.2.3. Folding white space and comments
-
- White space characters, including white space used in folding
- (described in section 2.2.3), may appear between many elements in
- header field bodies. Also, strings of characters that are treated as
- comments may be included in structured field bodies as characters
- enclosed in parentheses. The following defines the folding white
- space (FWS) and comment constructs.
-
- Strings of characters enclosed in parentheses are considered comments
- so long as they do not appear within a "quoted-string", as defined in
- section 3.2.5. Comments may nest.
-
- There are several places in this standard where comments and FWS may
- be freely inserted. To accommodate that syntax, an additional token
- for "CFWS" is defined for places where comments and/or FWS can occur.
- However, where CFWS occurs in this standard, it MUST NOT be inserted
- in such a way that any line of a folded header field is made up
- entirely of WSP characters and nothing else.
-
-FWS = ([*WSP CRLF] 1*WSP) / ; Folding white space
- obs-FWS
-
-ctext = NO-WS-CTL / ; Non white space controls
-
- %d33-39 / ; The rest of the US-ASCII
- %d42-91 / ; characters not including "(",
- %d93-126 ; ")", or "\"
-
-ccontent = ctext / quoted-pair / comment
-
-comment = "(" *([FWS] ccontent) [FWS] ")"
-
-CFWS = *([FWS] comment) (([FWS] comment) / FWS)
-
- Throughout this standard, where FWS (the folding white space token)
- appears, it indicates a place where header folding, as discussed in
- section 2.2.3, may take place. Wherever header folding appears in a
- message (that is, a header field body containing a CRLF followed by
- any WSP), header unfolding (removal of the CRLF) is performed before
- any further lexical analysis is performed on that header field
- according to this standard. That is to say, any CRLF that appears in
- FWS is semantically "invisible."
-
- A comment is normally used in a structured field body to provide some
- human readable informational text. Since a comment is allowed to
- contain FWS, folding is permitted within the comment. Also note that
- since quoted-pair is allowed in a comment, the parentheses and
-
-
-
-Resnick Standards Track [Page 11]
-
-RFC 2822 Internet Message Format April 2001
-
-
- backslash characters may appear in a comment so long as they appear
- as a quoted-pair. Semantically, the enclosing parentheses are not
- part of the comment; the comment is what is contained between the two
- parentheses. As stated earlier, the "\" in any quoted-pair and the
- CRLF in any FWS that appears within the comment are semantically
- "invisible" and therefore not part of the comment either.
-
- Runs of FWS, comment or CFWS that occur between lexical tokens in a
- structured field header are semantically interpreted as a single
- space character.
-
-3.2.4. Atom
-
- Several productions in structured header field bodies are simply
- strings of certain basic characters. Such productions are called
- atoms.
-
- Some of the structured header field bodies also allow the period
- character (".", ASCII value 46) within runs of atext. An additional
- "dot-atom" token is defined for those purposes.
-
-atext = ALPHA / DIGIT / ; Any character except controls,
- "!" / "#" / ; SP, and specials.
- "$" / "%" / ; Used for atoms
- "&" / "'" /
- "*" / "+" /
- "-" / "/" /
- "=" / "?" /
- "^" / "_" /
- "`" / "{" /
- "|" / "}" /
- "~"
-
-atom = [CFWS] 1*atext [CFWS]
-
-dot-atom = [CFWS] dot-atom-text [CFWS]
-
-dot-atom-text = 1*atext *("." 1*atext)
-
- Both atom and dot-atom are interpreted as a single unit, comprised of
- the string of characters that make it up. Semantically, the optional
- comments and FWS surrounding the rest of the characters are not part
- of the atom; the atom is only the run of atext characters in an atom,
- or the atext and "." characters in a dot-atom.
-
-
-
-
-
-
-
-Resnick Standards Track [Page 12]
-
-RFC 2822 Internet Message Format April 2001
-
-
-3.2.5. Quoted strings
-
- Strings of characters that include characters other than those
- allowed in atoms may be represented in a quoted string format, where
- the characters are surrounded by quote (DQUOTE, ASCII value 34)
- characters.
-
-qtext = NO-WS-CTL / ; Non white space controls
-
- %d33 / ; The rest of the US-ASCII
- %d35-91 / ; characters not including "\"
- %d93-126 ; or the quote character
-
-qcontent = qtext / quoted-pair
-
-quoted-string = [CFWS]
- DQUOTE *([FWS] qcontent) [FWS] DQUOTE
- [CFWS]
-
- A quoted-string is treated as a unit. That is, quoted-string is
- identical to atom, semantically. Since a quoted-string is allowed to
- contain FWS, folding is permitted. Also note that since quoted-pair
- is allowed in a quoted-string, the quote and backslash characters may
- appear in a quoted-string so long as they appear as a quoted-pair.
-
- Semantically, neither the optional CFWS outside of the quote
- characters nor the quote characters themselves are part of the
- quoted-string; the quoted-string is what is contained between the two
- quote characters. As stated earlier, the "\" in any quoted-pair and
- the CRLF in any FWS/CFWS that appears within the quoted-string are
- semantically "invisible" and therefore not part of the quoted-string
- either.
-
-3.2.6. Miscellaneous tokens
-
- Three additional tokens are defined, word and phrase for combinations
- of atoms and/or quoted-strings, and unstructured for use in
- unstructured header fields and in some places within structured
- header fields.
-
-word = atom / quoted-string
-
-phrase = 1*word / obs-phrase
-
-
-
-
-
-
-
-
-Resnick Standards Track [Page 13]
-
-RFC 2822 Internet Message Format April 2001
-
-
-utext = NO-WS-CTL / ; Non white space controls
- %d33-126 / ; The rest of US-ASCII
- obs-utext
-
-unstructured = *([FWS] utext) [FWS]
-
-3.3. Date and Time Specification
-
- Date and time occur in several header fields. This section specifies
- the syntax for a full date and time specification. Though folding
- white space is permitted throughout the date-time specification, it
- is RECOMMENDED that a single space be used in each place that FWS
- appears (whether it is required or optional); some older
- implementations may not interpret other occurrences of folding white
- space correctly.
-
-date-time = [ day-of-week "," ] date FWS time [CFWS]
-
-day-of-week = ([FWS] day-name) / obs-day-of-week
-
-day-name = "Mon" / "Tue" / "Wed" / "Thu" /
- "Fri" / "Sat" / "Sun"
-
-date = day month year
-
-year = 4*DIGIT / obs-year
-
-month = (FWS month-name FWS) / obs-month
-
-month-name = "Jan" / "Feb" / "Mar" / "Apr" /
- "May" / "Jun" / "Jul" / "Aug" /
- "Sep" / "Oct" / "Nov" / "Dec"
-
-day = ([FWS] 1*2DIGIT) / obs-day
-
-time = time-of-day FWS zone
-
-time-of-day = hour ":" minute [ ":" second ]
-
-hour = 2DIGIT / obs-hour
-
-minute = 2DIGIT / obs-minute
-
-second = 2DIGIT / obs-second
-
-zone = (( "+" / "-" ) 4DIGIT) / obs-zone
-
-
-
-
-
-Resnick Standards Track [Page 14]
-
-RFC 2822 Internet Message Format April 2001
-
-
- The day is the numeric day of the month. The year is any numeric
- year 1900 or later.
-
- The time-of-day specifies the number of hours, minutes, and
- optionally seconds since midnight of the date indicated.
-
- The date and time-of-day SHOULD express local time.
-
- The zone specifies the offset from Coordinated Universal Time (UTC,
- formerly referred to as "Greenwich Mean Time") that the date and
- time-of-day represent. The "+" or "-" indicates whether the
- time-of-day is ahead of (i.e., east of) or behind (i.e., west of)
- Universal Time. The first two digits indicate the number of hours
- difference from Universal Time, and the last two digits indicate the
- number of minutes difference from Universal Time. (Hence, +hhmm
- means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
- minutes). The form "+0000" SHOULD be used to indicate a time zone at
- Universal Time. Though "-0000" also indicates Universal Time, it is
- used to indicate that the time was generated on a system that may be
- in a local time zone other than Universal Time and therefore
- indicates that the date-time contains no information about the local
- time zone.
-
- A date-time specification MUST be semantically valid. That is, the
- day-of-the-week (if included) MUST be the day implied by the date,
- the numeric day-of-month MUST be between 1 and the number of days
- allowed for the specified month (in the specified year), the
- time-of-day MUST be in the range 00:00:00 through 23:59:60 (the
- number of seconds allowing for a leap second; see [STD12]), and the
- zone MUST be within the range -9959 through +9959.
-
-3.4. Address Specification
-
- Addresses occur in several message header fields to indicate senders
- and recipients of messages. An address may either be an individual
- mailbox, or a group of mailboxes.
-
-address = mailbox / group
-
-mailbox = name-addr / addr-spec
-
-name-addr = [display-name] angle-addr
-
-angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
-
-group = display-name ":" [mailbox-list / CFWS] ";"
- [CFWS]
-
-
-
-
-Resnick Standards Track [Page 15]
-
-RFC 2822 Internet Message Format April 2001
-
-
-display-name = phrase
-
-mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
-
-address-list = (address *("," address)) / obs-addr-list
-
- A mailbox receives mail. It is a conceptual entity which does not
- necessarily pertain to file storage. For example, some sites may
- choose to print mail on a printer and deliver the output to the
- addressee's desk. Normally, a mailbox is comprised of two parts: (1)
- an optional display name that indicates the name of the recipient
- (which could be a person or a system) that could be displayed to the
- user of a mail application, and (2) an addr-spec address enclosed in
- angle brackets ("<" and ">"). There is also an alternate simple form
- of a mailbox where the addr-spec address appears alone, without the
- recipient's name or the angle brackets. The Internet addr-spec
- address is described in section 3.4.1.
-
- Note: Some legacy implementations used the simple form where the
- addr-spec appears without the angle brackets, but included the name
- of the recipient in parentheses as a comment following the addr-spec.
- Since the meaning of the information in a comment is unspecified,
- implementations SHOULD use the full name-addr form of the mailbox,
- instead of the legacy form, to specify the display name associated
- with a mailbox. Also, because some legacy implementations interpret
- the comment, comments generally SHOULD NOT be used in address fields
- to avoid confusing such implementations.
-
- When it is desirable to treat several mailboxes as a single unit
- (i.e., in a distribution list), the group construct can be used. The
- group construct allows the sender to indicate a named group of
- recipients. This is done by giving a display name for the group,
- followed by a colon, followed by a comma separated list of any number
- of mailboxes (including zero and one), and ending with a semicolon.
- Because the list of mailboxes can be empty, using the group construct
- is also a simple way to communicate to recipients that the message
- was sent to one or more named sets of recipients, without actually
- providing the individual mailbox address for each of those
- recipients.
-
-3.4.1. Addr-spec specification
-
- An addr-spec is a specific Internet identifier that contains a
- locally interpreted string followed by the at-sign character ("@",
- ASCII value 64) followed by an Internet domain. The locally
- interpreted string is either a quoted-string or a dot-atom. If the
- string can be represented as a dot-atom (that is, it contains no
- characters other than atext characters or "." surrounded by atext
-
-
-
-Resnick Standards Track [Page 16]
-
-RFC 2822 Internet Message Format April 2001
-
-
- characters), then the dot-atom form SHOULD be used and the
- quoted-string form SHOULD NOT be used. Comments and folding white
- space SHOULD NOT be used around the "@" in the addr-spec.
-
-addr-spec = local-part "@" domain
-
-local-part = dot-atom / quoted-string / obs-local-part
-
-domain = dot-atom / domain-literal / obs-domain
-
-domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]
-
-dcontent = dtext / quoted-pair
-
-dtext = NO-WS-CTL / ; Non white space controls
-
- %d33-90 / ; The rest of the US-ASCII
- %d94-126 ; characters not including "[",
- ; "]", or "\"
-
- The domain portion identifies the point to which the mail is
- delivered. In the dot-atom form, this is interpreted as an Internet
- domain name (either a host name or a mail exchanger name) as
- described in [STD3, STD13, STD14]. In the domain-literal form, the
- domain is interpreted as the literal Internet address of the
- particular host. In both cases, how addressing is used and how
- messages are transported to a particular host is covered in the mail
- transport document [RFC2821]. These mechanisms are outside of the
- scope of this document.
-
- The local-part portion is a domain dependent string. In addresses,
- it is simply interpreted on the particular host as a name of a
- particular mailbox.
-
-3.5 Overall message syntax
-
- A message consists of header fields, optionally followed by a message
- body. Lines in a message MUST be a maximum of 998 characters
- excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
- characters excluding the CRLF. (See section 2.1.1 for explanation.)
- In a message body, though all of the characters listed in the text
- rule MAY be used, the use of US-ASCII control characters (values 1
- through 8, 11, 12, and 14 through 31) is discouraged since their
- interpretation by receivers for display is not guaranteed.
-
-
-
-
-
-
-
-Resnick Standards Track [Page 17]
-
-RFC 2822 Internet Message Format April 2001
-
-
-message = (fields / obs-fields)
- [CRLF body]
-
-body = *(*998text CRLF) *998text
-
- The header fields carry most of the semantic information and are
- defined in section 3.6. The body is simply a series of lines of text
- which are uninterpreted for the purposes of this standard.
-
-3.6. Field definitions
-
- The header fields of a message are defined here. All header fields
- have the same general syntactic structure: A field name, followed by
- a colon, followed by the field body. The specific syntax for each
- header field is defined in the subsequent sections.
-
- Note: In the ABNF syntax for each field in subsequent sections, each
- field name is followed by the required colon. However, for brevity
- sometimes the colon is not referred to in the textual description of
- the syntax. It is, nonetheless, required.
-
- It is important to note that the header fields are not guaranteed to
- be in a particular order. They may appear in any order, and they
- have been known to be reordered occasionally when transported over
- the Internet. However, for the purposes of this standard, header
- fields SHOULD NOT be reordered when a message is transported or
- transformed. More importantly, the trace header fields and resent
- header fields MUST NOT be reordered, and SHOULD be kept in blocks
- prepended to the message. See sections 3.6.6 and 3.6.7 for more
- information.
-
- The only required header fields are the origination date field and
- the originator address field(s). All other header fields are
- syntactically optional. More information is contained in the table
- following this definition.
-
-fields = *(trace
- *(resent-date /
- resent-from /
- resent-sender /
- resent-to /
- resent-cc /
- resent-bcc /
- resent-msg-id))
- *(orig-date /
- from /
- sender /
- reply-to /
-
-
-
-Resnick Standards Track [Page 18]
-
-RFC 2822 Internet Message Format April 2001
-
-
- to /
- cc /
- bcc /
- message-id /
- in-reply-to /
- references /
- subject /
- comments /
- keywords /
- optional-field)
-
- The following table indicates limits on the number of times each
- field may occur in a message header as well as any special
- limitations on the use of those fields. An asterisk next to a value
- in the minimum or maximum column indicates that a special restriction
- appears in the Notes column.
-
-Field Min number Max number Notes
-
-trace 0 unlimited Block prepended - see
- 3.6.7
-
-resent-date 0* unlimited* One per block, required
- if other resent fields
- present - see 3.6.6
-
-resent-from 0 unlimited* One per block - see
- 3.6.6
-
-resent-sender 0* unlimited* One per block, MUST
- occur with multi-address
- resent-from - see 3.6.6
-
-resent-to 0 unlimited* One per block - see
- 3.6.6
-
-resent-cc 0 unlimited* One per block - see
- 3.6.6
-
-resent-bcc 0 unlimited* One per block - see
- 3.6.6
-
-resent-msg-id 0 unlimited* One per block - see
- 3.6.6
-
-orig-date 1 1
-
-from 1 1 See sender and 3.6.2
-
-
-
-Resnick Standards Track [Page 19]
-
-RFC 2822 Internet Message Format April 2001
-
-
-sender 0* 1 MUST occur with multi-
- address from - see 3.6.2
-
-reply-to 0 1
-
-to 0 1
-
-cc 0 1
-
-bcc 0 1
-
-message-id 0* 1 SHOULD be present - see
- 3.6.4
-
-in-reply-to 0* 1 SHOULD occur in some
- replies - see 3.6.4
-
-references 0* 1 SHOULD occur in some
- replies - see 3.6.4
-
-subject 0 1
-
-comments 0 unlimited
-
-keywords 0 unlimited
-
-optional-field 0 unlimited
-
- The exact interpretation of each field is described in subsequent
- sections.
-
-3.6.1. The origination date field
-
- The origination date field consists of the field name "Date" followed
- by a date-time specification.
-
-orig-date = "Date:" date-time CRLF
-
- The origination date specifies the date and time at which the creator
- of the message indicated that the message was complete and ready to
- enter the mail delivery system. For instance, this might be the time
- that a user pushes the "send" or "submit" button in an application
- program. In any case, it is specifically not intended to convey the
- time that the message is actually transported, but rather the time at
- which the human or other creator of the message has put the message
- into its final form, ready for transport. (For example, a portable
- computer user who is not connected to a network might queue a message
-
-
-
-
-Resnick Standards Track [Page 20]
-
-RFC 2822 Internet Message Format April 2001
-
-
- for delivery. The origination date is intended to contain the date
- and time that the user queued the message, not the time when the user
- connected to the network to send the message.)
-
-3.6.2. Originator fields
-
- The originator fields of a message consist of the from field, the
- sender field (when applicable), and optionally the reply-to field.
- The from field consists of the field name "From" and a
- comma-separated list of one or more mailbox specifications. If the
- from field contains more than one mailbox specification in the
- mailbox-list, then the sender field, containing the field name
- "Sender" and a single mailbox specification, MUST appear in the
- message. In either case, an optional reply-to field MAY also be
- included, which contains the field name "Reply-To" and a
- comma-separated list of one or more addresses.
-
-from = "From:" mailbox-list CRLF
-
-sender = "Sender:" mailbox CRLF
-
-reply-to = "Reply-To:" address-list CRLF
-
- The originator fields indicate the mailbox(es) of the source of the
- message. The "From:" field specifies the author(s) of the message,
- that is, the mailbox(es) of the person(s) or system(s) responsible
- for the writing of the message. The "Sender:" field specifies the
- mailbox of the agent responsible for the actual transmission of the
- message. For example, if a secretary were to send a message for
- another person, the mailbox of the secretary would appear in the
- "Sender:" field and the mailbox of the actual author would appear in
- the "From:" field. If the originator of the message can be indicated
- by a single mailbox and the author and transmitter are identical, the
- "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD
- appear.
-
- The originator fields also provide the information required when
- replying to a message. When the "Reply-To:" field is present, it
- indicates the mailbox(es) to which the author of the message suggests
- that replies be sent. In the absence of the "Reply-To:" field,
- replies SHOULD by default be sent to the mailbox(es) specified in the
- "From:" field unless otherwise specified by the person composing the
- reply.
-
- In all cases, the "From:" field SHOULD NOT contain any mailbox that
- does not belong to the author(s) of the message. See also section
- 3.6.3 for more information on forming the destination addresses for a
- reply.
-
-
-
-Resnick Standards Track [Page 21]
-
-RFC 2822 Internet Message Format April 2001
-
-
-3.6.3. Destination address fields
-
- The destination fields of a message consist of three possible fields,
- each of the same form: The field name, which is either "To", "Cc", or
- "Bcc", followed by a comma-separated list of one or more addresses
- (either mailbox or group syntax).
-
-to = "To:" address-list CRLF
-
-cc = "Cc:" address-list CRLF
-
-bcc = "Bcc:" (address-list / [CFWS]) CRLF
-
- The destination fields specify the recipients of the message. Each
- destination field may have one or more addresses, and each of the
- addresses indicate the intended recipients of the message. The only
- difference between the three fields is how each is used.
-
- The "To:" field contains the address(es) of the primary recipient(s)
- of the message.
-
- The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of
- making a copy on a typewriter using carbon paper) contains the
- addresses of others who are to receive the message, though the
- content of the message may not be directed at them.
-
- The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
- addresses of recipients of the message whose addresses are not to be
- revealed to other recipients of the message. There are three ways in
- which the "Bcc:" field is used. In the first case, when a message
- containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
- removed even though all of the recipients (including those specified
- in the "Bcc:" field) are sent a copy of the message. In the second
- case, recipients specified in the "To:" and "Cc:" lines each are sent
- a copy of the message with the "Bcc:" line removed as above, but the
- recipients on the "Bcc:" line get a separate copy of the message
- containing a "Bcc:" line. (When there are multiple recipient
- addresses in the "Bcc:" field, some implementations actually send a
- separate copy of the message to each recipient with a "Bcc:"
- containing only the address of that particular recipient.) Finally,
- since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
- sent without any addresses indicating to the recipients that blind
- copies were sent to someone. Which method to use with "Bcc:" fields
- is implementation dependent, but refer to the "Security
- Considerations" section of this document for a discussion of each.
-
-
-
-
-
-
-Resnick Standards Track [Page 22]
-
-RFC 2822 Internet Message Format April 2001
-
-
- When a message is a reply to another message, the mailboxes of the
- authors of the original message (the mailboxes in the "From:" field)
- or mailboxes specified in the "Reply-To:" field (if it exists) MAY
- appear in the "To:" field of the reply since these would normally be
- the primary recipients of the reply. If a reply is sent to a message
- that has destination fields, it is often desirable to send a copy of
- the reply to all of the recipients of the message, in addition to the
- author. When such a reply is formed, addresses in the "To:" and
- "Cc:" fields of the original message MAY appear in the "Cc:" field of
- the reply, since these are normally secondary recipients of the
- reply. If a "Bcc:" field is present in the original message,
- addresses in that field MAY appear in the "Bcc:" field of the reply,
- but SHOULD NOT appear in the "To:" or "Cc:" fields.
-
- Note: Some mail applications have automatic reply commands that
- include the destination addresses of the original message in the
- destination addresses of the reply. How those reply commands behave
- is implementation dependent and is beyond the scope of this document.
- In particular, whether or not to include the original destination
- addresses when the original message had a "Reply-To:" field is not
- addressed here.
-
-3.6.4. Identification fields
-
- Though optional, every message SHOULD have a "Message-ID:" field.
- Furthermore, reply messages SHOULD have "In-Reply-To:" and
- "References:" fields as appropriate, as described below.
-
- The "Message-ID:" field contains a single unique message identifier.
- The "References:" and "In-Reply-To:" field each contain one or more
- unique message identifiers, optionally separated by CFWS.
-
- The message identifier (msg-id) is similar in syntax to an angle-addr
- construct without the internal CFWS.
-
-message-id = "Message-ID:" msg-id CRLF
-
-in-reply-to = "In-Reply-To:" 1*msg-id CRLF
-
-references = "References:" 1*msg-id CRLF
-
-msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]
-
-id-left = dot-atom-text / no-fold-quote / obs-id-left
-
-id-right = dot-atom-text / no-fold-literal / obs-id-right
-
-no-fold-quote = DQUOTE *(qtext / quoted-pair) DQUOTE
-
-
-
-Resnick Standards Track [Page 23]
-
-RFC 2822 Internet Message Format April 2001
-
-
-no-fold-literal = "[" *(dtext / quoted-pair) "]"
-
- The "Message-ID:" field provides a unique message identifier that
- refers to a particular version of a particular message. The
- uniqueness of the message identifier is guaranteed by the host that
- generates it (see below). This message identifier is intended to be
- machine readable and not necessarily meaningful to humans. A message
- identifier pertains to exactly one instantiation of a particular
- message; subsequent revisions to the message each receive new message
- identifiers.
-
- Note: There are many instances when messages are "changed", but those
- changes do not constitute a new instantiation of that message, and
- therefore the message would not get a new message identifier. For
- example, when messages are introduced into the transport system, they
- are often prepended with additional header fields such as trace
- fields (described in section 3.6.7) and resent fields (described in
- section 3.6.6). The addition of such header fields does not change
- the identity of the message and therefore the original "Message-ID:"
- field is retained. In all cases, it is the meaning that the sender
- of the message wishes to convey (i.e., whether this is the same
- message or a different message) that determines whether or not the
- "Message-ID:" field changes, not any particular syntactic difference
- that appears (or does not appear) in the message.
-
- The "In-Reply-To:" and "References:" fields are used when creating a
- reply to a message. They hold the message identifier of the original
- message and the message identifiers of other messages (for example,
- in the case of a reply to a message which was itself a reply). The
- "In-Reply-To:" field may be used to identify the message (or
- messages) to which the new message is a reply, while the
- "References:" field may be used to identify a "thread" of
- conversation.
-
- When creating a reply to a message, the "In-Reply-To:" and
- "References:" fields of the resultant message are constructed as
- follows:
-
- The "In-Reply-To:" field will contain the contents of the "Message-
- ID:" field of the message to which this one is a reply (the "parent
- message"). If there is more than one parent message, then the "In-
- Reply-To:" field will contain the contents of all of the parents'
- "Message-ID:" fields. If there is no "Message-ID:" field in any of
- the parent messages, then the new message will have no "In-Reply-To:"
- field.
-
-
-
-
-
-
-Resnick Standards Track [Page 24]
-
-RFC 2822 Internet Message Format April 2001
-
-
- The "References:" field will contain the contents of the parent's
- "References:" field (if any) followed by the contents of the parent's
- "Message-ID:" field (if any). If the parent message does not contain
- a "References:" field but does have an "In-Reply-To:" field
- containing a single message identifier, then the "References:" field
- will contain the contents of the parent's "In-Reply-To:" field
- followed by the contents of the parent's "Message-ID:" field (if
- any). If the parent has none of the "References:", "In-Reply-To:",
- or "Message-ID:" fields, then the new message will have no
- "References:" field.
-
- Note: Some implementations parse the "References:" field to display
- the "thread of the discussion". These implementations assume that
- each new message is a reply to a single parent and hence that they
- can walk backwards through the "References:" field to find the parent
- of each message listed there. Therefore, trying to form a
- "References:" field for a reply that has multiple parents is
- discouraged and how to do so is not defined in this document.
-
- The message identifier (msg-id) itself MUST be a globally unique
- identifier for a message. The generator of the message identifier
- MUST guarantee that the msg-id is unique. There are several
- algorithms that can be used to accomplish this. Since the msg-id has
- a similar syntax to angle-addr (identical except that comments and
- folding white space are not allowed), a good method is to put the
- domain name (or a domain literal IP address) of the host on which the
- message identifier was created on the right hand side of the "@", and
- put a combination of the current absolute date and time along with
- some other currently unique (perhaps sequential) identifier available
- on the system (for example, a process id number) on the left hand
- side. Using a date on the left hand side and a domain name or domain
- literal on the right hand side makes it possible to guarantee
- uniqueness since no two hosts use the same domain name or IP address
- at the same time. Though other algorithms will work, it is
- RECOMMENDED that the right hand side contain some domain identifier
- (either of the host itself or otherwise) such that the generator of
- the message identifier can guarantee the uniqueness of the left hand
- side within the scope of that domain.
-
- Semantically, the angle bracket characters are not part of the
- msg-id; the msg-id is what is contained between the two angle bracket
- characters.
-
-
-
-
-
-
-
-
-
-Resnick Standards Track [Page 25]
-
-RFC 2822 Internet Message Format April 2001
-
-
-3.6.5. Informational fields
-
- The informational fields are all optional. The "Keywords:" field
- contains a comma-separated list of one or more words or
- quoted-strings. The "Subject:" and "Comments:" fields are
- unstructured fields as defined in section 2.2.1, and therefore may
- contain text or folding white space.
-
-subject = "Subject:" unstructured CRLF
-
-comments = "Comments:" unstructured CRLF
-
-keywords = "Keywords:" phrase *("," phrase) CRLF
-
- These three fields are intended to have only human-readable content
- with information about the message. The "Subject:" field is the most
- common and contains a short string identifying the topic of the
- message. When used in a reply, the field body MAY start with the
- string "Re: " (from the Latin "res", in the matter of) followed by
- the contents of the "Subject:" field body of the original message.
- If this is done, only one instance of the literal string "Re: " ought
- to be used since use of other strings or more than one instance can
- lead to undesirable consequences. The "Comments:" field contains any
- additional comments on the text of the body of the message. The
- "Keywords:" field contains a comma-separated list of important words
- and phrases that might be useful for the recipient.
-
-3.6.6. Resent fields
-
- Resent fields SHOULD be added to any message that is reintroduced by
- a user into the transport system. A separate set of resent fields
- SHOULD be added each time this is done. All of the resent fields
- corresponding to a particular resending of the message SHOULD be
- together. Each new set of resent fields is prepended to the message;
- that is, the most recent set of resent fields appear earlier in the
- message. No other fields in the message are changed when resent
- fields are added.
-
- Each of the resent fields corresponds to a particular field elsewhere
- in the syntax. For instance, the "Resent-Date:" field corresponds to
- the "Date:" field and the "Resent-To:" field corresponds to the "To:"
- field. In each case, the syntax for the field body is identical to
- the syntax given previously for the corresponding field.
-
- When resent fields are used, the "Resent-From:" and "Resent-Date:"
- fields MUST be sent. The "Resent-Message-ID:" field SHOULD be sent.
- "Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be
- identical to "Resent-From:".
-
-
-
-Resnick Standards Track [Page 26]
-
-RFC 2822 Internet Message Format April 2001
-
-
-resent-date = "Resent-Date:" date-time CRLF
-
-resent-from = "Resent-From:" mailbox-list CRLF
-
-resent-sender = "Resent-Sender:" mailbox CRLF
-
-resent-to = "Resent-To:" address-list CRLF
-
-resent-cc = "Resent-Cc:" address-list CRLF
-
-resent-bcc = "Resent-Bcc:" (address-list / [CFWS]) CRLF
-
-resent-msg-id = "Resent-Message-ID:" msg-id CRLF
-
- Resent fields are used to identify a message as having been
- reintroduced into the transport system by a user. The purpose of
- using resent fields is to have the message appear to the final
- recipient as if it were sent directly by the original sender, with
- all of the original fields remaining the same. Each set of resent
- fields correspond to a particular resending event. That is, if a
- message is resent multiple times, each set of resent fields gives
- identifying information for each individual time. Resent fields are
- strictly informational. They MUST NOT be used in the normal
- processing of replies or other such automatic actions on messages.
-
- Note: Reintroducing a message into the transport system and using
- resent fields is a different operation from "forwarding".
- "Forwarding" has two meanings: One sense of forwarding is that a mail
- reading program can be told by a user to forward a copy of a message
- to another person, making the forwarded message the body of the new
- message. A forwarded message in this sense does not appear to have
- come from the original sender, but is an entirely new message from
- the forwarder of the message. On the other hand, forwarding is also
- used to mean when a mail transport program gets a message and
- forwards it on to a different destination for final delivery. Resent
- header fields are not intended for use with either type of
- forwarding.
-
- The resent originator fields indicate the mailbox of the person(s) or
- system(s) that resent the message. As with the regular originator
- fields, there are two forms: a simple "Resent-From:" form which
- contains the mailbox of the individual doing the resending, and the
- more complex form, when one individual (identified in the
- "Resent-Sender:" field) resends a message on behalf of one or more
- others (identified in the "Resent-From:" field).
-
- Note: When replying to a resent message, replies behave just as they
- would with any other message, using the original "From:",
-
-
-
-Resnick Standards Track [Page 27]
-
-RFC 2822 Internet Message Format April 2001
-
-
- "Reply-To:", "Message-ID:", and other fields. The resent fields are
- only informational and MUST NOT be used in the normal processing of
- replies.
-
- The "Resent-Date:" indicates the date and time at which the resent
- message is dispatched by the resender of the message. Like the
- "Date:" field, it is not the date and time that the message was
- actually transported.
-
- The "Resent-To:", "Resent-Cc:", and "Resent-Bcc:" fields function
- identically to the "To:", "Cc:", and "Bcc:" fields respectively,
- except that they indicate the recipients of the resent message, not
- the recipients of the original message.
-
- The "Resent-Message-ID:" field provides a unique identifier for the
- resent message.
-
-3.6.7. Trace fields
-
- The trace fields are a group of header fields consisting of an
- optional "Return-Path:" field, and one or more "Received:" fields.
- The "Return-Path:" header field contains a pair of angle brackets
- that enclose an optional addr-spec. The "Received:" field contains a
- (possibly empty) list of name/value pairs followed by a semicolon and
- a date-time specification. The first item of the name/value pair is
- defined by item-name, and the second item is either an addr-spec, an
- atom, a domain, or a msg-id. Further restrictions may be applied to
- the syntax of the trace fields by standards that provide for their
- use, such as [RFC2821].
-
-trace = [return]
- 1*received
-
-return = "Return-Path:" path CRLF
-
-path = ([CFWS] "<" ([CFWS] / addr-spec) ">" [CFWS]) /
- obs-path
-
-received = "Received:" name-val-list ";" date-time CRLF
-
-name-val-list = [CFWS] [name-val-pair *(CFWS name-val-pair)]
-
-name-val-pair = item-name CFWS item-value
-
-item-name = ALPHA *(["-"] (ALPHA / DIGIT))
-
-item-value = 1*angle-addr / addr-spec /
- atom / domain / msg-id
-
-
-
-Resnick Standards Track [Page 28]
-
-RFC 2822 Internet Message Format April 2001
-
-
- A full discussion of the Internet mail use of trace fields is
- contained in [RFC2821]. For the purposes of this standard, the trace
- fields are strictly informational, and any formal interpretation of
- them is outside of the scope of this document.
-
-3.6.8. Optional fields
-
- Fields may appear in messages that are otherwise unspecified in this
- standard. They MUST conform to the syntax of an optional-field.
- This is a field name, made up of the printable US-ASCII characters
- except SP and colon, followed by a colon, followed by any text which
- conforms to unstructured.
-
- The field names of any optional-field MUST NOT be identical to any
- field name specified elsewhere in this standard.
-
-optional-field = field-name ":" unstructured CRLF
-
-field-name = 1*ftext
-
-ftext = %d33-57 / ; Any character except
- %d59-126 ; controls, SP, and
- ; ":".
-
- For the purposes of this standard, any optional field is
- uninterpreted.
-
-4. Obsolete Syntax
-
- Earlier versions of this standard allowed for different (usually more
- liberal) syntax than is allowed in this version. Also, there have
- been syntactic elements used in messages on the Internet whose
- interpretation have never been documented. Though some of these
- syntactic forms MUST NOT be generated according to the grammar in
- section 3, they MUST be accepted and parsed by a conformant receiver.
- This section documents many of these syntactic elements. Taking the
- grammar in section 3 and adding the definitions presented in this
- section will result in the grammar to use for interpretation of
- messages.
-
- Note: This section identifies syntactic forms that any implementation
- MUST reasonably interpret. However, there are certainly Internet
- messages which do not conform to even the additional syntax given in
- this section. The fact that a particular form does not appear in any
- section of this document is not justification for computer programs
- to crash or for malformed data to be irretrievably lost by any
- implementation. To repeat an example, though this document requires
- lines in messages to be no longer than 998 characters, silently
-
-
-
-Resnick Standards Track [Page 29]
-
-RFC 2822 Internet Message Format April 2001
-
-
- discarding the 999th and subsequent characters in a line without
- warning would still be bad behavior for an implementation. It is up
- to the implementation to deal with messages robustly.
-
- One important difference between the obsolete (interpreting) and the
- current (generating) syntax is that in structured header field bodies
- (i.e., between the colon and the CRLF of any structured header
- field), white space characters, including folding white space, and
- comments can be freely inserted between any syntactic tokens. This
- allows many complex forms that have proven difficult for some
- implementations to parse.
-
- Another key difference between the obsolete and the current syntax is
- that the rule in section 3.2.3 regarding lines composed entirely of
- white space in comments and folding white space does not apply. See
- the discussion of folding white space in section 4.2 below.
-
- Finally, certain characters that were formerly allowed in messages
- appear in this section. The NUL character (ASCII value 0) was once
- allowed, but is no longer for compatibility reasons. CR and LF were
- allowed to appear in messages other than as CRLF; this use is also
- shown here.
-
- Other differences in syntax and semantics are noted in the following
- sections.
-
-4.1. Miscellaneous obsolete tokens
-
- These syntactic elements are used elsewhere in the obsolete syntax or
- in the main syntax. The obs-char and obs-qp elements each add ASCII
- value 0. Bare CR and bare LF are added to obs-text and obs-utext.
- The period character is added to obs-phrase. The obs-phrase-list
- provides for "empty" elements in a comma-separated list of phrases.
-
- Note: The "period" (or "full stop") character (".") in obs-phrase is
- not a form that was allowed in earlier versions of this or any other
- standard. Period (nor any other character from specials) was not
- allowed in phrase because it introduced a parsing difficulty
- distinguishing between phrases and portions of an addr-spec (see
- section 4.4). It appears here because the period character is
- currently used in many messages in the display-name portion of
- addresses, especially for initials in names, and therefore must be
- interpreted properly. In the future, period may appear in the
- regular syntax of phrase.
-
-obs-qp = "\" (%d0-127)
-
-obs-text = *LF *CR *(obs-char *LF *CR)
-
-
-
-Resnick Standards Track [Page 30]
-
-RFC 2822 Internet Message Format April 2001
-
-
-obs-char = %d0-9 / %d11 / ; %d0-127 except CR and
- %d12 / %d14-127 ; LF
-
-obs-utext = obs-text
-
-obs-phrase = word *(word / "." / CFWS)
-
-obs-phrase-list = phrase / 1*([phrase] [CFWS] "," [CFWS]) [phrase]
-
- Bare CR and bare LF appear in messages with two different meanings.
- In many cases, bare CR or bare LF are used improperly instead of CRLF
- to indicate line separators. In other cases, bare CR and bare LF are
- used simply as ASCII control characters with their traditional ASCII
- meanings.
-
-4.2. Obsolete folding white space
-
- In the obsolete syntax, any amount of folding white space MAY be
- inserted where the obs-FWS rule is allowed. This creates the
- possibility of having two consecutive "folds" in a line, and
- therefore the possibility that a line which makes up a folded header
- field could be composed entirely of white space.
-
- obs-FWS = 1*WSP *(CRLF 1*WSP)
-
-4.3. Obsolete Date and Time
-
- The syntax for the obsolete date format allows a 2 digit year in the
- date field and allows for a list of alphabetic time zone
- specifications that were used in earlier versions of this standard.
- It also permits comments and folding white space between many of the
- tokens.
-
-obs-day-of-week = [CFWS] day-name [CFWS]
-
-obs-year = [CFWS] 2*DIGIT [CFWS]
-
-obs-month = CFWS month-name CFWS
-
-obs-day = [CFWS] 1*2DIGIT [CFWS]
-
-obs-hour = [CFWS] 2DIGIT [CFWS]
-
-obs-minute = [CFWS] 2DIGIT [CFWS]
-
-obs-second = [CFWS] 2DIGIT [CFWS]
-
-obs-zone = "UT" / "GMT" / ; Universal Time
-
-
-
-Resnick Standards Track [Page 31]
-
-RFC 2822 Internet Message Format April 2001
-
-
- ; North American UT
- ; offsets
- "EST" / "EDT" / ; Eastern: - 5/ - 4
- "CST" / "CDT" / ; Central: - 6/ - 5
- "MST" / "MDT" / ; Mountain: - 7/ - 6
- "PST" / "PDT" / ; Pacific: - 8/ - 7
-
- %d65-73 / ; Military zones - "A"
- %d75-90 / ; through "I" and "K"
- %d97-105 / ; through "Z", both
- %d107-122 ; upper and lower case
-
- Where a two or three digit year occurs in a date, the year is to be
- interpreted as follows: If a two digit year is encountered whose
- value is between 00 and 49, the year is interpreted by adding 2000,
- ending up with a value between 2000 and 2049. If a two digit year is
- encountered with a value between 50 and 99, or any three digit year
- is encountered, the year is interpreted by adding 1900.
-
- In the obsolete time zone, "UT" and "GMT" are indications of
- "Universal Time" and "Greenwich Mean Time" respectively and are both
- semantically identical to "+0000".
-
- The remaining three character zones are the US time zones. The first
- letter, "E", "C", "M", or "P" stands for "Eastern", "Central",
- "Mountain" and "Pacific". The second letter is either "S" for
- "Standard" time, or "D" for "Daylight" (or summer) time. Their
- interpretations are as follows:
-
- EDT is semantically equivalent to -0400
- EST is semantically equivalent to -0500
- CDT is semantically equivalent to -0500
- CST is semantically equivalent to -0600
- MDT is semantically equivalent to -0600
- MST is semantically equivalent to -0700
- PDT is semantically equivalent to -0700
- PST is semantically equivalent to -0800
-
- The 1 character military time zones were defined in a non-standard
- way in [RFC822] and are therefore unpredictable in their meaning.
- The original definitions of the military zones "A" through "I" are
- equivalent to "+0100" through "+0900" respectively; "K", "L", and "M"
- are equivalent to "+1000", "+1100", and "+1200" respectively; "N"
- through "Y" are equivalent to "-0100" through "-1200" respectively;
- and "Z" is equivalent to "+0000". However, because of the error in
- [RFC822], they SHOULD all be considered equivalent to "-0000" unless
- there is out-of-band information confirming their meaning.
-
-
-
-
-Resnick Standards Track [Page 32]
-
-RFC 2822 Internet Message Format April 2001
-
-
- Other multi-character (usually between 3 and 5) alphabetic time zones
- have been used in Internet messages. Any such time zone whose
- meaning is not known SHOULD be considered equivalent to "-0000"
- unless there is out-of-band information confirming their meaning.
-
-4.4. Obsolete Addressing
-
- There are three primary differences in addressing. First, mailbox
- addresses were allowed to have a route portion before the addr-spec
- when enclosed in "<" and ">". The route is simply a comma-separated
- list of domain names, each preceded by "@", and the list terminated
- by a colon. Second, CFWS were allowed between the period-separated
- elements of local-part and domain (i.e., dot-atom was not used). In
- addition, local-part is allowed to contain quoted-string in addition
- to just atom. Finally, mailbox-list and address-list were allowed to
- have "null" members. That is, there could be two or more commas in
- such a list with nothing in between them.
-
-obs-angle-addr = [CFWS] "<" [obs-route] addr-spec ">" [CFWS]
-
-obs-route = [CFWS] obs-domain-list ":" [CFWS]
-
-obs-domain-list = "@" domain *(*(CFWS / "," ) [CFWS] "@" domain)
-
-obs-local-part = word *("." word)
-
-obs-domain = atom *("." atom)
-
-obs-mbox-list = 1*([mailbox] [CFWS] "," [CFWS]) [mailbox]
-
-obs-addr-list = 1*([address] [CFWS] "," [CFWS]) [address]
-
- When interpreting addresses, the route portion SHOULD be ignored.
-
-4.5. Obsolete header fields
-
- Syntactically, the primary difference in the obsolete field syntax is
- that it allows multiple occurrences of any of the fields and they may
- occur in any order. Also, any amount of white space is allowed
- before the ":" at the end of the field name.
-
-obs-fields = *(obs-return /
- obs-received /
- obs-orig-date /
- obs-from /
- obs-sender /
- obs-reply-to /
- obs-to /
-
-
-
-Resnick Standards Track [Page 33]
-
-RFC 2822 Internet Message Format April 2001
-
-
- obs-cc /
- obs-bcc /
- obs-message-id /
- obs-in-reply-to /
- obs-references /
- obs-subject /
- obs-comments /
- obs-keywords /
- obs-resent-date /
- obs-resent-from /
- obs-resent-send /
- obs-resent-rply /
- obs-resent-to /
- obs-resent-cc /
- obs-resent-bcc /
- obs-resent-mid /
- obs-optional)
-
- Except for destination address fields (described in section 4.5.3),
- the interpretation of multiple occurrences of fields is unspecified.
- Also, the interpretation of trace fields and resent fields which do
- not occur in blocks prepended to the message is unspecified as well.
- Unless otherwise noted in the following sections, interpretation of
- other fields is identical to the interpretation of their non-obsolete
- counterparts in section 3.
-
-4.5.1. Obsolete origination date field
-
-obs-orig-date = "Date" *WSP ":" date-time CRLF
-
-4.5.2. Obsolete originator fields
-
-obs-from = "From" *WSP ":" mailbox-list CRLF
-
-obs-sender = "Sender" *WSP ":" mailbox CRLF
-
-obs-reply-to = "Reply-To" *WSP ":" mailbox-list CRLF
-
-4.5.3. Obsolete destination address fields
-
-obs-to = "To" *WSP ":" address-list CRLF
-
-obs-cc = "Cc" *WSP ":" address-list CRLF
-
-obs-bcc = "Bcc" *WSP ":" (address-list / [CFWS]) CRLF
-
-
-
-
-
-
-Resnick Standards Track [Page 34]
-
-RFC 2822 Internet Message Format April 2001
-
-
- When multiple occurrences of destination address fields occur in a
- message, they SHOULD be treated as if the address-list in the first
- occurrence of the field is combined with the address lists of the
- subsequent occurrences by adding a comma and concatenating.
-
-4.5.4. Obsolete identification fields
-
- The obsolete "In-Reply-To:" and "References:" fields differ from the
- current syntax in that they allow phrase (words or quoted strings) to
- appear. The obsolete forms of the left and right sides of msg-id
- allow interspersed CFWS, making them syntactically identical to
- local-part and domain respectively.
-
-obs-message-id = "Message-ID" *WSP ":" msg-id CRLF
-
-obs-in-reply-to = "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF
-
-obs-references = "References" *WSP ":" *(phrase / msg-id) CRLF
-
-obs-id-left = local-part
-
-obs-id-right = domain
-
- For purposes of interpretation, the phrases in the "In-Reply-To:" and
- "References:" fields are ignored.
-
- Semantically, none of the optional CFWS surrounding the local-part
- and the domain are part of the obs-id-left and obs-id-right
- respectively.
-
-4.5.5. Obsolete informational fields
-
-obs-subject = "Subject" *WSP ":" unstructured CRLF
-
-obs-comments = "Comments" *WSP ":" unstructured CRLF
-
-obs-keywords = "Keywords" *WSP ":" obs-phrase-list CRLF
-
-4.5.6. Obsolete resent fields
-
- The obsolete syntax adds a "Resent-Reply-To:" field, which consists
- of the field name, the optional comments and folding white space, the
- colon, and a comma separated list of addresses.
-
-obs-resent-from = "Resent-From" *WSP ":" mailbox-list CRLF
-
-obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF
-
-
-
-
-Resnick Standards Track [Page 35]
-
-RFC 2822 Internet Message Format April 2001
-
-
-obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF
-
-obs-resent-to = "Resent-To" *WSP ":" address-list CRLF
-
-obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF
-
-obs-resent-bcc = "Resent-Bcc" *WSP ":"
- (address-list / [CFWS]) CRLF
-
-obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF
-
-obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF
-
- As with other resent fields, the "Resent-Reply-To:" field is to be
- treated as trace information only.
-
-4.5.7. Obsolete trace fields
-
- The obs-return and obs-received are again given here as template
- definitions, just as return and received are in section 3. Their
- full syntax is given in [RFC2821].
-
-obs-return = "Return-Path" *WSP ":" path CRLF
-
-obs-received = "Received" *WSP ":" name-val-list CRLF
-
-obs-path = obs-angle-addr
-
-4.5.8. Obsolete optional fields
-
-obs-optional = field-name *WSP ":" unstructured CRLF
-
-5. Security Considerations
-
- Care needs to be taken when displaying messages on a terminal or
- terminal emulator. Powerful terminals may act on escape sequences
- and other combinations of ASCII control characters with a variety of
- consequences. They can remap the keyboard or permit other
- modifications to the terminal which could lead to denial of service
- or even damaged data. They can trigger (sometimes programmable)
- answerback messages which can allow a message to cause commands to be
- issued on the recipient's behalf. They can also effect the operation
- of terminal attached devices such as printers. Message viewers may
- wish to strip potentially dangerous terminal escape sequences from
- the message prior to display. However, other escape sequences appear
- in messages for useful purposes (cf. [RFC2045, RFC2046, RFC2047,
- RFC2048, RFC2049, ISO2022]) and therefore should not be stripped
- indiscriminately.
-
-
-
-Resnick Standards Track [Page 36]
-
-RFC 2822 Internet Message Format April 2001
-
-
- Transmission of non-text objects in messages raises additional
- security issues. These issues are discussed in [RFC2045, RFC2046,
- RFC2047, RFC2048, RFC2049].
-
- Many implementations use the "Bcc:" (blind carbon copy) field
- described in section 3.6.3 to facilitate sending messages to
- recipients without revealing the addresses of one or more of the
- addressees to the other recipients. Mishandling this use of "Bcc:"
- has implications for confidential information that might be revealed,
- which could eventually lead to security problems through knowledge of
- even the existence of a particular mail address. For example, if
- using the first method described in section 3.6.3, where the "Bcc:"
- line is removed from the message, blind recipients have no explicit
- indication that they have been sent a blind copy, except insofar as
- their address does not appear in the message header. Because of
- this, one of the blind addressees could potentially send a reply to
- all of the shown recipients and accidentally reveal that the message
- went to the blind recipient. When the second method from section
- 3.6.3 is used, the blind recipient's address appears in the "Bcc:"
- field of a separate copy of the message. If the "Bcc:" field sent
- contains all of the blind addressees, all of the "Bcc:" recipients
- will be seen by each "Bcc:" recipient. Even if a separate message is
- sent to each "Bcc:" recipient with only the individual's address,
- implementations still need to be careful to process replies to the
- message as per section 3.6.3 so as not to accidentally reveal the
- blind recipient to other recipients.
-
-6. Bibliography
-
- [ASCII] American National Standards Institute (ANSI), Coded
- Character Set - 7-Bit American National Standard Code for
- Information Interchange, ANSI X3.4, 1986.
-
- [ISO2022] International Organization for Standardization (ISO),
- Information processing - ISO 7-bit and 8-bit coded
- character sets - Code extension techniques, Third edition
- - 1986-05-01, ISO 2022, 1986.
-
- [RFC822] Crocker, D., "Standard for the Format of ARPA Internet
- Text Messages", RFC 822, August 1982.
-
- [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message
- Bodies", RFC 2045, November 1996.
-
- [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part Two: Media Types", RFC 2046,
- November 1996.
-
-
-
-Resnick Standards Track [Page 37]
-
-RFC 2822 Internet Message Format April 2001
-
-
- [RFC2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME)
- Part Three: Message Header Extensions for Non-ASCII Text",
- RFC 2047, November 1996.
-
- [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
- Internet Mail Extensions (MIME) Part Four: Format of
- Internet Message Bodies", RFC 2048, November 1996.
-
- [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part Five: Conformance Criteria and
- Examples", RFC 2049, November 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2234] Crocker, D., Editor, and P. Overell, "Augmented BNF for
- Syntax Specifications: ABNF", RFC 2234, November 1997.
-
- [RFC2821] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC
- 2821, March 2001.
-
- [STD3] Braden, R., "Host Requirements", STD 3, RFC 1122 and RFC
- 1123, October 1989.
-
- [STD12] Mills, D., "Network Time Protocol", STD 12, RFC 1119,
- September 1989.
-
- [STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034
- and RFC 1035, November 1987.
-
- [STD14] Partridge, C., "Mail Routing and the Domain System", STD
- 14, RFC 974, January 1986.
-
-7. Editor's Address
-
- Peter W. Resnick
- QUALCOMM Incorporated
- 5775 Morehouse Drive
- San Diego, CA 92121-1714
- USA
-
- Phone: +1 858 651 4478
- Fax: +1 858 651 1102
- EMail: address@hidden
-
-
-
-
-
-
-
-Resnick Standards Track [Page 38]
-
-RFC 2822 Internet Message Format April 2001
-
-
-8. Acknowledgements
-
- Many people contributed to this document. They included folks who
- participated in the Detailed Revision and Update of Messaging
- Standards (DRUMS) Working Group of the Internet Engineering Task
- Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and
- people who simply sent their comments in via e-mail. The editor is
- deeply indebted to them all and thanks them sincerely. The below
- list includes everyone who sent e-mail concerning this document.
- Hopefully, everyone who contributed is named here:
-
- Matti Aarnio Barry Finkel Larry Masinter
- Tanaka Akira Erik Forsberg Denis McKeon
- Russ Allbery Chuck Foster William P McQuillan
- Eric Allman Paul Fox Alexey Melnikov
- Harald Tveit Alvestrand Klaus M. Frank Perry E. Metzger
- Ran Atkinson Ned Freed Steven Miller
- Jos Backus Jochen Friedrich Keith Moore
- Bruce Balden Randall C. Gellens John Gardiner Myers
- Dave Barr Sukvinder Singh Gill Chris Newman
- Alan Barrett Tim Goodwin John W. Noerenberg
- John Beck Philip Guenther Eric Norman
- J. Robert von Behren Tony Hansen Mike O'Dell
- Jos den Bekker John Hawkinson Larry Osterman
- D. J. Bernstein Philip Hazel Paul Overell
- James Berriman Kai Henningsen Jacob Palme
- Norbert Bollow Robert Herriot Michael A. Patton
- Raj Bose Paul Hethmon Uzi Paz
- Antony Bowesman Jim Hill Michael A. Quinlan
- Scott Bradner Paul E. Hoffman Eric S. Raymond
- Randy Bush Steve Hole Sam Roberts
- Tom Byrer Kari Hurtta Hugh Sasse
- Bruce Campbell Marco S. Hyman Bart Schaefer
- Larry Campbell Ofer Inbar Tom Scola
- W. J. Carpenter Olle Jarnefors Wolfgang Segmuller
- Michael Chapman Kevin Johnson Nick Shelness
- Richard Clayton Sudish Joseph John Stanley
- Maurizio Codogno Maynard Kang Einar Stefferud
- Jim Conklin Prabhat Keni Jeff Stephenson
- R. Kelley Cook John C. Klensin Bernard Stern
- Steve Coya Graham Klyne Peter Sylvester
- Mark Crispin Brad Knowles Mark Symons
- Dave Crocker Shuhei Kobayashi Eric Thomas
- Matt Curtin Peter Koch Lee Thompson
- Michael D'Errico Dan Kohn Karel De Vriendt
- Cyrus Daboo Christian Kuhtz Matthew Wall
- Jutta Degener Anand Kumria Rolf Weber
- Mark Delany Steen Larsen Brent B. Welch
-
-
-
-Resnick Standards Track [Page 39]
-
-RFC 2822 Internet Message Format April 2001
-
-
- Steve Dorner Eliot Lear Dan Wing
- Harold A. Driscoll Barry Leiba Jack De Winter
- Michael Elkins Jay Levitt Gregory J. Woodhouse
- Robert Elz Lars-Johan Liman Greg A. Woods
- Johnny Eriksson Charles Lindsey Kazu Yamamoto
- Erik E. Fair Pete Loshin Alain Zahm
- Roger Fajman Simon Lyall Jamie Zawinski
- Patrik Faltstrom Bill Manning Timothy S. Zurcher
- Claus Andre Farber John Martin
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Resnick Standards Track [Page 40]
-
-RFC 2822 Internet Message Format April 2001
-
-
-Appendix A. Example messages
-
- This section presents a selection of messages. These are intended to
- assist in the implementation of this standard, but should not be
- taken as normative; that is to say, although the examples in this
- section were carefully reviewed, if there happens to be a conflict
- between these examples and the syntax described in sections 3 and 4
- of this document, the syntax in those sections is to be taken as
- correct.
-
- Messages are delimited in this section between lines of "----". The
- "----" lines are not part of the message itself.
-
-A.1. Addressing examples
-
- The following are examples of messages that might be sent between two
- individuals.
-
-A.1.1. A message from one person to another with simple addressing
-
- This could be called a canonical message. It has a single author,
- John Doe, a single recipient, Mary Smith, a subject, the date, a
- message identifier, and a textual message in the body.
-
-----
-From: John Doe <address@hidden>
-To: Mary Smith <address@hidden>
-Subject: Saying Hello
-Date: Fri, 21 Nov 1997 09:55:06 -0600
-Message-ID: <address@hidden>
-
-This is a message just to say hello.
-So, "Hello".
-----
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Resnick Standards Track [Page 41]
-
-RFC 2822 Internet Message Format April 2001
-
-
- If John's secretary Michael actually sent the message, though John
- was the author and replies to this message should go back to him, the
- sender field would be used:
-
-----
-From: John Doe <address@hidden>
-Sender: Michael Jones <address@hidden>
-To: Mary Smith <address@hidden>
-Subject: Saying Hello
-Date: Fri, 21 Nov 1997 09:55:06 -0600
-Message-ID: <address@hidden>
-
-This is a message just to say hello.
-So, "Hello".
-----
-
-A.1.2. Different types of mailboxes
-
- This message includes multiple addresses in the destination fields
- and also uses several different forms of addresses.
-
-----
-From: "Joe Q. Public" <address@hidden>
-To: Mary Smith <address@hidden>, address@hidden, Who? <address@hidden>
-Cc: <address@hidden>, "Giant; \"Big\" Box" <address@hidden>
-Date: Tue, 1 Jul 2003 10:52:37 +0200
-Message-ID: <address@hidden>
-
-Hi everyone.
-----
-
- Note that the display names for Joe Q. Public and Giant; "Big" Box
- needed to be enclosed in double-quotes because the former contains
- the period and the latter contains both semicolon and double-quote
- characters (the double-quote characters appearing as quoted-pair
- construct). Conversely, the display name for Who? could appear
- without them because the question mark is legal in an atom. Notice
- also that address@hidden and address@hidden have no display names
- associated with them at all, and address@hidden uses the simpler
- address form without the angle brackets.
-
-
-
-
-
-
-
-
-
-
-
-Resnick Standards Track [Page 42]
-
-RFC 2822 Internet Message Format April 2001
-
-
-A.1.3. Group addresses
-
-----
-From: Pete <address@hidden>
-To: A Group:Chris Jones <address@hidden>,address@hidden,John <address@hidden>;
-Cc: Undisclosed recipients:;
-Date: Thu, 13 Feb 1969 23:32:54 -0330
-Message-ID: <address@hidden>
-
-Testing.
-----
-
- In this message, the "To:" field has a single group recipient named A
- Group which contains 3 addresses, and a "Cc:" field with an empty
- group recipient named Undisclosed recipients.
-
-A.2. Reply messages
-
- The following is a series of three messages that make up a
- conversation thread between John and Mary. John firsts sends a
- message to Mary, Mary then replies to John's message, and then John
- replies to Mary's reply message.
-
- Note especially the "Message-ID:", "References:", and "In-Reply-To:"
- fields in each message.
-
-----
-From: John Doe <address@hidden>
-To: Mary Smith <address@hidden>
-Subject: Saying Hello
-Date: Fri, 21 Nov 1997 09:55:06 -0600
-Message-ID: <address@hidden>
-
-This is a message just to say hello.
-So, "Hello".
-----
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Resnick Standards Track [Page 43]
-
-RFC 2822 Internet Message Format April 2001
-
-
- When sending replies, the Subject field is often retained, though
- prepended with "Re: " as described in section 3.6.5.
-
-----
-From: Mary Smith <address@hidden>
-To: John Doe <address@hidden>
-Reply-To: "Mary Smith: Personal Account" <address@hidden>
-Subject: Re: Saying Hello
-Date: Fri, 21 Nov 1997 10:01:10 -0600
-Message-ID: <address@hidden>
-In-Reply-To: <address@hidden>
-References: <address@hidden>
-
-This is a reply to your hello.
-----
-
- Note the "Reply-To:" field in the above message. When John replies
- to Mary's message above, the reply should go to the address in the
- "Reply-To:" field instead of the address in the "From:" field.
-
-----
-To: "Mary Smith: Personal Account" <address@hidden>
-From: John Doe <address@hidden>
-Subject: Re: Saying Hello
-Date: Fri, 21 Nov 1997 11:00:00 -0600
-Message-ID: <address@hidden>
-In-Reply-To: <address@hidden>
-References: <address@hidden> <address@hidden>
-
-This is a reply to your reply.
-----
-
-A.3. Resent messages
-
- Start with the message that has been used as an example several
- times:
-
-----
-From: John Doe <address@hidden>
-To: Mary Smith <address@hidden>
-Subject: Saying Hello
-Date: Fri, 21 Nov 1997 09:55:06 -0600
-Message-ID: <address@hidden>
-
-This is a message just to say hello.
-So, "Hello".
-----
-
-
-
-
-Resnick Standards Track [Page 44]
-
-RFC 2822 Internet Message Format April 2001
-
-
- Say that Mary, upon receiving this message, wishes to send a copy of
- the message to Jane such that (a) the message would appear to have
- come straight from John; (b) if Jane replies to the message, the
- reply should go back to John; and (c) all of the original
- information, like the date the message was originally sent to Mary,
- the message identifier, and the original addressee, is preserved. In
- this case, resent fields are prepended to the message:
-
-----
-Resent-From: Mary Smith <address@hidden>
-Resent-To: Jane Brown <address@hidden>
-Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800
-Resent-Message-ID: <address@hidden>
-From: John Doe <address@hidden>
-To: Mary Smith <address@hidden>
-Subject: Saying Hello
-Date: Fri, 21 Nov 1997 09:55:06 -0600
-Message-ID: <address@hidden>
-
-This is a message just to say hello.
-So, "Hello".
-----
-
- If Jane, in turn, wished to resend this message to another person,
- she would prepend her own set of resent header fields to the above
- and send that.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Resnick Standards Track [Page 45]
-
-RFC 2822 Internet Message Format April 2001
-
-
-A.4. Messages with trace fields
-
- As messages are sent through the transport system as described in
- [RFC2821], trace fields are prepended to the message. The following
- is an example of what those trace fields might look like. Note that
- there is some folding white space in the first one since these lines
- can be long.
-
-----
-Received: from x.y.test
- by example.net
- via TCP
- with ESMTP
- id ABC12345
- for <address@hidden>; 21 Nov 1997 10:05:43 -0600
-Received: from machine.example by x.y.test; 21 Nov 1997 10:01:22 -0600
-From: John Doe <address@hidden>
-To: Mary Smith <address@hidden>
-Subject: Saying Hello
-Date: Fri, 21 Nov 1997 09:55:06 -0600
-Message-ID: <address@hidden>
-
-This is a message just to say hello.
-So, "Hello".
-----
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Resnick Standards Track [Page 46]
-
-RFC 2822 Internet Message Format April 2001
-
-
-A.5. White space, comments, and other oddities
-
- White space, including folding white space, and comments can be
- inserted between many of the tokens of fields. Taking the example
- from A.1.3, white space and comments can be inserted into all of the
- fields.
-
-----
-From: Pete(A wonderful \) chap) <pete(his account)@silly.test(his host)>
-To:A Group(Some people)
- :Chris Jones <c@(Chris's host.)public.example>,
- address@hidden,
- John <address@hidden> (my dear friend); (the end of the group)
-Cc:(Empty list)(start)Undisclosed recipients :(nobody(that I know)) ;
-Date: Thu,
- 13
- Feb
- 1969
- 23:32
- -0330 (Newfoundland Time)
-Message-ID: <address@hidden>
-
-Testing.
-----
-
- The above example is aesthetically displeasing, but perfectly legal.
- Note particularly (1) the comments in the "From:" field (including
- one that has a ")" character appearing as part of a quoted-pair); (2)
- the white space absent after the ":" in the "To:" field as well as
- the comment and folding white space after the group name, the special
- character (".") in the comment in Chris Jones's address, and the
- folding white space before and after "address@hidden,"; (3) the
- multiple and nested comments in the "Cc:" field as well as the
- comment immediately following the ":" after "Cc"; (4) the folding
- white space (but no comments except at the end) and the missing
- seconds in the time of the date field; and (5) the white space before
- (but not within) the identifier in the "Message-ID:" field.
-
-A.6. Obsoleted forms
-
- The following are examples of obsolete (that is, the "MUST NOT
- generate") syntactic elements described in section 4 of this
- document.
-
-
-
-
-
-
-
-
-Resnick Standards Track [Page 47]
-
-RFC 2822 Internet Message Format April 2001
-
-
-A.6.1. Obsolete addressing
-
- Note in the below example the lack of quotes around Joe Q. Public,
- the route that appears in the address for Mary Smith, the two commas
- that appear in the "To:" field, and the spaces that appear around the
- "." in the jdoe address.
-
-----
-From: Joe Q. Public <address@hidden>
-To: Mary Smith <@machine.tld:address@hidden>, , address@hidden . example
-Date: Tue, 1 Jul 2003 10:52:37 +0200
-Message-ID: <address@hidden>
-
-Hi everyone.
-----
-
-A.6.2. Obsolete dates
-
- The following message uses an obsolete date format, including a non-
- numeric time zone and a two digit year. Note that although the
- day-of-week is missing, that is not specific to the obsolete syntax;
- it is optional in the current syntax as well.
-
-----
-From: John Doe <address@hidden>
-To: Mary Smith <address@hidden>
-Subject: Saying Hello
-Date: 21 Nov 97 09:55:06 GMT
-Message-ID: <address@hidden>
-
-This is a message just to say hello.
-So, "Hello".
-----
-
-A.6.3. Obsolete white space and comments
-
- White space and comments can appear between many more elements than
- in the current syntax. Also, folding lines that are made up entirely
- of white space are legal.
-
-
-
-
-
-
-
-
-
-
-
-
-Resnick Standards Track [Page 48]
-
-RFC 2822 Internet Message Format April 2001
-
-
-----
-From : John Doe <address@hidden(comment). example>
-To : Mary Smith
-__
- <address@hidden>
-Subject : Saying Hello
-Date : Fri, 21 Nov 1997 09(comment): 55 : 06 -0600
-Message-ID : <1234 @ local(blah) .machine .example>
-
-This is a message just to say hello.
-So, "Hello".
-----
-
- Note especially the second line of the "To:" field. It starts with
- two space characters. (Note that "__" represent blank spaces.)
- Therefore, it is considered part of the folding as described in
- section 4.2. Also, the comments and white space throughout
- addresses, dates, and message identifiers are all part of the
- obsolete syntax.
-
-Appendix B. Differences from earlier standards
-
- This appendix contains a list of changes that have been made in the
- Internet Message Format from earlier standards, specifically [RFC822]
- and [STD3]. Items marked with an asterisk (*) below are items which
- appear in section 4 of this document and therefore can no longer be
- generated.
-
- 1. Period allowed in obsolete form of phrase.
- 2. ABNF moved out of document to [RFC2234].
- 3. Four or more digits allowed for year.
- 4. Header field ordering (and lack thereof) made explicit.
- 5. Encrypted header field removed.
- 6. Received syntax loosened to allow any token/value pair.
- 7. Specifically allow and give meaning to "-0000" time zone.
- 8. Folding white space is not allowed between every token.
- 9. Requirement for destinations removed.
- 10. Forwarding and resending redefined.
- 11. Extension header fields no longer specifically called out.
- 12. ASCII 0 (null) removed.*
- 13. Folding continuation lines cannot contain only white space.*
- 14. Free insertion of comments not allowed in date.*
- 15. Non-numeric time zones not allowed.*
- 16. Two digit years not allowed.*
- 17. Three digit years interpreted, but not allowed for generation.
- 18. Routes in addresses not allowed.*
- 19. CFWS within local-parts and domains not allowed.*
- 20. Empty members of address lists not allowed.*
-
-
-
-Resnick Standards Track [Page 49]
-
-RFC 2822 Internet Message Format April 2001
-
-
- 21. Folding white space between field name and colon not allowed.*
- 22. Comments between field name and colon not allowed.
- 23. Tightened syntax of in-reply-to and references.*
- 24. CFWS within msg-id not allowed.*
- 25. Tightened semantics of resent fields as informational only.
- 26. Resent-Reply-To not allowed.*
- 27. No multiple occurrences of fields (except resent and received).*
- 28. Free CR and LF not allowed.*
- 29. Routes in return path not allowed.*
- 30. Line length limits specified.
- 31. Bcc more clearly specified.
-
-Appendix C. Notices
-
- Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Resnick Standards Track [Page 50]
-
-RFC 2822 Internet Message Format April 2001
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Resnick Standards Track [Page 51]
-
diff --git a/doc/rfc/rfc2831.txt b/doc/rfc/rfc2831.txt
deleted file mode 100644
index c1a54c4..0000000
--- a/doc/rfc/rfc2831.txt
+++ /dev/null
@@ -1,1515 +0,0 @@
-
-
-
-
-
-
-Network Working Group P. Leach
-Request for Comments: 2831 Microsoft
-Category: Standards Track C. Newman
- Innosoft
- May 2000
-
-
- Using Digest Authentication as a SASL Mechanism
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-Abstract
-
- This specification defines how HTTP Digest Authentication [Digest]
- can be used as a SASL [RFC 2222] mechanism for any protocol that has
- a SASL profile. It is intended both as an improvement over CRAM-MD5
- [RFC 2195] and as a convenient way to support a single authentication
- mechanism for web, mail, LDAP, and other protocols.
-
-Table of Contents
-
- 1 INTRODUCTION.....................................................2
- 1.1 CONVENTIONS AND NOTATION......................................2
- 1.2 REQUIREMENTS..................................................3
- 2 AUTHENTICATION...................................................3
- 2.1 INITIAL AUTHENTICATION........................................3
- 2.1.1 Step One...................................................3
- 2.1.2 Step Two...................................................6
- 2.1.3 Step Three................................................12
- 2.2 SUBSEQUENT AUTHENTICATION....................................12
- 2.2.1 Step one..................................................13
- 2.2.2 Step Two..................................................13
- 2.3 INTEGRITY PROTECTION.........................................13
- 2.4 CONFIDENTIALITY PROTECTION...................................14
- 3 SECURITY CONSIDERATIONS.........................................15
- 3.1 AUTHENTICATION OF CLIENTS USING DIGEST AUTHENTICATION........15
- 3.2 COMPARISON OF DIGEST WITH PLAINTEXT PASSWORDS................16
- 3.3 REPLAY ATTACKS...............................................16
-
-
-
-Leach & Newman Standards Track [Page 1]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- 3.4 ONLINE DICTIONARY ATTACKS....................................16
- 3.5 OFFLINE DICTIONARY ATTACKS...................................16
- 3.6 MAN IN THE MIDDLE............................................17
- 3.7 CHOSEN PLAINTEXT ATTACKS.....................................17
- 3.8 SPOOFING BY COUNTERFEIT SERVERS..............................17
- 3.9 STORING PASSWORDS............................................17
- 3.10 MULTIPLE REALMS.............................................18
- 3.11 SUMMARY.....................................................18
- 4 EXAMPLE.........................................................18
- 5 REFERENCES......................................................20
- 6 AUTHORS' ADDRESSES..............................................21
- 7 ABNF............................................................21
- 7.1 AUGMENTED BNF................................................21
- 7.2 BASIC RULES..................................................23
- 8 SAMPLE CODE.....................................................25
- 9 FULL COPYRIGHT STATEMENT........................................27
-
-1 Introduction
-
- This specification describes the use of HTTP Digest Access
- Authentication as a SASL mechanism. The authentication type
- associated with the Digest SASL mechanism is "DIGEST-MD5".
-
- This specification is intended to be upward compatible with the
- "md5-sess" algorithm of HTTP/1.1 Digest Access Authentication
- specified in [Digest]. The only difference in the "md5-sess"
- algorithm is that some directives not needed in a SASL mechanism have
- had their values defaulted.
-
- There is one new feature for use as a SASL mechanism: integrity
- protection on application protocol messages after an authentication
- exchange.
-
- Also, compared to CRAM-MD5, DIGEST-MD5 prevents chosen plaintext
- attacks, and permits the use of third party authentication servers,
- mutual authentication, and optimized reauthentication if a client has
- recently authenticated to a server.
-
-1.1 Conventions and Notation
-
- This specification uses the same ABNF notation and lexical
- conventions as HTTP/1.1 specification; see appendix A.
-
- Let { a, b, ... } be the concatenation of the octet strings a, b, ...
-
- Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet string s.
-
-
-
-
-
-Leach & Newman Standards Track [Page 2]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- Let KD(k, s) be H({k, ":", s}), i.e., the 16 octet hash of the string
- k, a colon and the string s.
-
- Let HEX(n) be the representation of the 16 octet MD5 hash n as a
- string of 32 hex digits (with alphabetic characters always in lower
- case, since MD5 is case sensitive).
-
- Let HMAC(k, s) be the 16 octet HMAC-MD5 [RFC 2104] of the octet
- string s using the octet string k as a key.
-
- The value of a quoted string constant as an octet string does not
- include any terminating null character.
-
-1.2 Requirements
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [RFC 2119].
-
- An implementation is not compliant if it fails to satisfy one or more
- of the MUST level requirements for the protocols it implements. An
- implementation that satisfies all the MUST level and all the SHOULD
- level requirements for its protocols is said to be "unconditionally
- compliant"; one that satisfies all the MUST level requirements but
- not all the SHOULD level requirements for its protocols is said to be
- "conditionally compliant."
-
-2 Authentication
-
- The following sections describe how to use Digest as a SASL
- authentication mechanism.
-
-2.1 Initial Authentication
-
- If the client has not recently authenticated to the server, then it
- must perform "initial authentication", as defined in this section. If
- it has recently authenticated, then a more efficient form is
- available, defined in the next section.
-
-2.1.1 Step One
-
- The server starts by sending a challenge. The data encoded in the
- challenge contains a string formatted according to the rules for a
- "digest-challenge" defined as follows:
-
-
-
-
-
-
-
-Leach & Newman Standards Track [Page 3]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- digest-challenge =
- 1#( realm | nonce | qop-options | stale | maxbuf | charset
- algorithm | cipher-opts | auth-param )
-
- realm = "realm" "=" <"> realm-value <">
- realm-value = qdstr-val
- nonce = "nonce" "=" <"> nonce-value <">
- nonce-value = qdstr-val
- qop-options = "qop" "=" <"> qop-list <">
- qop-list = 1#qop-value
- qop-value = "auth" | "auth-int" | "auth-conf" |
- token
- stale = "stale" "=" "true"
- maxbuf = "maxbuf" "=" maxbuf-value
- maxbuf-value = 1*DIGIT
- charset = "charset" "=" "utf-8"
- algorithm = "algorithm" "=" "md5-sess"
- cipher-opts = "cipher" "=" <"> 1#cipher-value <">
- cipher-value = "3des" | "des" | "rc4-40" | "rc4" |
- "rc4-56" | token
- auth-param = token "=" ( token | quoted-string )
-
- The meanings of the values of the directives used above are as
- follows:
-
- realm
- Mechanistically, a string which can enable users to know which
- username and password to use, in case they might have different
- ones for different servers. Conceptually, it is the name of a
- collection of accounts that might include the user's account. This
- string should contain at least the name of the host performing the
- authentication and might additionally indicate the collection of
- users who might have access. An example might be
- "address@hidden". This directive is
- optional; if not present, the client SHOULD solicit it from the
- user or be able to compute a default; a plausible default might be
- the realm supplied by the user when they logged in to the client
- system. Multiple realm directives are allowed, in which case the
- user or client must choose one as the realm for which to supply to
- username and password.
-
- nonce
- A server-specified data string which MUST be different each time a
- digest-challenge is sent as part of initial authentication. It is
- recommended that this string be base64 or hexadecimal data. Note
- that since the string is passed as a quoted string, the
- double-quote character is not allowed unless escaped (see section
- 7.2). The contents of the nonce are implementation dependent. The
-
-
-
-Leach & Newman Standards Track [Page 4]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- security of the implementation depends on a good choice. It is
- RECOMMENDED that it contain at least 64 bits of entropy. The nonce
- is opaque to the client. This directive is required and MUST
- appear exactly once; if not present, or if multiple instances are
- present, the client should abort the authentication exchange.
-
- qop-options
- A quoted string of one or more tokens indicating the "quality of
- protection" values supported by the server. The value "auth"
- indicates authentication; the value "auth-int" indicates
- authentication with integrity protection; the value "auth-conf"
- indicates authentication with integrity protection and encryption.
- This directive is optional; if not present it defaults to "auth".
- The client MUST ignore unrecognized options; if the client
- recognizes no option, it should abort the authentication exchange.
-
- stale
- The "stale" directive is not used in initial authentication. See
- the next section for its use in subsequent authentications. This
- directive may appear at most once; if multiple instances are
- present, the client should abort the authentication exchange.
-
- maxbuf
- A number indicating the size of the largest buffer the server is
- able to receive when using "auth-int" or "auth-conf". If this
- directive is missing, the default value is 65536. This directive
- may appear at most once; if multiple instances are present, the
- client should abort the authentication exchange.
-
- charset
- This directive, if present, specifies that the server supports
- UTF-8 encoding for the username and password. If not present, the
- username and password must be encoded in ISO 8859-1 (of which
- US-ASCII is a subset). The directive is needed for backwards
- compatibility with HTTP Digest, which only supports ISO 8859-1.
- This directive may appear at most once; if multiple instances are
- present, the client should abort the authentication exchange.
-
- algorithm
- This directive is required for backwards compatibility with HTTP
- Digest., which supports other algorithms. . This directive is
- required and MUST appear exactly once; if not present, or if
- multiple instances are present, the client should abort the
- authentication exchange.
-
-
-
-
-
-
-
-Leach & Newman Standards Track [Page 5]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- cipher-opts
- A list of ciphers that the server supports. This directive must be
- present exactly once if "auth-conf" is offered in the
- "qop-options" directive, in which case the "3des" and "des" modes
- are mandatory-to-implement. The client MUST ignore unrecognized
- options; if the client recognizes no option, it should abort the
- authentication exchange.
-
- des
- the Data Encryption Standard (DES) cipher [FIPS] in cipher
- block chaining (CBC) mode with a 56 bit key.
-
- 3des
- the "triple DES" cipher in CBC mode with EDE with the same key
- for each E stage (aka "two keys mode") for a total key length
- of 112 bits.
-
- rc4, rc4-40, rc4-56
- the RC4 cipher with a 128 bit, 40 bit, and 56 bit key,
- respectively.
-
- auth-param This construct allows for future extensions; it may appear
- more than once. The client MUST ignore any unrecognized
- directives.
-
- For use as a SASL mechanism, note that the following changes are made
- to "digest-challenge" from HTTP: the following Digest options (called
- "directives" in HTTP terminology) are unused (i.e., MUST NOT be sent,
- and MUST be ignored if received):
-
- opaque
- domain
-
- The size of a digest-challenge MUST be less than 2048 bytes.
-
-2.1.2 Step Two
-
- The client makes note of the "digest-challenge" and then responds
- with a string formatted and computed according to the rules for a
- "digest-response" defined as follows:
-
-
-
-
-
-
-
-
-
-
-
-Leach & Newman Standards Track [Page 6]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- digest-response = 1#( username | realm | nonce | cnonce |
- nonce-count | qop | digest-uri | response |
- maxbuf | charset | cipher | authzid |
- auth-param )
-
- username = "username" "=" <"> username-value <">
- username-value = qdstr-val
- cnonce = "cnonce" "=" <"> cnonce-value <">
- cnonce-value = qdstr-val
- nonce-count = "nc" "=" nc-value
- nc-value = 8LHEX
- qop = "qop" "=" qop-value
- digest-uri = "digest-uri" "=" <"> digest-uri-value <">
- digest-uri-value = serv-type "/" host [ "/" serv-name ]
- serv-type = 1*ALPHA
- host = 1*( ALPHA | DIGIT | "-" | "." )
- serv-name = host
- response = "response" "=" response-value
- response-value = 32LHEX
- LHEX = "0" | "1" | "2" | "3" |
- "4" | "5" | "6" | "7" |
- "8" | "9" | "a" | "b" |
- "c" | "d" | "e" | "f"
- cipher = "cipher" "=" cipher-value
- authzid = "authzid" "=" <"> authzid-value <">
- authzid-value = qdstr-val
-
-
- username
- The user's name in the specified realm, encoded according to the
- value of the "charset" directive. This directive is required and
- MUST be present exactly once; otherwise, authentication fails.
-
- realm
- The realm containing the user's account. This directive is
- required if the server provided any realms in the
- "digest-challenge", in which case it may appear exactly once and
- its value SHOULD be one of those realms. If the directive is
- missing, "realm-value" will set to the empty string when computing
- A1 (see below for details).
-
- nonce
- The server-specified data string received in the preceding
- digest-challenge. This directive is required and MUST be present
- exactly once; otherwise, authentication fails.
-
-
-
-
-
-
-Leach & Newman Standards Track [Page 7]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- cnonce
- A client-specified data string which MUST be different each time a
- digest-response is sent as part of initial authentication. The
- cnonce-value is an opaque quoted string value provided by the
- client and used by both client and server to avoid chosen
- plaintext attacks, and to provide mutual authentication. The
- security of the implementation depends on a good choice. It is
- RECOMMENDED that it contain at least 64 bits of entropy. This
- directive is required and MUST be present exactly once; otherwise,
- authentication fails.
-
- nonce-count
- The nc-value is the hexadecimal count of the number of requests
- (including the current request) that the client has sent with the
- nonce value in this request. For example, in the first request
- sent in response to a given nonce value, the client sends
- "nc=00000001". The purpose of this directive is to allow the
- server to detect request replays by maintaining its own copy of
- this count - if the same nc-value is seen twice, then the request
- is a replay. See the description below of the construction of
- the response value. This directive may appear at most once; if
- multiple instances are present, the client should abort the
- authentication exchange.
-
- qop
- Indicates what "quality of protection" the client accepted. If
- present, it may appear exactly once and its value MUST be one of
- the alternatives in qop-options. If not present, it defaults to
- "auth". These values affect the computation of the response. Note
- that this is a single token, not a quoted list of alternatives.
-
- serv-type
- Indicates the type of service, such as "www" for web service,
- "ftp" for FTP service, "smtp" for mail delivery service, etc. The
- service name as defined in the SASL profile for the protocol see
- section 4 of [RFC 2222], registered in the IANA registry of
- "service" elements for the GSSAPI host-based service name form
- [RFC 2078].
-
- host
- The DNS host name or IP address for the service requested. The
- DNS host name must be the fully-qualified canonical name of the
- host. The DNS host name is the preferred form; see notes on server
- processing of the digest-uri.
-
-
-
-
-
-
-
-Leach & Newman Standards Track [Page 8]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- serv-name
- Indicates the name of the service if it is replicated. The service
- is considered to be replicated if the client's service-location
- process involves resolution using standard DNS lookup operations,
- and if these operations involve DNS records (such as SRV, or MX)
- which resolve one DNS name into a set of other DNS names. In this
- case, the initial name used by the client is the "serv-name", and
- the final name is the "host" component. For example, the incoming
- mail service for "example.com" may be replicated through the use
- of MX records stored in the DNS, one of which points at an SMTP
- server called "mail3.example.com"; it's "serv-name" would be
- "example.com", it's "host" would be "mail3.example.com". If the
- service is not replicated, or the serv-name is identical to the
- host, then the serv-name component MUST be omitted.
-
- digest-uri
- Indicates the principal name of the service with which the client
- wishes to connect, formed from the serv-type, host, and serv-name.
- For example, the FTP service on "ftp.example.com" would have a
- "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from
- the example above would have a "digest-uri" value of
- "smtp/mail3.example.com/example.com".
-
- Servers SHOULD check that the supplied value is correct. This will
- detect accidental connection to the incorrect server. It is also so
- that clients will be trained to provide values that will work with
- implementations that use a shared back-end authentication service
- that can provide server authentication.
-
- The serv-type component should match the service being offered. The
- host component should match one of the host names of the host on
- which the service is running, or it's IP address. Servers SHOULD NOT
- normally support the IP address form, because server authentication
- by IP address is not very useful; they should only do so if the DNS
- is unavailable or unreliable. The serv-name component should match
- one of the service's configured service names.
-
- This directive may appear at most once; if multiple instances are
- present, the client should abort the authentication exchange.
-
- Note: In the HTTP use of Digest authentication, the digest-uri is the
- URI (usually a URL) of the resource requested -- hence the name of
- the directive.
-
- response
- A string of 32 hex digits computed as defined below, which proves
- that the user knows a password. This directive is required and
- MUST be present exactly once; otherwise, authentication fails.
-
-
-
-Leach & Newman Standards Track [Page 9]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- maxbuf
- A number indicating the size of the largest buffer the client is
- able to receive. If this directive is missing, the default value
- is 65536. This directive may appear at most once; if multiple
- instances are present, the server should abort the authentication
- exchange.
-
- charset
- This directive, if present, specifies that the client has used
- UTF-8 encoding for the username and password. If not present, the
- username and password must be encoded in ISO 8859-1 (of which
- US-ASCII is a subset). The client should send this directive only
- if the server has indicated it supports UTF-8. The directive is
- needed for backwards compatibility with HTTP Digest, which only
- supports ISO 8859-1.
-
- LHEX
- 32 hex digits, where the alphabetic characters MUST be lower case,
- because MD5 is not case insensitive.
-
- cipher
- The cipher chosen by the client. This directive MUST appear
- exactly once if "auth-conf" is negotiated; if required and not
- present, authentication fails.
-
- authzid
- The "authorization ID" as per RFC 2222, encoded in UTF-8. This
- directive is optional. If present, and the authenticating user has
- sufficient privilege, and the server supports it, then after
- authentication the server will use this identity for making all
- accesses and access checks. If the client specifies it, and the
- server does not support it, then the response-value will be
- incorrect, and authentication will fail.
-
- The size of a digest-response MUST be less than 4096 bytes.
-
-2.1.2.1 Response-value
-
- The definition of "response-value" above indicates the encoding for
- its value -- 32 lower case hex characters. The following definitions
- show how the value is computed.
-
- Although qop-value and components of digest-uri-value may be
- case-insensitive, the case which the client supplies in step two is
- preserved for the purpose of computing and verifying the
- response-value.
-
- response-value =
-
-
-
-Leach & Newman Standards Track [Page 10]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- HEX( KD ( HEX(H(A1)),
- { nonce-value, ":" nc-value, ":",
- cnonce-value, ":", qop-value, ":", HEX(H(A2)) }))
-
- If authzid is specified, then A1 is
-
-
- A1 = { H( { username-value, ":", realm-value, ":", passwd } ),
- ":", nonce-value, ":", cnonce-value, ":", authzid-value }
-
- If authzid is not specified, then A1 is
-
-
- A1 = { H( { username-value, ":", realm-value, ":", passwd } ),
- ":", nonce-value, ":", cnonce-value }
-
- where
-
- passwd = *OCTET
-
- The "username-value", "realm-value" and "passwd" are encoded
- according to the value of the "charset" directive. If "charset=UTF-8"
- is present, and all the characters of either "username-value" or
- "passwd" are in the ISO 8859-1 character set, then it must be
- converted to ISO 8859-1 before being hashed. This is so that
- authentication databases that store the hashed username, realm and
- password (which is common) can be shared compatibly with HTTP, which
- specifies ISO 8859-1. A sample implementation of this conversion is
- in section 8.
-
- If the "qop" directive's value is "auth", then A2 is:
-
- A2 = { "AUTHENTICATE:", digest-uri-value }
-
- If the "qop" value is "auth-int" or "auth-conf" then A2 is:
-
- A2 = { "AUTHENTICATE:", digest-uri-value,
- ":00000000000000000000000000000000" }
-
- Note that "AUTHENTICATE:" must be in upper case, and the second
- string constant is a string with a colon followed by 32 zeros.
-
- These apparently strange values of A2 are for compatibility with
- HTTP; they were arrived at by setting "Method" to "AUTHENTICATE" and
- the hash of the entity body to zero in the HTTP digest calculation of
- A2.
-
- Also, in the HTTP usage of Digest, several directives in the
-
-
-
-Leach & Newman Standards Track [Page 11]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- "digest-challenge" sent by the server have to be returned by the
- client in the "digest-response". These are:
-
- opaque
- algorithm
-
- These directives are not needed when Digest is used as a SASL
- mechanism (i.e., MUST NOT be sent, and MUST be ignored if received).
-
-2.1.3 Step Three
-
- The server receives and validates the "digest-response". The server
- checks that the nonce-count is "00000001". If it supports subsequent
- authentication (see section 2.2), it saves the value of the nonce and
- the nonce-count. It sends a message formatted as follows:
-
- response-auth = "rspauth" "=" response-value
-
- where response-value is calculated as above, using the values sent in
- step two, except that if qop is "auth", then A2 is
-
- A2 = { ":", digest-uri-value }
-
- And if qop is "auth-int" or "auth-conf" then A2 is
-
- A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" }
-
- Compared to its use in HTTP, the following Digest directives in the
- "digest-response" are unused:
-
- nextnonce
- qop
- cnonce
- nonce-count
-
-2.2 Subsequent Authentication
-
- If the client has previously authenticated to the server, and
- remembers the values of username, realm, nonce, nonce-count, cnonce,
- and qop that it used in that authentication, and the SASL profile for
- a protocol permits an initial client response, then it MAY perform
- "subsequent authentication", as defined in this section.
-
-
-
-
-
-
-
-
-
-Leach & Newman Standards Track [Page 12]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
-2.2.1 Step one
-
- The client uses the values from the previous authentication and sends
- an initial response with a string formatted and computed according to
- the rules for a "digest-response", as defined above, but with a
- nonce-count one greater than used in the last "digest-response".
-
-2.2.2 Step Two
-
- The server receives the "digest-response". If the server does not
- support subsequent authentication, then it sends a
- "digest-challenge", and authentication proceeds as in initial
- authentication. If the server has no saved nonce and nonce-count from
- a previous authentication, then it sends a "digest-challenge", and
- authentication proceeds as in initial authentication. Otherwise, the
- server validates the "digest-response", checks that the nonce-count
- is one greater than that used in the previous authentication using
- that nonce, and saves the new value of nonce-count.
-
- If the response is invalid, then the server sends a
- "digest-challenge", and authentication proceeds as in initial
- authentication (and should be configurable to log an authentication
- failure in some sort of security audit log, since the failure may be
- a symptom of an attack). The nonce-count MUST NOT be incremented in
- this case: to do so would allow a denial of service attack by sending
- an out-of-order nonce-count.
-
- If the response is valid, the server MAY choose to deem that
- authentication has succeeded. However, if it has been too long since
- the previous authentication, or for any other reason, the server MAY
- send a new "digest-challenge" with a new value for nonce. The
- challenge MAY contain a "stale" directive with value "true", which
- says that the client may respond to the challenge using the password
- it used in the previous response; otherwise, the client must solicit
- the password anew from the user. This permits the server to make sure
- that the user has presented their password recently. (The directive
- name refers to the previous nonce being stale, not to the last use of
- the password.) Except for the handling of "stale", after sending the
- "digest-challenge" authentication proceeds as in the case of initial
- authentication.
-
-2.3 Integrity Protection
-
- If the server offered "qop=auth-int" and the client responded
- "qop=auth-int", then subsequent messages, up to but not including the
- next subsequent authentication, between the client and the server
-
-
-
-
-
-Leach & Newman Standards Track [Page 13]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- MUST be integrity protected. Using as a base session key the value of
- H(A1) as defined above the client and server calculate a pair of
- message integrity keys as follows.
-
- The key for integrity protecting messages from client to server is:
-
- Kic = MD5({H(A1),
- "Digest session key to client-to-server signing key magic constant"})
-
- The key for integrity protecting messages from server to client is:
-
- Kis = MD5({H(A1),
- "Digest session key to server-to-client signing key magic constant"})
-
- where MD5 is as specified in [RFC 1321]. If message integrity is
- negotiated, a MAC block for each message is appended to the message.
- The MAC block is 16 bytes: the first 10 bytes of the HMAC-MD5 [RFC
- 2104] of the message, a 2-byte message type number in network byte
- order with value 1, and the 4-byte sequence number in network byte
- order. The message type is to allow for future extensions such as
- rekeying.
-
- MAC(Ki, SeqNum, msg) = (HMAC(Ki, {SeqNum, msg})[0..9], 0x0001,
- SeqNum)
-
- where Ki is Kic for messages sent by the client and Kis for those
- sent by the server. The sequence number is initialized to zero, and
- incremented by one for each message sent.
-
- Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the
- received value; the message is discarded if they differ.
-
-2.4 Confidentiality Protection
-
- If the server sent a "cipher-opts" directive and the client responded
- with a "cipher" directive, then subsequent messages between the
- client and the server MUST be confidentiality protected. Using as a
- base session key the value of H(A1) as defined above the client and
- server calculate a pair of message integrity keys as follows.
-
- The key for confidentiality protecting messages from client to server
- is:
-
- Kcc = MD5({H(A1)[0..n],
- "Digest H(A1) to client-to-server sealing key magic constant"})
-
- The key for confidentiality protecting messages from server to client
- is:
-
-
-
-Leach & Newman Standards Track [Page 14]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- Kcs = MD5({H(A1)[0..n],
- "Digest H(A1) to server-to-client sealing key magic constant"})
-
- where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5;
- for "rc4-56" n is 7; for the rest n is 16. The key for the "rc-*"
- ciphers is all 16 bytes of Kcc or Kcs; the key for "des" is the first
- 7 bytes; the key for "3des" is the first 14 bytes. The IV for "des"
- and "3des" is the last 8 bytes of Kcc or Kcs.
-
- If message confidentiality is negotiated, each message is encrypted
- with the chosen cipher and a MAC block is appended to the message.
-
- The MAC block is a variable length padding prefix followed by 16
- bytes formatted as follows: the first 10 bytes of the HMAC-MD5 [RFC
- 2104] of the message, a 2-byte message type number in network byte
- order with value 1, and the 4-byte sequence number in network byte
- order. If the blocksize of the chosen cipher is not 1 byte, the
- padding prefix is one or more octets each containing the number of
- padding bytes, such that total length of the encrypted part of the
- message is a multiple of the blocksize. The padding and first 10
- bytes of the MAC block are encrypted along with the message.
-
- SEAL(Ki, Kc, SeqNum, msg) =
- {CIPHER(Kc, {msg, pad, HMAC(Ki, {SeqNum, msg})[0..9])}), 0x0001,
- SeqNum}
-
- where CIPHER is the chosen cipher, Ki and Kc are Kic and Kcc for
- messages sent by the client and Kis and Kcs for those sent by the
- server. The sequence number is initialized to zero, and incremented
- by one for each message sent.
-
- Upon receipt, the message is decrypted, HMAC(Ki, {SeqNum, msg}) is
- computed and compared with the received value; the message is
- discarded if they differ.
-
-3 Security Considerations
-
-3.1 Authentication of Clients using Digest Authentication
-
- Digest Authentication does not provide a strong authentication
- mechanism, when compared to public key based mechanisms, for example.
- However, since it prevents chosen plaintext attacks, it is stronger
- than (e.g.) CRAM-MD5, which has been proposed for use with LDAP [10],
- POP and IMAP (see RFC 2195 [9]). It is intended to replace the much
- weaker and even more dangerous use of plaintext passwords; however,
- since it is still a password based mechanism it avoids some of the
- potential deployabilty issues with public-key, OTP or similar
- mechanisms.
-
-
-
-Leach & Newman Standards Track [Page 15]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- Digest Authentication offers no confidentiality protection beyond
- protecting the actual password. All of the rest of the challenge and
- response are available to an eavesdropper, including the user's name
- and authentication realm.
-
-3.2 Comparison of Digest with Plaintext Passwords
-
- The greatest threat to the type of transactions for which these
- protocols are used is network snooping. This kind of transaction
- might involve, for example, online access to a mail service whose use
- is restricted to paying subscribers. With plaintext password
- authentication an eavesdropper can obtain the password of the user.
- This not only permits him to access anything in the database, but,
- often worse, will permit access to anything else the user protects
- with the same password.
-
-3.3 Replay Attacks
-
- Replay attacks are defeated if the client or the server chooses a
- fresh nonce for each authentication, as this specification requires.
-
-3.4 Online dictionary attacks
-
- If the attacker can eavesdrop, then it can test any overheard
- nonce/response pairs against a (potentially very large) list of
- common words. Such a list is usually much smaller than the total
- number of possible passwords. The cost of computing the response for
- each password on the list is paid once for each challenge.
-
- The server can mitigate this attack by not allowing users to select
- passwords that are in a dictionary.
-
-3.5 Offline dictionary attacks
-
- If the attacker can choose the challenge, then it can precompute the
- possible responses to that challenge for a list of common words. Such
- a list is usually much smaller than the total number of possible
- passwords. The cost of computing the response for each password on
- the list is paid just once.
-
- Offline dictionary attacks are defeated if the client chooses a fresh
- nonce for each authentication, as this specification requires.
-
-
-
-
-
-
-
-
-
-Leach & Newman Standards Track [Page 16]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
-3.6 Man in the Middle
-
- Digest authentication is vulnerable to "man in the middle" (MITM)
- attacks. Clearly, a MITM would present all the problems of
- eavesdropping. But it also offers some additional opportunities to
- the attacker.
-
- A possible man-in-the-middle attack would be to substitute a weaker
- qop scheme for the one(s) sent by the server; the server will not be
- able to detect this attack. For this reason, the client should always
- use the strongest scheme that it understands from the choices
- offered, and should never choose a scheme that does not meet its
- minimum requirements.
-
-3.7 Chosen plaintext attacks
-
- A chosen plaintext attack is where a MITM or a malicious server can
- arbitrarily choose the challenge that the client will use to compute
- the response. The ability to choose the challenge is known to make
- cryptanalysis much easier [8].
-
- However, Digest does not permit the attack to choose the challenge as
- long as the client chooses a fresh nonce for each authentication, as
- this specification requires.
-
-3.8 Spoofing by Counterfeit Servers
-
- If a user can be led to believe that she is connecting to a host
- containing information protected by a password she knows, when in
- fact she is connecting to a hostile server, then the hostile server
- can obtain challenge/response pairs where it was able to partly
- choose the challenge. There is no known way that this can be
- exploited.
-
-3.9 Storing passwords
-
- Digest authentication requires that the authenticating agent (usually
- the server) store some data derived from the user's name and password
- in a "password file" associated with a given realm. Normally this
- might contain pairs consisting of username and H({ username-value,
- ":", realm-value, ":", passwd }), which is adequate to compute H(A1)
- as described above without directly exposing the user's password.
-
- The security implications of this are that if this password file is
- compromised, then an attacker gains immediate access to documents on
- the server using this realm. Unlike, say a standard UNIX password
- file, this information need not be decrypted in order to access
- documents in the server realm associated with this file. On the other
-
-
-
-Leach & Newman Standards Track [Page 17]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- hand, decryption, or more likely a brute force attack, would be
- necessary to obtain the user's password. This is the reason that the
- realm is part of the digested data stored in the password file. It
- means that if one Digest authentication password file is compromised,
- it does not automatically compromise others with the same username
- and password (though it does expose them to brute force attack).
-
- There are two important security consequences of this. First the
- password file must be protected as if it contained plaintext
- passwords, because for the purpose of accessing documents in its
- realm, it effectively does.
-
- A second consequence of this is that the realm string should be
- unique among all realms that any single user is likely to use. In
- particular a realm string should include the name of the host doing
- the authentication.
-
-3.10 Multiple realms
-
- Use of multiple realms may mean both that compromise of a the
- security database for a single realm does not compromise all
- security, and that there are more things to protect in order to keep
- the whole system secure.
-
-3.11 Summary
-
- By modern cryptographic standards Digest Authentication is weak,
- compared to (say) public key based mechanisms. But for a large range
- of purposes it is valuable as a replacement for plaintext passwords.
- Its strength may vary depending on the implementation.
-
-4 Example
-
- This example shows the use of the Digest SASL mechanism with the
- IMAP4 AUTHENTICATE command [RFC 2060].
-
- In this example, "C:" and "S:" represent a line sent by the client or
- server respectively including a CRLF at the end. Linebreaks and
- indentation within a "C:" or "S:" are editorial and not part of the
- protocol. The password in this example was "secret". Note that the
- base64 encoding of the challenges and responses is part of the IMAP4
- AUTHENTICATE command, not part of the Digest specification itself.
-
- S: * OK elwood.innosoft.com PMDF IMAP4rev1 V6.0-9
- C: c CAPABILITY
- S: * CAPABILITY IMAP4 IMAP4rev1 ACL LITERAL+ NAMESPACE QUOTA
- UIDPLUS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN
- S: c OK Completed
-
-
-
-Leach & Newman Standards Track [Page 18]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- C: a AUTHENTICATE DIGEST-MD5
- S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
- RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
- cnNldD11dGYtOA==
- C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
- QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
- MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im
- ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw
- ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg=
- S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
- C:
- S: a OK User logged in
- ---
-
- The base64-decoded version of the SASL exchange is:
-
- S: realm="elwood.innosoft.com",nonce="OA6MG9tEQGm2hh",qop="auth",
- algorithm=md5-sess,charset=utf-8
- C: charset=utf-8,username="chris",realm="elwood.innosoft.com",
- nonce="OA6MG9tEQGm2hh",nc=00000001,cnonce="OA6MHXh6VqTrRk",
- digest-uri="imap/elwood.innosoft.com",
- response=d388dad90d4bbd760a152321f2143af7,qop=auth
- S: rspauth=ea40f60335c427b5527b84dbabcdfffd
-
- The password in this example was "secret".
-
- This example shows the use of the Digest SASL mechanism with the
- ACAP, using the same notational conventions and password as in the
- previous example. Note that ACAP does not base64 encode and uses
- fewer round trips that IMAP4.
-
- S: * ACAP (IMPLEMENTATION "Test ACAP server") (SASL "CRAM-MD5"
- "DIGEST-MD5" "PLAIN")
- C: a AUTHENTICATE "DIGEST-MD5"
- S: + {94}
- S: realm="elwood.innosoft.com",nonce="OA9BSXrbuRhWay",qop="auth",
- algorithm=md5-sess,charset=utf-8
- C: {206}
- C: charset=utf-8,username="chris",realm="elwood.innosoft.com",
- nonce="OA9BSXrbuRhWay",nc=00000001,cnonce="OA9BSuZWMSpW8m",
- digest-uri="acap/elwood.innosoft.com",
- response=6084c6db3fede7352c551284490fd0fc,qop=auth
- S: a OK (SASL {40}
- S: rspauth=2f0b3d7c3c2e486600ef710726aa2eae) "AUTHENTICATE
- Completed"
- ---
-
-
-
-
-
-Leach & Newman Standards Track [Page 19]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- The server uses the values of all the directives, plus knowledge of
- the users password (or the hash of the user's name, server's realm
- and the user's password) to verify the computations above. If they
- check, then the user has authenticated.
-
-5 References
-
- [Digest] Franks, J., et al., "HTTP Authentication: Basic and Digest
- Access Authentication", RFC 2617, June 1999.
-
- [ISO-8859] ISO-8859. International Standard--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.
-
- [RFC 822] Crocker, D., "Standard for The Format of ARPA Internet
- Text Messages," STD 11, RFC 822, August 1982.
-
- [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
- April 1992.
-
- [RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
- Part Three: Message Header Extensions for Non-ASCII Text",
- RFC 2047, November 1996.
-
- [RFC 2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
- location of services (DNS SRV)", RFC 2052, October 1996.
-
- [RFC 2060] Crispin, M., "Internet Message Access Protocol - Version
- 4rev1", RFC 2060, December 1996.
-
- [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
- Hashing for Message Authentication", RFC 2104, February
- 1997.
-
- [RFC 2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
- AUTHorize Extension for Simple Challenge/Response", RFC
- 2195, September 1997.
-
-
-
-
-
-
-Leach & Newman Standards Track [Page 20]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC 2222] Myers, J., "Simple Authentication and Security Layer
- (SASL)", RFC 2222, October 1997.
-
- [USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard
- Code for Information Interchange. Standard ANSI X3.4-1986,
- ANSI, 1986.
-
-6 Authors' Addresses
-
- Paul Leach
- Microsoft
- 1 Microsoft Way
- Redmond, WA 98052
-
- EMail: address@hidden
-
-
- Chris Newman
- Innosoft International, Inc.
- 1050 Lakes Drive
- West Covina, CA 91790 USA
-
- EMail: address@hidden
-
-7 ABNF
-
- What follows is the definition of the notation as is used in the
- HTTP/1.1 specification (RFC 2616) and the HTTP authentication
- specification (RFC 2617); it is reproduced here for ease of
- reference. Since it is intended that a single Digest implementation
- can support both HTTP and SASL-based protocols, the same notation is
- used in both to facilitate comparison and prevention of unwanted
- differences. Since it is cut-and-paste from the HTTP specifications,
- not all productions may be used in this specification. It is also not
- quite legal ABNF; again, the errors were copied from the HTTP
- specifications.
-
-7.1 Augmented BNF
-
- All of the mechanisms specified in this document are described in
- both prose and an augmented Backus-Naur Form (BNF) similar to that
- used by RFC 822 [RFC 822]. Implementers will need to be familiar with
- the notation in order to understand this specification.
-
-
-
-
-
-Leach & Newman Standards Track [Page 21]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- The augmented BNF includes the following constructs:
-
- name = definition
- The name of a rule is simply the name itself (without any
- enclosing "<" and ">") and is separated from its definition by the
- equal "=" character. White space is only significant in that
- indentation of continuation lines is used to indicate a rule
- definition that spans more than one line. Certain basic rules are
- in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle
- brackets are used within definitions whenever their presence will
- facilitate discerning the use of rule names.
-
- "literal"
- Quotation marks surround literal text. Unless stated otherwise,
- the text is case-insensitive.
-
- rule1 | rule2
- Elements separated by a bar ("|") are alternatives, e.g., "yes |
- no" will accept yes or no.
-
- (rule1 rule2)
- Elements enclosed in parentheses are treated as a single element.
- Thus, "(elem (foo | bar) elem)" allows the token sequences
- "elem foo elem" and "elem bar elem".
-
- *rule
- The character "*" preceding an element indicates repetition. The
- full form is "<n>*<m>element" indicating at least <n> and at most
- <m> occurrences of element. Default values are 0 and infinity so
- that "*(element)" allows any number, including zero; "1*element"
- requires at least one; and "1*2element" allows one or two.
-
- [rule]
- Square brackets enclose optional elements; "[foo bar]" is
- equivalent to "*1(foo bar)".
-
- N rule
- Specific repetition: "<n>(element)" is equivalent to
- "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
- Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
- alphabetic characters.
-
- #rule
- A construct "#" is defined, similar to "*", for defining lists of
- elements. The full form is "<n>#<m>element" indicating at least
- <n> and at most <m> elements, each separated by one or more commas
- (",") and OPTIONAL linear white space (LWS). This makes the usual
- form of lists very easy; a rule such as
-
-
-
-Leach & Newman Standards Track [Page 22]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- ( *LWS element *( *LWS "," *LWS element ))
- can be shown as
- 1#element
- Wherever this construct is used, null elements are allowed, but do
- not contribute to the count of elements present. That is,
- "(element), , (element) " is permitted, but counts as only two
- elements. Therefore, where at least one element is required, at
- least one non-null element MUST be present. Default values are 0
- and infinity so that "#element" allows any number, including zero;
- "1#element" requires at least one; and "1#2element" allows one or
- two.
-
- ; comment
- A semi-colon, set off some distance to the right of rule text,
- starts a comment that continues to the end of line. This is a
- simple way of including useful notes in parallel with the
- specifications.
-
- implied *LWS
- The grammar described by this specification is word-based. Except
- where noted otherwise, linear white space (LWS) can be included
- between any two adjacent words (token or quoted-string), and
- between adjacent words and separators, without changing the
- interpretation of a field. At least one delimiter (LWS and/or
- separators) MUST exist between any two tokens (for the definition
- of "token" below), since they would otherwise be interpreted as a
- single token.
-
-7.2 Basic Rules
-
- The following rules are used throughout this specification to
- describe basic parsing constructs. The US-ASCII coded character set
- is defined by ANSI X3.4-1986 [USASCII].
-
- OCTET = <any 8-bit sequence of data>
- CHAR = <any US-ASCII character (octets 0 - 127)>
- UPALPHA = <any US-ASCII uppercase letter "A".."Z">
- LOALPHA = <any US-ASCII lowercase letter "a".."z">
- ALPHA = UPALPHA | LOALPHA
- DIGIT = <any US-ASCII digit "0".."9">
- CTL = <any US-ASCII control character
- (octets 0 - 31) and DEL (127)>
- CR = <US-ASCII CR, carriage return (13)>
- LF = <US-ASCII LF, linefeed (10)>
- SP = <US-ASCII SP, space (32)>
- HT = <US-ASCII HT, horizontal-tab (9)>
- <"> = <US-ASCII double-quote mark (34)>
- CRLF = CR LF
-
-
-
-Leach & Newman Standards Track [Page 23]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
-
- All linear white space, including folding, has the same semantics as
- SP. A recipient MAY replace any linear white space with a single SP
- before interpreting the field value or forwarding the message
- downstream.
-
- LWS = [CRLF] 1*( SP | HT )
-
- The TEXT rule is only used for descriptive field contents and values
- that are not intended to be interpreted by the message parser. Words
- of *TEXT MAY contain characters from character sets other than
- ISO-8859-1 [ISO 8859] only when encoded according to the rules of RFC
- 2047 [RFC 2047].
-
- TEXT = <any OCTET except CTLs,
- but including LWS>
-
- A CRLF is allowed in the definition of TEXT only as part of a header
- field continuation. It is expected that the folding LWS will be
- replaced with a single SP before interpretation of the TEXT value.
-
- Hexadecimal numeric characters are used in several protocol elements.
-
- HEX = "A" | "B" | "C" | "D" | "E" | "F"
- | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
-
- Many HTTP/1.1 header field values consist of words separated by LWS
- or special characters. These special characters MUST be in a quoted
- string to be used within a parameter value.
-
- token = 1*<any CHAR except CTLs or separators>
- separators = "(" | ")" | "<" | ">" | "@"
- | "," | ";" | ":" | "\" | <">
- | "/" | "[" | "]" | "?" | "="
- | "{" | "}" | SP | HT
-
- A string of text is parsed as a single word if it is quoted using
- double-quote marks.
-
- quoted-string = ( <"> qdstr-val <"> )
- qdstr-val = *( qdtext | quoted-pair )
- qdtext = <any TEXT except <">>
-
- Note that LWS is NOT implicit between the double-quote marks (<">)
- surrounding a qdstr-val and the qdstr-val; any LWS will be considered
- part of the qdstr-val. This is also the case for quotation marks
- surrounding any other construct.
-
-
-
-
-Leach & Newman Standards Track [Page 24]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- The backslash character ("\") MAY be used as a single-character
- quoting mechanism only within qdstr-val and comment constructs.
-
- quoted-pair = "\" CHAR
-
- The value of this construct is CHAR. Note that an effect of this rule
- is that backslash must be quoted.
-
-8 Sample Code
-
- The sample implementation in [Digest] also applies to DIGEST-MD5.
-
- The following code implements the conversion from UTF-8 to 8859-1 if
- necessary.
-
- /* if the string is entirely in the 8859-1 subset of UTF-8, then
- * translate to 8859-1 prior to MD5
- */
- void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base,
- int len)
- {
- const unsigned char *scan, *end;
- unsigned char cbuf;
-
- end = base + len;
- for (scan = base; scan < end; ++scan) {
- if (*scan > 0xC3) break; /* abort if outside 8859-1 */
- if (*scan >= 0xC0 && *scan <= 0xC3) {
- if (++scan == end || *scan < 0x80 || *scan > 0xBF)
- break;
- }
- }
- /* if we found a character outside 8859-1, don't alter string
- */
- if (scan < end) {
- MD5Update(ctx, base, len);
- return;
- }
-
- /* convert to 8859-1 prior to applying hash
- */
- do {
- for (scan = base; scan < end && *scan < 0xC0; ++scan)
- ;
- if (scan != base) MD5Update(ctx, base, scan - base);
- if (scan + 1 >= end) break;
- cbuf = ((scan[0] & 0x3) << 6) | (scan[1] & 0x3f);
- MD5Update(ctx, &cbuf, 1);
-
-
-
-Leach & Newman Standards Track [Page 25]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
- base = scan + 2;
- } while (base < end);
- }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Leach & Newman Standards Track [Page 26]
-
-RFC 2831 Digest SASL Mechanism May 2000
-
-
-9 Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Leach & Newman Standards Track [Page 27]
-
diff --git a/doc/rfc/rfc3028.txt b/doc/rfc/rfc3028.txt
deleted file mode 100644
index d909a54..0000000
--- a/doc/rfc/rfc3028.txt
+++ /dev/null
@@ -1,2019 +0,0 @@
-
-
-
-
-
-
-Network Working Group T. Showalter
-Request for Comments: 3028 Mirapoint, Inc.
-Category: Standards Track January 2001
-
-
- Sieve: A Mail Filtering Language
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
-Abstract
-
- This document describes a language for filtering e-mail messages at
- time of final delivery. It is designed to be implementable on either
- a mail client or mail server. It is meant to be extensible, simple,
- and independent of access protocol, mail architecture, and operating
- system. It is suitable for running on a mail server where users may
- not be allowed to execute arbitrary programs, such as on black box
- Internet Message Access Protocol (IMAP) servers, as it has no
- variables, loops, or ability to shell out to external programs.
-
-Table of Contents
-
- 1. Introduction ........................................... 3
- 1.1. Conventions Used in This Document ..................... 4
- 1.2. Example mail messages ................................. 4
- 2. Design ................................................. 5
- 2.1. Form of the Language .................................. 5
- 2.2. Whitespace ............................................ 5
- 2.3. Comments .............................................. 6
- 2.4. Literal Data .......................................... 6
- 2.4.1. Numbers ............................................... 6
- 2.4.2. Strings ............................................... 7
- 2.4.2.1. String Lists .......................................... 7
- 2.4.2.2. Headers ............................................... 8
- 2.4.2.3. Addresses ............................................. 8
- 2.4.2.4. MIME Parts ............................................ 9
- 2.5. Tests ................................................. 9
- 2.5.1. Test Lists ............................................ 9
-
-
-
-Showalter Standards Track [Page 1]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- 2.6. Arguments ............................................. 9
- 2.6.1. Positional Arguments .................................. 9
- 2.6.2. Tagged Arguments ...................................... 10
- 2.6.3. Optional Arguments .................................... 10
- 2.6.4. Types of Arguments .................................... 10
- 2.7. String Comparison ..................................... 11
- 2.7.1. Match Type ............................................ 11
- 2.7.2. Comparisons Across Character Sets ..................... 12
- 2.7.3. Comparators ........................................... 12
- 2.7.4. Comparisons Against Addresses ......................... 13
- 2.8. Blocks ................................................ 14
- 2.9. Commands .............................................. 14
- 2.10. Evaluation ............................................ 15
- 2.10.1. Action Interaction .................................... 15
- 2.10.2. Implicit Keep ......................................... 15
- 2.10.3. Message Uniqueness in a Mailbox ....................... 15
- 2.10.4. Limits on Numbers of Actions .......................... 16
- 2.10.5. Extensions and Optional Features ...................... 16
- 2.10.6. Errors ................................................ 17
- 2.10.7. Limits on Execution ................................... 17
- 3. Control Commands ....................................... 17
- 3.1. Control Structure If .................................. 18
- 3.2. Control Structure Require ............................. 19
- 3.3. Control Structure Stop ................................ 19
- 4. Action Commands ........................................ 19
- 4.1. Action reject ......................................... 20
- 4.2. Action fileinto ....................................... 20
- 4.3. Action redirect ....................................... 21
- 4.4. Action keep ........................................... 21
- 4.5. Action discard ........................................ 22
- 5. Test Commands .......................................... 22
- 5.1. Test address .......................................... 23
- 5.2. Test allof ............................................ 23
- 5.3. Test anyof ............................................ 24
- 5.4. Test envelope ......................................... 24
- 5.5. Test exists ........................................... 25
- 5.6. Test false ............................................ 25
- 5.7. Test header ........................................... 25
- 5.8. Test not .............................................. 26
- 5.9. Test size ............................................. 26
- 5.10. Test true ............................................. 26
- 6. Extensibility .......................................... 26
- 6.1. Capability String ..................................... 27
- 6.2. IANA Considerations ................................... 28
- 6.2.1. Template for Capability Registrations ................. 28
- 6.2.2. Initial Capability Registrations ...................... 28
- 6.3. Capability Transport .................................. 29
- 7. Transmission ........................................... 29
-
-
-
-Showalter Standards Track [Page 2]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- 8. Parsing ................................................ 30
- 8.1. Lexical Tokens ........................................ 30
- 8.2. Grammar ............................................... 31
- 9. Extended Example ....................................... 32
- 10. Security Considerations ................................ 34
- 11. Acknowledgments ........................................ 34
- 12. Author's Address ....................................... 34
- 13. References ............................................. 34
- 14. Full Copyright Statement ............................... 36
-
-1. Introduction
-
- This memo documents a language that can be used to create filters for
- electronic mail. It is not tied to any particular operating system or
- mail architecture. It requires the use of [IMAIL]-compliant
- messages, but should otherwise generalize to many systems.
-
- The language is powerful enough to be useful but limited in order to
- allow for a safe server-side filtering system. The intention is to
- make it impossible for users to do anything more complex (and
- dangerous) than write simple mail filters, along with facilitating
- the use of GUIs for filter creation and manipulation. The language is
- not Turing-complete: it provides no way to write a loop or a function
- and variables are not provided.
-
- Scripts written in Sieve are executed during final delivery, when the
- message is moved to the user-accessible mailbox. In systems where
- the MTA does final delivery, such as traditional Unix mail, it is
- reasonable to sort when the MTA deposits mail into the user's
- mailbox.
-
- There are a number of reasons to use a filtering system. Mail
- traffic for most users has been increasing due to increased usage of
- e-mail, the emergence of unsolicited email as a form of advertising,
- and increased usage of mailing lists.
-
- Experience at Carnegie Mellon has shown that if a filtering system is
- made available to users, many will make use of it in order to file
- messages from specific users or mailing lists. However, many others
- did not make use of the Andrew system's FLAMES filtering language
- [FLAMES] due to difficulty in setting it up.
-
- Because of the expectation that users will make use of filtering if
- it is offered and easy to use, this language has been made simple
- enough to allow many users to make use of it, but rich enough that it
- can be used productively. However, it is expected that GUI-based
- editors will be the preferred way of editing filters for a large
- number of users.
-
-
-
-Showalter Standards Track [Page 3]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
-1.1. Conventions Used in This Document
-
- In the sections of this document that discuss the requirements of
- various keywords and operators, the following conventions have been
- adopted.
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and
- "MAY" in this document are to be interpreted as defined in
- [KEYWORDS].
-
- Each section on a command (test, action, or control structure) has a
- line labeled "Syntax:". This line describes the syntax of the
- command, including its name and its arguments. Required arguments
- are listed inside angle brackets ("<" and ">"). Optional arguments
- are listed inside square brackets ("[" and "]"). Each argument is
- followed by its type, so "<key: string>" represents an argument
- called "key" that is a string. Literal strings are represented with
- double-quoted strings. Alternatives are separated with slashes, and
- parenthesis are used for grouping, similar to [ABNF].
-
- In the "Syntax" line, there are three special pieces of syntax that
- are frequently repeated, MATCH-TYPE, COMPARATOR, and ADDRESS-PART.
- These are discussed in sections 2.7.1, 2.7.3, and 2.7.4,
- respectively.
-
- The formal grammar for these commands in section 10 and is the
- authoritative reference on how to construct commands, but the formal
- grammar does not specify the order, semantics, number or types of
- arguments to commands, nor the legal command names. The intent is to
- allow for extension without changing the grammar.
-
-1.2. Example mail messages
-
- The following mail messages will be used throughout this document in
- examples.
-
- Message A
- -----------------------------------------------------------
- Date: Tue, 1 Apr 1997 09:06:31 -0800 (PST)
- From: address@hidden
- To: address@hidden
- Subject: I have a present for you
-
- Look, I'm sorry about the whole anvil thing, and I really
- didn't mean to try and drop it on you from the top of the
- cliff. I want to try to make it up to you. I've got some
- great birdseed over here at my place--top of the line
-
-
-
-
-Showalter Standards Track [Page 4]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- stuff--and if you come by, I'll have it all wrapped up
- for you. I'm really sorry for all the problems I've caused
- for you over the years, but I know we can work this out.
- --
- Wile E. Coyote "Super Genius" address@hidden
- -----------------------------------------------------------
-
- Message B
- -----------------------------------------------------------
- From: address@hidden
- Sender: address@hidden
- To: address@hidden
- Date: Mon, 31 Mar 1997 18:26:10 -0800
- Subject: $$$ YOU, TOO, CAN BE A MILLIONAIRE! $$$
-
- YOU MAY HAVE ALREADY WON TEN MILLION DOLLARS, BUT I DOUBT
- IT! SO JUST POST THIS TO SIX HUNDRED NEWSGROUPS! IT WILL
- GUARANTEE THAT YOU GET AT LEAST FIVE RESPONSES WITH MONEY!
- MONEY! MONEY! COLD HARD CASH! YOU WILL RECEIVE OVER
- $20,000 IN LESS THAN TWO MONTHS! AND IT'S LEGAL!!!!!!!!!
- !!!!!!!!!!!!!!!!!!111111111!!!!!!!11111111111!!1 JUST
- SEND $5 IN SMALL, UNMARKED BILLS TO THE ADDRESSES BELOW!
- -----------------------------------------------------------
-
-2. Design
-
-2.1. Form of the Language
-
- The language consists of a set of commands. Each command consists of
- a set of tokens delimited by whitespace. The command identifier is
- the first token and it is followed by zero or more argument tokens.
- Arguments may be literal data, tags, blocks of commands, or test
- commands.
-
- The language is represented in UTF-8, as specified in [UTF-8].
-
- Tokens in the ASCII range are considered case-insensitive.
-
-2.2. Whitespace
-
- Whitespace is used to separate tokens. Whitespace is made up of
- tabs, newlines (CRLF, never just CR or LF), and the space character.
- The amount of whitespace used is not significant.
-
-
-
-
-
-
-
-
-Showalter Standards Track [Page 5]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
-2.3. Comments
-
- Two types of comments are offered. Comments are semantically
- equivalent to whitespace and can be used anyplace that whitespace is
- (with one exception in multi-line strings, as described in the
- grammar).
-
- Hash comments begin with a "#" character that is not contained within
- a string and continue until the next CRLF.
-
- Example: if size :over 100K { # this is a comment
- discard;
- }
-
- Bracketed comments begin with the token "/*" and end with "*/" outside
- of a string. Bracketed comments may span multiple lines. Bracketed
- comments do not nest.
-
- Example: if size :over 100K { /* this is a comment
- this is still a comment */ discard /* this is a comment
- */ ;
- }
-
-2.4. Literal Data
-
- Literal data means data that is not executed, merely evaluated "as
- is", to be used as arguments to commands. Literal data is limited to
- numbers and strings.
-
-2.4.1. Numbers
-
- Numbers are given as ordinary decimal numbers. However, those
- numbers that have a tendency to be fairly large, such as message
- sizes, MAY have a "K", "M", or "G" appended to indicate a multiple of
- a power of two. To be comparable with the power-of-two-based
- versions of SI units that computers frequently use, K specifies
- kibi-, or 1,024 (2^10) times the value of the number; M specifies
- mebi-, or 1,048,576 (2^20) times the value of the number; and G
- specifies tebi-, or 1,073,741,824 (2^30) times the value of the
- number [BINARY-SI].
-
- Implementations MUST provide 31 bits of magnitude in numbers, but MAY
- provide more.
-
- Only positive integers are permitted by this specification.
-
-
-
-
-
-
-Showalter Standards Track [Page 6]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
-2.4.2. Strings
-
- Scripts involve large numbers of strings as they are used for pattern
- matching, addresses, textual bodies, etc. Typically, short quoted
- strings suffice for most uses, but a more convenient form is provided
- for longer strings such as bodies of messages.
-
- A quoted string starts and ends with a single double quote (the <">
- character, ASCII 34). A backslash ("\", ASCII 92) inside of a quoted
- string is followed by either another backslash or a double quote.
- This two-character sequence represents a single backslash or double-
- quote within the string, respectively.
-
- No other characters should be escaped with a single backslash.
-
- An undefined escape sequence (such as "\a" in a context where "a" has
- no special meaning) is interpreted as if there were no backslash (in
- this case, "\a" is just "a").
-
- Non-printing characters such as tabs, CR and LF, and control
- characters are permitted in quoted strings. Quoted strings MAY span
- multiple lines. NUL (ASCII 0) is not allowed in strings.
-
- For entering larger amounts of text, such as an email message, a
- multi-line form is allowed. It starts with the keyword "text:",
- followed by a CRLF, and ends with the sequence of a CRLF, a single
- period, and another CRLF. In order to allow the message to contain
- lines with a single-dot, lines are dot-stuffed. That is, when
- composing a message body, an extra `.' is added before each line
- which begins with a `.'. When the server interprets the script,
- these extra dots are removed. Note that a line that begins with a
- dot followed by a non-dot character is not interpreted dot-stuffed;
- that is, ".foo" is interpreted as ".foo". However, because this is
- potentially ambiguous, scripts SHOULD be properly dot-stuffed so such
- lines do not appear.
-
- Note that a hashed comment or whitespace may occur in between the
- "text:" and the CRLF, but not within the string itself. Bracketed
- comments are not allowed here.
-
-2.4.2.1. String Lists
-
- When matching patterns, it is frequently convenient to match against
- groups of strings instead of single strings. For this reason, a list
- of strings is allowed in many tests, implying that if the test is
- true using any one of the strings, then the test is true.
- Implementations are encouraged to use short-circuit evaluation in
- these cases.
-
-
-
-Showalter Standards Track [Page 7]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- For instance, the test `header :contains ["To", "Cc"]
- ["address@hidden", "address@hidden"]' is true if either the
- To header or Cc header of the input message contains either of the
- e-mail addresses "address@hidden" or "address@hidden".
-
- Conversely, in any case where a list of strings is appropriate, a
- single string is allowed without being a member of a list: it is
- equivalent to a list with a single member. This means that the test
- `exists "To"' is equivalent to the test `exists ["To"]'.
-
-2.4.2.2. Headers
-
- Headers are a subset of strings. In the Internet Message
- Specification [IMAIL] [RFC1123], each header line is allowed to have
- whitespace nearly anywhere in the line, including after the field
- name and before the subsequent colon. Extra spaces between the
- header name and the ":" in a header field are ignored.
-
- A header name never contains a colon. The "From" header refers to a
- line beginning "From:" (or "From :", etc.). No header will match
- the string "From:" due to the trailing colon.
-
- Folding of long header lines (as described in [IMAIL] 3.4.8) is
- removed prior to interpretation of the data. The folding syntax (the
- CRLF that ends a line plus any leading whitespace at the beginning of
- the next line that indicates folding) are interpreted as if they were
- a single space.
-
-2.4.2.3. Addresses
-
- A number of commands call for email addresses, which are also a
- subset of strings. When these addresses are used in outbound
- contexts, addresses must be compliant with [IMAIL], but are further
- constrained. Using the symbols defined in [IMAIL], section 6.1, the
- syntax of an address is:
-
- sieve-address = addr-spec ; simple address
- / phrase "<" addr-spec ">" ; name & addr-spec
-
- That is, routes and group syntax are not permitted. If multiple
- addresses are required, use a string list. Named groups are not used
- here.
-
- Implementations MUST ensure that the addresses are syntactically
- valid, but need not ensure that they actually identify an email
- recipient.
-
-
-
-
-
-Showalter Standards Track [Page 8]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
-2.4.2.4. MIME Parts
-
- In a few places, [MIME] body parts are represented as strings. These
- parts include MIME headers and the body. This provides a way of
- embedding typed data within a Sieve script so that, among other
- things, character sets other than UTF-8 can be used for output
- messages.
-
-2.5. Tests
-
- Tests are given as arguments to commands in order to control their
- actions. In this document, tests are given to if/elsif/else to
- decide which block of code is run.
-
- Tests MUST NOT have side effects. That is, a test cannot affect the
- state of the filter or message. No tests in this specification have
- side effects, and side effects are forbidden in extension tests as
- well.
-
- The rationale for this is that tests with side effects impair
- readability and maintainability and are difficult to represent in a
- graphic interface for generating scripts. Side effects are confined
- to actions where they are clearer.
-
-2.5.1. Test Lists
-
- Some tests ("allof" and "anyof", which implement logical "and" and
- logical "or", respectively) may require more than a single test as an
- argument. The test-list syntax element provides a way of grouping
- tests.
-
- Example: if anyof (not exists ["From", "Date"],
- header :contains "from" "address@hidden") {
- discard;
- }
-
-2.6. Arguments
-
- In order to specify what to do, most commands take arguments. There
- are three types of arguments: positional, tagged, and optional.
-
-2.6.1. Positional Arguments
-
- Positional arguments are given to a command which discerns their
- meaning based on their order. When a command takes positional
- arguments, all positional arguments must be supplied and must be in
- the order prescribed.
-
-
-
-
-Showalter Standards Track [Page 9]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
-2.6.2. Tagged Arguments
-
- This document provides for tagged arguments in the style of
- CommonLISP. These are also similar to flags given to commands in
- most command-line systems.
-
- A tagged argument is an argument for a command that begins with ":"
- followed by a tag naming the argument, such as ":contains". This
- argument means that zero or more of the next tokens have some
- particular meaning depending on the argument. These next tokens may
- be numbers or strings but they are never blocks.
-
- Tagged arguments are similar to positional arguments, except that
- instead of the meaning being derived from the command, it is derived
- from the tag.
-
- Tagged arguments must appear before positional arguments, but they
- may appear in any order with other tagged arguments. For simplicity
- of the specification, this is not expressed in the syntax definitions
- with commands, but they still may be reordered arbitrarily provided
- they appear before positional arguments. Tagged arguments may be
- mixed with optional arguments.
-
- To simplify this specification, tagged arguments SHOULD NOT take
- tagged arguments as arguments.
-
-2.6.3. Optional Arguments
-
- Optional arguments are exactly like tagged arguments except that they
- may be left out, in which case a default value is implied. Because
- optional arguments tend to result in shorter scripts, they have been
- used far more than tagged arguments.
-
- One particularly noteworthy case is the ":comparator" argument, which
- allows the user to specify which [ACAP] comparator will be used to
- compare two strings, since different languages may impose different
- orderings on UTF-8 [UTF-8] characters.
-
-2.6.4. Types of Arguments
-
- Abstractly, arguments may be literal data, tests, or blocks of
- commands. In this way, an "if" control structure is merely a command
- that happens to take a test and a block as arguments and may execute
- the block of code.
-
- However, this abstraction is ambiguous from a parsing standpoint.
- The grammar in section 9.2 presents a parsable version of this:
- Arguments are string-lists, numbers, and tags, which may be followed
-
-
-
-Showalter Standards Track [Page 10]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- by a test or a test-list, which may be followed by a block of
- commands. No more than one test or test list, nor more than one
- block of commands, may be used, and commands that end with blocks of
- commands do not end with semicolons.
-
-2.7. String Comparison
-
- When matching one string against another, there are a number of ways
- of performing the match operation. These are accomplished with three
- types of matches: an exact match, a substring match, and a wildcard
- glob-style match. These are described below.
-
- In order to provide for matches between character sets and case
- insensitivity, Sieve borrows ACAP's comparator registry.
-
- However, when a string represents the name of a header, the
- comparator is never user-specified. Header comparisons are always
- done with the "i;ascii-casemap" operator, i.e., case-insensitive
- comparisons, because this is the way things are defined in the
- message specification [IMAIL].
-
-2.7.1. Match Type
-
- There are three match types describing the matching used in this
- specification: ":is", ":contains", and ":matches". Match type
- arguments are supplied to those commands which allow them to specify
- what kind of match is to be performed.
-
- These are used as tagged arguments to tests that perform string
- comparison.
-
- The ":contains" match type describes a substring match. If the value
- argument contains the key argument as a substring, the match is true.
- For instance, the string "frobnitzm" contains "frob" and "nit", but
- not "fbm". The null key ("") is contained in all values.
-
- The ":is" match type describes an absolute match; if the contents of
- the first string are absolutely the same as the contents of the
- second string, they match. Only the string "frobnitzm" is the string
- "frobnitzm". The null key ":is" and only ":is" the null value.
-
- The ":matches" version specifies a wildcard match using the
- characters "*" and "?". "*" matches zero or more characters, and "?"
- matches a single character. "?" and "*" may be escaped as "\\?" and
- "\\*" in strings to match against themselves. The first backslash
- escapes the second backslash; together, they escape the "*". This is
- awkward, but it is commonplace in several programming languages that
- use globs and regular expressions.
-
-
-
-Showalter Standards Track [Page 11]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- In order to specify what type of match is supposed to happen,
- commands that support matching take optional tagged arguments
- ":matches", ":is", and ":contains". Commands default to using ":is"
- matching if no match type argument is supplied. Note that these
- modifiers may interact with comparators; in particular, some
- comparators are not suitable for matching with ":contains" or
- ":matches". It is an error to use a comparator with ":contains" or
- ":matches" that is not compatible with it.
-
- It is an error to give more than one of these arguments to a given
- command.
-
- For convenience, the "MATCH-TYPE" syntax element is defined here as
- follows:
-
- Syntax: ":is" / ":contains" / ":matches"
-
-2.7.2. Comparisons Across Character Sets
-
- All Sieve scripts are represented in UTF-8, but messages may involve
- a number of character sets. In order for comparisons to work across
- character sets, implementations SHOULD implement the following
- behavior:
-
- Implementations decode header charsets to UTF-8. Two strings are
- considered equal if their UTF-8 representations are identical.
- Implementations should decode charsets represented in the forms
- specified by [MIME] for both message headers and bodies.
- Implementations must be capable of decoding US-ASCII, ISO-8859-1,
- the ASCII subset of ISO-8859-* character sets, and UTF-8.
-
- If implementations fail to support the above behavior, they MUST
- conform to the following:
-
- No two strings can be considered equal if one contains octets
- greater than 127.
-
-2.7.3. Comparators
-
- In order to allow for language-independent, case-independent matches,
- the match type may be coupled with a comparator name. Comparators
- are described for [ACAP]; a registry is defined for ACAP, and this
- specification uses that registry.
-
- ACAP defines multiple comparator types. Only equality types are used
- in this specification.
-
-
-
-
-
-Showalter Standards Track [Page 12]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- All implementations MUST support the "i;octet" comparator (simply
- compares octets) and the "i;ascii-casemap" comparator (which treats
- uppercase and lowercase characters in the ASCII subset of UTF-8 as
- the same). If left unspecified, the default is "i;ascii-casemap".
-
- Some comparators may not be usable with substring matches; that is,
- they may only work with ":is". It is an error to try and use a
- comparator with ":matches" or ":contains" that is not compatible with
- it.
-
- A comparator is specified by the ":comparator" option with commands
- that support matching. This option is followed by a string providing
- the name of the comparator to be used. For convenience, the syntax
- of a comparator is abbreviated to "COMPARATOR", and (repeated in
- several tests) is as follows:
-
- Syntax: ":comparator" <comparator-name: string>
-
- So in this example,
-
- Example: if header :contains :comparator "i;octet" "Subject"
- "MAKE MONEY FAST" {
- discard;
- }
-
- would discard any message with subjects like "You can MAKE MONEY
- FAST", but not "You can Make Money Fast", since the comparator used
- is case-sensitive.
-
- Comparators other than i;octet and i;ascii-casemap must be declared
- with require, as they are extensions. If a comparator declared with
- require is not known, it is an error, and execution fails. If the
- comparator is not declared with require, it is also an error, even if
- the comparator is supported. (See 2.10.5.)
-
- Both ":matches" and ":contains" match types are compatible with the
- "i;octet" and "i;ascii-casemap" comparators and may be used with
- them.
-
- It is an error to give more than one of these arguments to a given
- command.
-
-2.7.4. Comparisons Against Addresses
-
- Addresses are one of the most frequent things represented as strings.
- These are structured, and being able to compare against the local-
- part or the domain of an address is useful, so some tests that act
-
-
-
-
-Showalter Standards Track [Page 13]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- exclusively on addresses take an additional optional argument that
- specifies what the test acts on.
-
- These optional arguments are ":localpart", ":domain", and ":all",
- which act on the local-part (left-side), the domain part (right-
- side), and the whole address.
-
- The kind of comparison done, such as whether or not the test done is
- case-insensitive, is specified as a comparator argument to the test.
-
- If an optional address-part is omitted, the default is ":all".
-
- It is an error to give more than one of these arguments to a given
- command.
-
- For convenience, the "ADDRESS-PART" syntax element is defined here as
- follows:
-
- Syntax: ":localpart" / ":domain" / ":all"
-
-2.8. Blocks
-
- Blocks are sets of commands enclosed within curly braces. Blocks are
- supplied to commands so that the commands can implement control
- commands.
-
- A control structure is a command that happens to take a test and a
- block as one of its arguments; depending on the result of the test
- supplied as another argument, it runs the code in the block some
- number of times.
-
- With the commands supplied in this memo, there are no loops. The
- control structures supplied--if, elsif, and else--run a block either
- once or not at all. So there are two arguments, the test and the
- block.
-
-2.9. Commands
-
- Sieve scripts are sequences of commands. Commands can take any of
- the tokens above as arguments, and arguments may be either tagged or
- positional arguments. Not all commands take all arguments.
-
- There are three kinds of commands: test commands, action commands,
- and control commands.
-
- The simplest is an action command. An action command is an
- identifier followed by zero or more arguments, terminated by a
- semicolon. Action commands do not take tests or blocks as arguments.
-
-
-
-Showalter Standards Track [Page 14]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- A control command is similar, but it takes a test as an argument, and
- ends with a block instead of a semicolon.
-
- A test command is used as part of a control command. It is used to
- specify whether or not the block of code given to the control command
- is executed.
-
-2.10. Evaluation
-
-2.10.1. Action Interaction
-
- Some actions cannot be used with other actions because the result
- would be absurd. These restrictions are noted throughout this memo.
-
- Extension actions MUST state how they interact with actions defined
- in this specification.
-
-2.10.2. Implicit Keep
-
- Previous experience with filtering systems suggests that cases tend
- to be missed in scripts. To prevent errors, Sieve has an "implicit
- keep".
-
- An implicit keep is a keep action (see 4.4) performed in absence of
- any action that cancels the implicit keep.
-
- An implicit keep is performed if a message is not written to a
- mailbox, redirected to a new address, or explicitly thrown out. That
- is, if a fileinto, a keep, a redirect, or a discard is performed, an
- implicit keep is not.
-
- Some actions may be defined to not cancel the implicit keep. These
- actions may not directly affect the delivery of a message, and are
- used for their side effects. None of the actions specified in this
- document meet that criteria, but extension actions will.
-
- For instance, with any of the short messages offered above, the
- following script produces no actions.
-
- Example: if size :over 500K { discard; }
-
- As a result, the implicit keep is taken.
-
-2.10.3. Message Uniqueness in a Mailbox
-
- Implementations SHOULD NOT deliver a message to the same folder more
- than once, even if a script explicitly asks for a message to be
- written to a mailbox twice.
-
-
-
-Showalter Standards Track [Page 15]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- The test for equality of two messages is implementation-defined.
-
- If a script asks for a message to be written to a mailbox twice, it
- MUST NOT be treated as an error.
-
-2.10.4. Limits on Numbers of Actions
-
- Site policy MAY limit numbers of actions taken and MAY impose
- restrictions on which actions can be used together. In the event
- that a script hits a policy limit on the number of actions taken for
- a particular message, an error occurs.
-
- Implementations MUST prohibit more than one reject.
-
- Implementations MUST allow at least one keep or one fileinto. If
- fileinto is not implemented, implementations MUST allow at least one
- keep.
-
- Implementations SHOULD prohibit reject when used with other actions.
-
-2.10.5. Extensions and Optional Features
-
- Because of the differing capabilities of many mail systems, several
- features of this specification are optional. Before any of these
- extensions can be executed, they must be declared with the "require"
- action.
-
- If an extension is not enabled with "require", implementations MUST
- treat it as if they did not support it at all.
-
- If a script does not understand an extension declared with require,
- the script must not be used at all. Implementations MUST NOT execute
- scripts which require unknown capability names.
-
- Note: The reason for this restriction is that prior experiences with
- languages such as LISP and Tcl suggest that this is a workable
- way of noting that a given script uses an extension.
-
- Experience with PostScript suggests that mechanisms that allow
- a script to work around missing extensions are not used in
- practice.
-
- Extensions which define actions MUST state how they interact with
- actions discussed in the base specification.
-
-
-
-
-
-
-
-Showalter Standards Track [Page 16]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
-2.10.6. Errors
-
- In any programming language, there are compile-time and run-time
- errors.
-
- Compile-time errors are ones in syntax that are detectable if a
- syntax check is done.
-
- Run-time errors are not detectable until the script is run. This
- includes transient failures like disk full conditions, but also
- includes issues like invalid combinations of actions.
-
- When an error occurs in a Sieve script, all processing stops.
-
- Implementations MAY choose to do a full parse, then evaluate the
- script, then do all actions. Implementations might even go so far as
- to ensure that execution is atomic (either all actions are executed
- or none are executed).
-
- Other implementations may choose to parse and run at the same time.
- Such implementations are simpler, but have issues with partial
- failure (some actions happen, others don't).
-
- Implementations might even go so far as to ensure that scripts can
- never execute an invalid set of actions (e.g., reject + fileinto)
- before execution, although this could involve solving the Halting
- Problem.
-
- This specification allows any of these approaches. Solving the
- Halting Problem is considered extra credit.
-
- When an error happens, implementations MUST notify the user that an
- error occurred, which actions (if any) were taken, and do an implicit
- keep.
-
-2.10.7. Limits on Execution
-
- Implementations may limit certain constructs. However, this
- specification places a lower bound on some of these limits.
-
- Implementations MUST support fifteen levels of nested blocks.
-
- Implementations MUST support fifteen levels of nested test lists.
-
-3. Control Commands
-
- Control structures are needed to allow for multiple and conditional
- actions.
-
-
-
-Showalter Standards Track [Page 17]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
-3.1. Control Structure If
-
- There are three pieces to if: "if", "elsif", and "else". Each is
- actually a separate command in terms of the grammar. However, an
- elsif MUST only follow an if, and an else MUST follow only either an
- if or an elsif. An error occurs if these conditions are not met.
-
- Syntax: if <test1: test> <block1: block>
-
- Syntax: elsif <test2: test> <block2: block>
-
- Syntax: else <block>
-
- The semantics are similar to those of any of the many other
- programming languages these control commands appear in. When the
- interpreter sees an "if", it evaluates the test associated with it.
- If the test is true, it executes the block associated with it.
-
- If the test of the "if" is false, it evaluates the test of the first
- "elsif" (if any). If the test of "elsif" is true, it runs the
- elsif's block. An elsif may be followed by an elsif, in which case,
- the interpreter repeats this process until it runs out of elsifs.
-
- When the interpreter runs out of elsifs, there may be an "else" case.
- If there is, and none of the if or elsif tests were true, the
- interpreter runs the else case.
-
- This provides a way of performing exactly one of the blocks in the
- chain.
-
- In the following example, both Message A and B are dropped.
-
- Example: require "fileinto";
- if header :contains "from" "coyote" {
- discard;
- } elsif header :contains ["subject"] ["$$$"] {
- discard;
- } else {
- fileinto "INBOX";
- }
-
-
- When the script below is run over message A, it redirects the message
- to address@hidden; message B, to address@hidden; any other
- message is redirected to address@hidden
-
-
-
-
-
-
-Showalter Standards Track [Page 18]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- Example: if header :contains ["From"] ["coyote"] {
- redirect "address@hidden";
- } elsif header :contains "Subject" "$$$" {
- redirect "address@hidden";
- } else {
- redirect "address@hidden";
- }
-
- Note that this definition prohibits the "... else if ..." sequence
- used by C. This is intentional, because this construct produces a
- shift-reduce conflict.
-
-3.2. Control Structure Require
-
- Syntax: require <capabilities: string-list>
-
- The require action notes that a script makes use of a certain
- extension. Such a declaration is required to use the extension, as
- discussed in section 2.10.5. Multiple capabilities can be declared
- with a single require.
-
- The require command, if present, MUST be used before anything other
- than a require can be used. An error occurs if a require appears
- after a command other than require.
-
- Example: require ["fileinto", "reject"];
-
- Example: require "fileinto";
- require "vacation";
-
-3.3. Control Structure Stop
-
- Syntax: stop
-
- The "stop" action ends all processing. If no actions have been
- executed, then the keep action is taken.
-
-4. Action Commands
-
- This document supplies five actions that may be taken on a message:
- keep, fileinto, redirect, reject, and discard.
-
- Implementations MUST support the "keep", "discard", and "redirect"
- actions.
-
- Implementations SHOULD support "reject" and "fileinto".
-
-
-
-
-
-Showalter Standards Track [Page 19]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- Implementations MAY limit the number of certain actions taken (see
- section 2.10.4).
-
-4.1. Action reject
-
- Syntax: reject <reason: string>
-
- The optional "reject" action refuses delivery of a message by sending
- back an [MDN] to the sender. It resends the message to the sender,
- wrapping it in a "reject" form, noting that it was rejected by the
- recipient. In the following script, message A is rejected and
- returned to the sender.
-
- Example: if header :contains "from" "address@hidden" {
- reject "I am not taking mail from you, and I don't want
- your birdseed, either!";
- }
-
- A reject message MUST take the form of a failure MDN as specified by
- [MDN]. The human-readable portion of the message, the first
- component of the MDN, contains the human readable message describing
- the error, and it SHOULD contain additional text alerting the
- original sender that mail was refused by a filter. This part of the
- MDN might appear as follows:
-
- ------------------------------------------------------------
- Message was refused by recipient's mail filtering program. Reason
- given was as follows:
-
- I am not taking mail from you, and I don't want your birdseed,
- either!
- ------------------------------------------------------------
-
- The MDN action-value field as defined in the MDN specification MUST
- be "deleted" and MUST have the MDN-sent-automatically and automatic-
- action modes set.
-
- Because some implementations can not or will not implement the reject
- command, it is optional. The capability string to be used with the
- require command is "reject".
-
-4.2. Action fileinto
-
- Syntax: fileinto <folder: string>
-
- The "fileinto" action delivers the message into the specified folder.
- Implementations SHOULD support fileinto, but in some environments
- this may be impossible.
-
-
-
-Showalter Standards Track [Page 20]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- The capability string for use with the require command is "fileinto".
-
- In the following script, message A is filed into folder
- "INBOX.harassment".
-
- Example: require "fileinto";
- if header :contains ["from"] "coyote" {
- fileinto "INBOX.harassment";
- }
-
-4.3. Action redirect
-
- Syntax: redirect <address: string>
-
- The "redirect" action is used to send the message to another user at
- a supplied address, as a mail forwarding feature does. The
- "redirect" action makes no changes to the message body or existing
- headers, but it may add new headers. The "redirect" modifies the
- envelope recipient.
-
- The redirect command performs an MTA-style "forward"--that is, what
- you get from a .forward file using sendmail under UNIX. The address
- on the SMTP envelope is replaced with the one on the redirect command
- and the message is sent back out. (This is not an MUA-style forward,
- which creates a new message with a different sender and message ID,
- wrapping the old message in a new one.)
-
- A simple script can be used for redirecting all mail:
-
- Example: redirect "address@hidden";
-
- Implementations SHOULD take measures to implement loop control,
- possibly including adding headers to the message or counting received
- headers. If an implementation detects a loop, it causes an error.
-
-4.4. Action keep
-
- Syntax: keep
-
- The "keep" action is whatever action is taken in lieu of all other
- actions, if no filtering happens at all; generally, this simply means
- to file the message into the user's main mailbox. This command
- provides a way to execute this action without needing to know the
- name of the user's main mailbox, providing a way to call it without
- needing to understand the user's setup, or the underlying mail
- system.
-
-
-
-
-
-Showalter Standards Track [Page 21]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- For instance, in an implementation where the IMAP server is running
- scripts on behalf of the user at time of delivery, a keep command is
- equivalent to a fileinto "INBOX".
-
- Example: if size :under 1M { keep; } else { discard; }
-
- Note that the above script is identical to the one below.
-
- Example: if not size :under 1M { discard; }
-
-4.5. Action discard
-
- Syntax: discard
-
- Discard is used to silently throw away the message. It does so by
- simply canceling the implicit keep. If discard is used with other
- actions, the other actions still happen. Discard is compatible with
- all other actions. (For instance fileinto+discard is equivalent to
- fileinto.)
-
- Discard MUST be silent; that is, it MUST NOT return a non-delivery
- notification of any kind ([DSN], [MDN], or otherwise).
-
- In the following script, any mail from "address@hidden" is thrown
- out.
-
- Example: if header :contains ["from"] ["address@hidden"] {
- discard;
- }
-
- While an important part of this language, "discard" has the potential
- to create serious problems for users: Students who leave themselves
- logged in to an unattended machine in a public computer lab may find
- their script changed to just "discard". In order to protect users in
- this situation (along with similar situations), implementations MAY
- keep messages destroyed by a script for an indefinite period, and MAY
- disallow scripts that throw out all mail.
-
-5. Test Commands
-
- Tests are used in conditionals to decide which part(s) of the
- conditional to execute.
-
- Implementations MUST support these tests: "address", "allof",
- "anyof", "exists", "false", "header", "not", "size", and "true".
-
- Implementations SHOULD support the "envelope" test.
-
-
-
-
-Showalter Standards Track [Page 22]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
-5.1. Test address
-
- Syntax: address [ADDRESS-PART] [COMPARATOR] [MATCH-TYPE]
- <header-list: string-list> <key-list: string-list>
-
- The address test matches Internet addresses in structured headers
- that contain addresses. It returns true if any header contains any
- key in the specified part of the address, as modified by the
- comparator and the match keyword.
-
- Like envelope and header, this test returns true if any combination
- of the header-list and key-list arguments match.
-
- Internet email addresses [IMAIL] have the somewhat awkward
- characteristic that the local-part to the left of the at-sign is
- considered case sensitive, and the domain-part to the right of the
- at-sign is case insensitive. The "address" command does not deal
- with this itself, but provides the ADDRESS-PART argument for allowing
- users to deal with it.
-
- The address primitive never acts on the phrase part of an email
- address, nor on comments within that address. It also never acts on
- group names, although it does act on the addresses within the group
- construct.
-
- Implementations MUST restrict the address test to headers that
- contain addresses, but MUST include at least From, To, Cc, Bcc,
- Sender, Resent-From, Resent-To, and SHOULD include any other header
- that utilizes an "address-list" structured header body.
-
- Example: if address :is :all "from" "address@hidden" {
- discard;
-
-5.2. Test allof
-
- Syntax: allof <tests: test-list>
-
- The allof test performs a logical AND on the tests supplied to it.
-
- Example: allof (false, false) => false
- allof (false, true) => false
- allof (true, true) => true
-
- The allof test takes as its argument a test-list.
-
-
-
-
-
-
-
-Showalter Standards Track [Page 23]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
-5.3. Test anyof
-
- Syntax: anyof <tests: test-list>
-
- The anyof test performs a logical OR on the tests supplied to it.
-
- Example: anyof (false, false) => false
- anyof (false, true) => true
- anyof (true, true) => true
-
-5.4. Test envelope
-
- Syntax: envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
- <envelope-part: string-list> <key-list: string-list>
-
- The "envelope" test is true if the specified part of the SMTP (or
- equivalent) envelope matches the specified key.
-
- If one of the envelope-part strings is (case insensitive) "from",
- then matching occurs against the FROM address used in the SMTP MAIL
- command.
-
- If one of the envelope-part strings is (case insensitive) "to", then
- matching occurs against the TO address used in the SMTP RCPT command
- that resulted in this message getting delivered to this user. Note
- that only the most recent TO is available, and only the one relevant
- to this user.
-
- The envelope-part is a string list and may contain more than one
- parameter, in which case all of the strings specified in the key-list
- are matched against all parts given in the envelope-part list.
-
- Like address and header, this test returns true if any combination of
- the envelope-part and key-list arguments is true.
-
- All tests against envelopes MUST drop source routes.
-
- If the SMTP transaction involved several RCPT commands, only the data
- from the RCPT command that caused delivery to this user is available
- in the "to" part of the envelope.
-
- If a protocol other than SMTP is used for message transport,
- implementations are expected to adapt this command appropriately.
-
- The envelope command is optional. Implementations SHOULD support it,
- but the necessary information may not be available in all cases.
-
-
-
-
-
-Showalter Standards Track [Page 24]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- Example: require "envelope";
- if envelope :all :is "from" "address@hidden" {
- discard;
- }
-
-5.5. Test exists
-
- Syntax: exists <header-names: string-list>
-
- The "exists" test is true if the headers listed in the header-names
- argument exist within the message. All of the headers must exist or
- the test is false.
-
- The following example throws out mail that doesn't have a From header
- and a Date header.
-
- Example: if not exists ["From","Date"] {
- discard;
- }
-
-5.6. Test false
-
- Syntax: false
-
- The "false" test always evaluates to false.
-
-5.7. Test header
-
- Syntax: header [COMPARATOR] [MATCH-TYPE]
- <header-names: string-list> <key-list: string-list>
-
- The "header" test evaluates to true if any header name matches any
- key. The type of match is specified by the optional match argument,
- which defaults to ":is" if not specified, as specified in section
- 2.6.
-
- Like address and envelope, this test returns true if any combination
- of the string-list and key-list arguments match.
-
- If a header listed in the header-names argument exists, it contains
- the null key (""). However, if the named header is not present, it
- does not contain the null key. So if a message contained the header
-
- X-Caffeine: C8H10N4O2
-
-
-
-
-
-
-
-Showalter Standards Track [Page 25]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- these tests on that header evaluate as follows:
-
- header :is ["X-Caffeine"] [""] => false
- header :contains ["X-Caffeine"] [""] => true
-
-5.8. Test not
-
- Syntax: not <test>
-
- The "not" test takes some other test as an argument, and yields the
- opposite result. "not false" evaluates to "true" and "not true"
- evaluates to "false".
-
-5.9. Test size
-
- Syntax: size <":over" / ":under"> <limit: number>
-
- The "size" test deals with the size of a message. It takes either a
- tagged argument of ":over" or ":under", followed by a number
- representing the size of the message.
-
- If the argument is ":over", and the size of the message is greater
- than the number provided, the test is true; otherwise, it is false.
-
- If the argument is ":under", and the size of the message is less than
- the number provided, the test is true; otherwise, it is false.
-
- Exactly one of ":over" or ":under" must be specified, and anything
- else is an error.
-
- The size of a message is defined to be the number of octets from the
- initial header until the last character in the message body.
-
- Note that for a message that is exactly 4,000 octets, the message is
- neither ":over" 4000 octets or ":under" 4000 octets.
-
-5.10. Test true
-
- Syntax: true
-
- The "true" test always evaluates to true.
-
-6. Extensibility
-
- New control structures, actions, and tests can be added to the
- language. Sites must make these features known to their users; this
- document does not define a way to discover the list of extensions
- supported by the server.
-
-
-
-Showalter Standards Track [Page 26]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- Any extensions to this language MUST define a capability string that
- uniquely identifies that extension. If a new version of an extension
- changes the functionality of a previously defined extension, it MUST
- use a different name.
-
- In a situation where there is a submission protocol and an extension
- advertisement mechanism aware of the details of this language,
- scripts submitted can be checked against the mail server to prevent
- use of an extension that the server does not support.
-
- Extensions MUST state how they interact with constraints defined in
- section 2.10, e.g., whether they cancel the implicit keep, and which
- actions they are compatible and incompatible with.
-
-6.1. Capability String
-
- Capability strings are typically short strings describing what
- capabilities are supported by the server.
-
- Capability strings beginning with "vnd." represent vendor-defined
- extensions. Such extensions are not defined by Internet standards or
- RFCs, but are still registered with IANA in order to prevent
- conflicts. Extensions starting with "vnd." SHOULD be followed by the
- name of the vendor and product, such as "vnd.acme.rocket-sled".
-
- The following capability strings are defined by this document:
-
- envelope The string "envelope" indicates that the implementation
- supports the "envelope" command.
-
- fileinto The string "fileinto" indicates that the implementation
- supports the "fileinto" command.
-
- reject The string "reject" indicates that the implementation
- supports the "reject" command.
-
- comparator- The string "comparator-elbonia" is provided if the
- implementation supports the "elbonia" comparator.
- Therefore, all implementations have at least the
- "comparator-i;octet" and "comparator-i;ascii-casemap"
- capabilities. However, these comparators may be used
- without being declared with require.
-
-
-
-
-
-
-
-
-
-Showalter Standards Track [Page 27]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
-6.2. IANA Considerations
-
- In order to provide a standard set of extensions, a registry is
- provided by IANA. Capability names may be registered on a first-
- come, first-served basis. Extensions designed for interoperable use
- SHOULD be defined as standards track or IESG approved experimental
- RFCs.
-
-6.2.1. Template for Capability Registrations
-
- The following template is to be used for registering new Sieve
- extensions with IANA.
-
- To: address@hidden
- Subject: Registration of new Sieve extension
-
- Capability name:
- Capability keyword:
- Capability arguments:
- Standards Track/IESG-approved experimental RFC number:
- Person and email address to contact for further information:
-
-6.2.2. Initial Capability Registrations
-
- The following are to be added to the IANA registry for Sieve
- extensions as the initial contents of the capability registry.
-
- Capability name: fileinto
- Capability keyword: fileinto
- Capability arguments: fileinto <folder: string>
- Standards Track/IESG-approved experimental RFC number:
- RFC 3028 (Sieve base spec)
- Person and email address to contact for further information:
- Tim Showalter
- address@hidden
-
- Capability name: reject
- Capability keyword: reject
- Capability arguments: reject <reason: string>
- Standards Track/IESG-approved experimental RFC number:
- RFC 3028 (Sieve base spec)
- Person and email address to contact for further information:
- Tim Showalter
- address@hidden
-
-
-
-
-
-
-
-Showalter Standards Track [Page 28]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- Capability name: envelope
- Capability keyword: envelope
- Capability arguments:
- envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
- <envelope-part: string-list> <key-list: string-list>
- Standards Track/IESG-approved experimental RFC number:
- RFC 3028 (Sieve base spec)
- Person and email address to contact for further information:
- Tim Showalter
- address@hidden
-
- Capability name: comparator-*
- Capability keyword:
- comparator-* (anything starting with "comparator-")
- Capability arguments: (none)
- Standards Track/IESG-approved experimental RFC number:
- RFC 3028, Sieve, by reference of
- RFC 2244, Application Configuration Access Protocol
- Person and email address to contact for further information:
- Tim Showalter
- address@hidden
-
-6.3. Capability Transport
-
- As the range of mail systems that this document is intended to apply
- to is quite varied, a method of advertising which capabilities an
- implementation supports is difficult due to the wide range of
- possible implementations. Such a mechanism, however, should have
- property that the implementation can advertise the complete set of
- extensions that it supports.
-
-7. Transmission
-
- The MIME type for a Sieve script is "application/sieve".
-
- The registration of this type for RFC 2048 requirements is as
- follows:
-
- Subject: Registration of MIME media type application/sieve
-
- MIME media type name: application
- MIME subtype name: sieve
- Required parameters: none
- Optional parameters: none
- Encoding considerations: Most sieve scripts will be textual,
- written in UTF-8. When non-7bit characters are used,
- quoted-printable is appropriate for transport systems
- that require 7bit encoding.
-
-
-
-Showalter Standards Track [Page 29]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- Security considerations: Discussed in section 10 of RFC 3028.
- Interoperability considerations: Discussed in section 2.10.5
- of RFC 3028.
- Published specification: RFC 3028.
- Applications which use this media type: sieve-enabled mail servers
- Additional information:
- Magic number(s):
- File extension(s): .siv
- Macintosh File Type Code(s):
- Person & email address to contact for further information:
- See the discussion list at address@hidden
- Intended usage:
- COMMON
- Author/Change controller:
- See Author information in RFC 3028.
-
-8. Parsing
-
- The Sieve grammar is separated into tokens and a separate grammar as
- most programming languages are.
-
-8.1. Lexical Tokens
-
- Sieve scripts are encoded in UTF-8. The following assumes a valid
- UTF-8 encoding; special characters in Sieve scripts are all ASCII.
-
- The following are tokens in Sieve:
-
- - identifiers
- - tags
- - numbers
- - quoted strings
- - multi-line strings
- - other separators
-
- Blanks, horizontal tabs, CRLFs, and comments ("white space") are
- ignored except as they separate tokens. Some white space is required
- to separate otherwise adjacent tokens and in specific places in the
- multi-line strings.
-
- The other separators are single individual characters, and are
- mentioned explicitly in the grammar.
-
- The lexical structure of sieve is defined in the following BNF (as
- described in [ABNF]):
-
-
-
-
-
-
-Showalter Standards Track [Page 30]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- bracket-comment = "/*" *(CHAR-NOT-STAR / ("*" CHAR-NOT-SLASH)) "*/"
- ;; No */ allowed inside a comment.
- ;; (No * is allowed unless it is the last character,
- ;; or unless it is followed by a character that isn't a
- ;; slash.)
-
- CHAR-NOT-DOT = (%x01-09 / %x0b-0c / %x0e-2d / %x2f-ff)
- ;; no dots, no CRLFs
-
- CHAR-NOT-CRLF = (%x01-09 / %x0b-0c / %x0e-ff)
-
- CHAR-NOT-SLASH = (%x00-57 / %x58-ff)
-
- CHAR-NOT-STAR = (%x00-51 / %x53-ff)
-
- comment = bracket-comment / hash-comment
-
- hash-comment = ( "#" *CHAR-NOT-CRLF CRLF )
-
- identifier = (ALPHA / "_") *(ALPHA DIGIT "_")
-
- tag = ":" identifier
-
- number = 1*DIGIT [QUANTIFIER]
-
- QUANTIFIER = "K" / "M" / "G"
-
- quoted-string = DQUOTE *CHAR DQUOTE
- ;; in general, \ CHAR inside a string maps to CHAR
- ;; so \" maps to " and \\ maps to \
- ;; note that newlines and other characters are all allowed
- ;; strings
-
- multi-line = "text:" *(SP / HTAB) (hash-comment / CRLF)
- *(multi-line-literal / multi-line-dotstuff)
- "." CRLF
- multi-line-literal = [CHAR-NOT-DOT *CHAR-NOT-CRLF] CRLF
- multi-line-dotstuff = "." 1*CHAR-NOT-CRLF CRLF
- ;; A line containing only "." ends the multi-line.
- ;; Remove a leading '.' if followed by another '.'.
-
- white-space = 1*(SP / CRLF / HTAB) / comment
-
-8.2. Grammar
-
- The following is the grammar of Sieve after it has been lexically
- interpreted. No white space or comments appear below. The start
- symbol is "start".
-
-
-
-Showalter Standards Track [Page 31]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- argument = string-list / number / tag
-
- arguments = *argument [test / test-list]
-
- block = "{" commands "}"
-
- command = identifier arguments ( ";" / block )
-
- commands = *command
-
- start = commands
-
- string = quoted-string / multi-line
-
- string-list = "[" string *("," string) "]" / string ;; if
- there is only a single string, the brackets are optional
-
- test = identifier arguments
-
- test-list = "(" test *("," test) ")"
-
-9. Extended Example
-
- The following is an extended example of a Sieve script. Note that it
- does not make use of the implicit keep.
-
- #
- # Example Sieve Filter
- # Declare any optional features or extension used by the script
- #
- require ["fileinto", "reject"];
-
- #
- # Reject any large messages (note that the four leading dots get
- # "stuffed" to three)
- #
- if size :over 1M
- {
- reject text:
- Please do not send me large attachments.
- Put your file on a server and send me the URL.
- Thank you.
- .... Fred
- .
- ;
- stop;
- }
- #
-
-
-
-Showalter Standards Track [Page 32]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- # Handle messages from known mailing lists
- # Move messages from IETF filter discussion list to filter folder
- #
- if header :is "Sender" "address@hidden"
- {
- fileinto "filter"; # move to "filter" folder
- }
- #
- # Keep all messages to or from people in my company
- #
- elsif address :domain :is ["From", "To"] "example.com"
- {
- keep; # keep in "In" folder
- }
-
- #
- # Try and catch unsolicited email. If a message is not to me,
- # or it contains a subject known to be spam, file it away.
- #
- elsif anyof (not address :all :contains
- ["To", "Cc", "Bcc"] "address@hidden",
- header :matches "subject"
- ["*make*money*fast*", "*university*dipl*mas*"])
- {
- # If message header does not contain my address,
- # it's from a list.
- fileinto "spam"; # move to "spam" folder
- }
- else
- {
- # Move all other (non-company) mail to "personal"
- # folder.
- fileinto "personal";
- }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Showalter Standards Track [Page 33]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
-10. Security Considerations
-
- Users must get their mail. It is imperative that whatever method
- implementations use to store the user-defined filtering scripts be
- secure.
-
- It is equally important that implementations sanity-check the user's
- scripts, and not allow users to create on-demand mailbombs. For
- instance, an implementation that allows a user to reject or redirect
- multiple times to a single message might also allow a user to create
- a mailbomb triggered by mail from a specific user. Site- or
- implementation-defined limits on actions are useful for this.
-
- Several commands, such as "discard", "redirect", and "fileinto" allow
- for actions to be taken that are potentially very dangerous.
-
- Implementations SHOULD take measures to prevent languages from
- looping.
-
-11. Acknowledgments
-
- I am very thankful to Chris Newman for his support and his ABNF
- syntax checker, to John Myers and Steve Hole for outlining the
- requirements for the original drafts, to Larry Greenfield for nagging
- me about the grammar and finally fixing it, to Greg Sereda for
- repeatedly fixing and providing examples, to Ned Freed for fixing
- everything else, to Rob Earhart for an early implementation and a
- great deal of help, and to Randall Gellens for endless amounts of
- proofreading. I am grateful to Carnegie Mellon University where most
- of the work on this document was done. I am also indebted to all of
- the readers of the address@hidden mailing list.
-
-12. Author's Address
-
- Tim Showalter
- Mirapoint, Inc.
- 909 Hermosa Court
- Sunnyvale, CA 94085
-
- EMail: address@hidden
-
-13. References
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
-
-
-
-
-
-Showalter Standards Track [Page 34]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
- [ACAP] Newman, C. and J. G. Myers, "ACAP -- Application
- Configuration Access Protocol", RFC 2244, November 1997.
-
- [BINARY-SI] "Standard IEC 60027-2: Letter symbols to be used in
- electrical technology - Part 2: Telecommunications and
- electronics", January 1999.
-
- [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format
- for Delivery Status Notifications", RFC 1894, January
- 1996.
-
- [FLAMES] Borenstein, N, and C. Thyberg, "Power, Ease of Use, and
- Cooperative Work in a Practical Multimedia Message
- System", Int. J. of Man-Machine Studies, April, 1991.
- Reprinted in Computer-Supported Cooperative Work and
- Groupware, Saul Greenberg, editor, Harcourt Brace
- Jovanovich, 1991. Reprinted in Readings in Groupware and
- Computer-Supported Cooperative Work, Ronald Baecker,
- editor, Morgan Kaufmann, 1993.
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [IMAP] Crispin, M., "Internet Message Access Protocol - version
- 4rev1", RFC 2060, December 1996.
-
- [IMAIL] Crocker, D., "Standard for the Format of ARPA Internet
- Text Messages", STD 11, RFC 822, August 1982.
-
- [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message
- Bodies", RFC 2045, November 1996.
-
- [MDN] Fajman, R., "An Extensible Message Format for Message
- Disposition Notifications", RFC 2298, March 1998.
-
- [RFC1123] Braden, R., "Requirements for Internet Hosts --
- Application and Support", STD 3, RFC 1123, November 1989.
-
- [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
- 821, August 1982.
-
- [UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode
- and ISO 10646", RFC 2044, October 1996.
-
-
-
-
-
-
-
-Showalter Standards Track [Page 35]
-
-RFC 3028 Sieve: A Mail Filtering Language January 2001
-
-
-14. Full Copyright Statement
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Showalter Standards Track [Page 36]
-
diff --git a/doc/rfc/rfc3206.txt b/doc/rfc/rfc3206.txt
deleted file mode 100644
index 9b542ba..0000000
--- a/doc/rfc/rfc3206.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Gellens
-Request for Comments: 3206 QUALCOMM
-Category: Standards Track February 2002
-
-
- The SYS and AUTH POP Response 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.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-Abstract
-
- This memo proposes two response codes: SYS and AUTH, which enable
- clients to unambiguously determine an optimal response to an
- authentication failure. In addition, a new capability (AUTH-RESP-
- CODE) is defined.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. Conventions Used in this Document . . . . . . . . . . . . . . 2
- 3. Background . . . . . . . . . . . . . . . . . . . . . . . . 2
- 4. The SYS Response Code . . . . . . . . . . . . . . . . . . . 3
- 5. The AUTH Response Code . . . . . . . . . . . . . . . . . . 3
- 6. The AUTH-RESP-CODE Capability . . . . . . . . . . . . . . . 4
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 4
- 8. Security Considerations . . . . . . . . . . . . . . . . . . 4
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . 5
- 10. Author's Address . . . . . . . . . . . . . . . . . . . . . . 5
- 11. Full Copyright Statement . . . . . . . . . . . . . . . . . 6
-
-
-
-
-
-
-
-
-
-
-
-
-Gellens Standards Track [Page 1]
-
-RFC 3206 The SYS and AUTH POP Response Codes February 2002
-
-
-
-1. Introduction
-
- RFC 2449 [POP3-EXT] defined extended [POP3] response codes, to give
- clients more information about errors so clients can respond more
- appropriately. In addition to the mechanism, two initial response
- codes were defined (IN-USE and LOGIN-DELAY), in an attempt to
- differentiate between authentication failures related to user
- credentials, and other errors.
-
- In practice, these two response codes, while helpful, do not go far
- enough. This memo proposes two additional response codes: SYS and
- AUTH, which enable clients to unambiguously determine an optimal
- response to an authentication failure.
-
- In addition, a new capability (AUTH-RESP-CODE) is defined.
-
-2. Conventions Used in this Document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [KEYWORDS].
-
-3. Background
-
- RFC 2449 [POP3-EXT] introduced the IN-USE and LOGIN-DELAY response
- codes. The intent is to allow clients to clearly determine the
- underlying cause of a failure in order to respond. For example,
- clients need to know if the user should be asked for new credentials,
- or if the POP3 session should simply be tried again later. (Some
- deployed POP3 clients attempt to parse the text of authentication
- failure errors, looking for strings known to be issued by various
- servers which indicate the mailbox is locked.)
-
- IN-USE indicates that an exclusive lock could not be obtained for the
- user's mailbox, probably because another POP3 session is in progress.
- LOGIN-DELAY informs the client that the user has not waited long
- enough before authenticating again.
-
- However, there are other error conditions which do not require new
- credentials, some of which should be brought to the user's attention.
-
- Despite the IN-USE and LOGIN-DELAY responses, clients cannot be sure
- if any other error requires new user credentials.
-
-
-
-
-
-
-
-Gellens Standards Track [Page 2]
-
-RFC 3206 The SYS and AUTH POP Response Codes February 2002
-
-
-4. The SYS Response Code
-
- The SYS response code announces that a failure is due to a system
- error, as opposed to the user's credentials or an external condition.
- It is hierarchical, with two possible second-level codes: TEMP and
- PERM. (Case is not significant at any level of the hierarchy.)
-
- SYS/TEMP indicates a problem which is likely to be temporary in
- nature, and therefore there is no need to alarm the user, unless the
- failure persists. Examples might include a central resource which is
- currently locked or otherwise temporarily unavailable, insufficient
- free disk or memory, etc.
-
- SYS/PERM is used for problems which are unlikely to be resolved
- without intervention. It is appropriate to alert the user and
- suggest that the organization's support or assistance personnel be
- contacted. Examples include corrupted mailboxes, system
- configuration errors, etc.
-
- The SYS response code is valid with an -ERR response to any command.
-
-5. The AUTH Response Code
-
- The AUTH response code informs the client that there is a problem
- with the user's credentials. This might be an incorrect password, an
- unknown user name, an expired account, an attempt to authenticate in
- violation of policy (such as from an invalid location or during an
- unauthorized time), or some other problem.
-
- The AUTH response code is valid with an -ERR response to any
- authentication command including AUTH, USER (see note), PASS, or
- APOP.
-
- Servers which include the AUTH response code with any authentication
- failure SHOULD support the CAPA command [POP3-EXT] and SHOULD include
- the AUTH-RESP-CODE capability in the CAPA response. AUTH-RESP-CODE
- assures the client that only errors with the AUTH code are caused by
- credential problems.
-
- NOTE: Returning the AUTH response code to the USER command
- reveals to the client that the specified user exists. It is
- strongly RECOMMENDED that the server not issue this response code
- to the USER command.
-
-
-
-
-
-
-
-
-Gellens Standards Track [Page 3]
-
-RFC 3206 The SYS and AUTH POP Response Codes February 2002
-
-
-6. The AUTH-RESP-CODE Capability
-
- CAPA tag:
- AUTH-RESP-CODE
-
- Arguments:
- none
-
- Added commands:
- none
-
- Standard commands affected:
- none
-
- Announced states / possible differences:
- both / no
-
- Commands valid in states:
- n/a
-
- Specification reference:
- this document
-
- Discussion:
- The AUTH-RESP-CODE capability indicates that the server includes
- the AUTH response code with any authentication error caused by a
- problem with the user's credentials.
-
-7. IANA Considerations
-
- IANA has added the AUTH-RESP-CODE capability to the list of POP3
- capabilities (established by RFC 2449 [POP3-EXT]).
-
- IANA has also added the SYS and AUTH response codes to the list of
- POP3 response codes (also established by RFC 2449 [POP3-EXT]).
-
-8. Security Considerations
-
- Section 5, The AUTH Response Code, discusses the security issues
- related to use of the AUTH response code with the USER command.
-
-
-
-
-
-
-
-
-
-
-
-Gellens Standards Track [Page 4]
-
-RFC 3206 The SYS and AUTH POP Response Codes February 2002
-
-
-9. References
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version
- 3", STD 53, RFC 1939, May 1996.
-
- [POP3-EXT] Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension
- Mechanism", RFC 2449, November 1998.
-
-10. Author's Address
-
- Randall Gellens
- QUALCOMM Incorporated
- 5775 Morehouse Drive
- San Diego, CA 92121-2779
- U.S.A.
-
- Phone: +1 858 651 5115
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gellens Standards Track [Page 5]
-
-RFC 3206 The SYS and AUTH POP Response Codes February 2002
-
-
-11. Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gellens Standards Track [Page 6]
-
diff --git a/doc/rfc/rfc3348.txt b/doc/rfc/rfc3348.txt
deleted file mode 100644
index 500871c..0000000
--- a/doc/rfc/rfc3348.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Gahrns
-Request for Comments: 3348 R. Cheng
-Category: Informational Microsoft
- July 2002
-
-
- The Internet Message Action Protocol (IMAP4)
- Child Mailbox Extension
-
-Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard of any kind. Distribution of this
- memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-Abstract
-
- The Internet Message Action Protocol (IMAP4) CHILDREN extension
- provides a mechanism for a client to efficiently determine if a
- particular mailbox has children, without issuing a LIST "" * or a
- LIST "" % for each mailbox.
-
-1. Conventions used in this document
-
- In examples, "C:" and "S:" indicate lines sent by the client and
- server respectively. If such lines are wrapped without a new "C:" or
- "S:" label, then the wrapping is for editorial clarity and is not
- part of the command.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC-2119].
-
-2. Introduction and Overview
-
- Many IMAP4 [RFC-2060] clients present to the user a hierarchical view
- of the mailboxes that a user has access to. Rather than initially
- presenting to the user the entire mailbox hierarchy, it is often
- preferable to show to the user a collapsed outline list of the
- mailbox hierarchy (particularly if there is a large number of
- mailboxes). The user can then expand the collapsed outline hierarchy
- as needed. It is common to include within the collapsed hierarchy a
-
-
-
-
-
-Gahrns, et al. Informational [Page 1]
-
-RFC 3348 IMAP4 Child Mailbox Extension July 2002
-
-
- visual clue (such as a "+") to indicate that there are child
- mailboxes under a particular mailbox. When the visual clue is
- clicked the hierarchy list is expanded to show the child mailboxes.
-
- Several IMAP vendors implemented this proposal, and it is proposed to
- document this behavior and functionality as an Informational RFC.
-
- There is interest in addressing the general extensibility of the IMAP
- LIST command through an IMAP LIST Extension draft. Similar
- functionality to the \HasChildren and \HasNoChildren flags could be
- incorporated into this new LIST Extension. It is proposed that the
- more general LIST Extension draft proceed on the standards track with
- this proposal being relegated to informational status only.
-
- If the functionality of the \HasChildren and \HasNoChildren flags
- were incorporated into a more general LIST extension, this would have
- the advantage that a client could then have the opportunity to
- request whether or not the server should return this information.
- This would be an advantage over the current draft for servers where
- this information is expensive to compute, since the server would only
- need to compute the information when it knew that the client
- requesting the information was able to consume it.
-
-3. Requirements
-
- IMAP4 servers that support this extension MUST list the keyword
- CHILDREN in their CAPABILITY response.
-
- The CHILDREN extension defines two new attributes that MAY be
- returned within a LIST response.
-
- \HasChildren - The presence of this attribute indicates that the
- mailbox has child mailboxes.
-
- Servers SHOULD NOT return \HasChildren if child mailboxes exist, but
- none will be displayed to the current user in a LIST response (as
- should be the case where child mailboxes exist, but a client does not
- have permissions to access them.) In this case, \HasNoChildren
- SHOULD be used.
-
- In many cases, however, a server may not be able to efficiently
- compute whether a user has access to all child mailboxes, or multiple
- users may be accessing the same account and simultaneously changing
- the mailbox hierarchy. As such a client MUST be prepared to accept
- the \HasChildren attribute as a hint. That is, a mailbox MAY be
- flagged with the \HasChildren attribute, but no child mailboxes will
- appear in a subsequent LIST response.
-
-
-
-
-Gahrns, et al. Informational [Page 2]
-
-RFC 3348 IMAP4 Child Mailbox Extension July 2002
-
-
- Example 3.1:
- ============
-
- /*** Consider a server that has the following mailbox hierarchy:
-
- INBOX
- ITEM_1
- ITEM_1A
- ITEM_2
- TOP_SECRET
-
- Where INBOX, ITEM_1 and ITEM_2 are top level mailboxes. ITEM_1A is a
- child mailbox of ITEM_1 and TOP_SECRET is a child mailbox of ITEM_2
- that the currently logged on user does NOT have access to.
-
- Note that in this case, the server is not able to efficiently compute
- access rights to child mailboxes and responds with a \HasChildren
- attribute for mailbox ITEM_2, even though ITEM_2/TOP_SECRET does not
- appear in the list response. ***/
-
- C: A001 LIST "" *
- S: * LIST (\HasNoChildren) "/" INBOX
- S: * LIST (\HasChildren) "/" ITEM_1
- S: * LIST (\HasNoChildren) "/" ITEM_1/ITEM_1A
- S: * LIST (\HasChildren) "/" ITEM_2
- S: A001 OK LIST Completed
-
- \HasNoChildren - The presence of this attribute indicates that the
- mailbox has NO child mailboxes that are accessible to the currently
- authenticated user. If a mailbox has the \Noinferiors attribute, the
- \HasNoChildren attribute is redundant and SHOULD be omitted in the
- LIST response.
-
- In some instances a server that supports the CHILDREN extension MAY
- NOT be able to determine whether a mailbox has children. For example
- it may have difficulty determining whether there are child mailboxes
- when LISTing mailboxes while operating in a particular namespace.
-
- In these cases, a server MAY exclude both the \HasChildren and
- \HasNoChildren attributes in the LIST response. As such, a client
- can not make any assumptions about whether a mailbox has children
- based upon the absence of a single attribute.
-
- It is an error for the server to return both a \HasChildren and a
- \HasNoChildren attribute in a LIST response.
-
-
-
-
-
-
-Gahrns, et al. Informational [Page 3]
-
-RFC 3348 IMAP4 Child Mailbox Extension July 2002
-
-
- It is an error for the server to return both a \HasChildren and a
- \NoInferiors attribute in a LIST response.
-
- Note: the \HasNoChildren attribute should not be confused with the
- IMAP4 [RFC-2060] defined attribute \Noinferiors which indicates that
- no child mailboxes exist now and none can be created in the future.
-
- The \HasChildren and \HasNoChildren attributes might not be returned
- in response to a LSUB response. Many servers maintain a simple
- mailbox subscription list that is not updated when the underlying
- mailbox structure is changed. A client MUST NOT assume that
- hierarchy information will be maintained in the subscription list.
-
- RLIST is a command defined in [RFC-2193] that includes in a LIST
- response mailboxes that are accessible only via referral. That is, a
- client must explicitly issue an RLIST command to see a list of these
- mailboxes. Thus in the case where a mailbox has child mailboxes that
- are available only via referral, the mailboxes would appear as
- \HasNoChildren in response to the LIST command, and \HasChildren in
- response to the RLIST command.
-
-5. Formal Syntax
-
- The following syntax specification uses the augmented Backus-Naur
- Form (BNF) as described in [ABNF].
-
- Two new mailbox attributes are defined as flag_extensions to the
- IMAP4 mailbox_list response:
-
- HasChildren = "\HasChildren"
-
- HasNoChildren = "\HasNoChildren"
-
-6. Security Considerations
-
- This extension provides a client a more efficient means of
- determining whether a particular mailbox has children. If a mailbox
- has children, but the currently authenticated user does not have
- access to any of them, the server SHOULD respond with a
- \HasNoChildren attribute. In many cases, however, a server may not
- be able to efficiently compute whether a user has access to all child
- mailboxes. If such a server responds with a \HasChildren attribute,
- when in fact the currently authenticated user does not have access to
- any child mailboxes, potentially more information is conveyed about
- the mailbox than intended. A server designed with such levels of
- security in mind SHOULD NOT attach the \HasChildren attribute to a
- mailbox unless the server is certain that the user has access to at
- least one of the child mailboxes.
-
-
-
-Gahrns, et al. Informational [Page 4]
-
-RFC 3348 IMAP4 Child Mailbox Extension July 2002
-
-
-7. References
-
- [RFC-2060] Crispin, M., "Internet Message Access Protocol - Version
- 4rev1", RFC 2060, December 1996.
-
- [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC-2234] Crocker, D. and P. Overell, Editors, "Augmented BNF for
- Syntax Specifications: ABNF", RFC 2234, November 1997.
-
- [RFC-2193] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, September
- 1997.
-
-8. Acknowledgments
-
- The authors would like to thank the participants of several IMC Mail
- Connect events for their input when this idea was originally
- presented and refined.
-
-9. Author's Address
-
- Mike Gahrns
- Microsoft
- One Microsoft Way
- Redmond, WA, 98052
- Phone: (425) 936-9833
- EMail: address@hidden
-
- Raymond Cheng
- Microsoft
- One Microsoft Way
- Redmond, WA, 98052
- Phone: (425) 703-4913
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gahrns, et al. Informational [Page 5]
-
-RFC 3348 IMAP4 Child Mailbox Extension July 2002
-
-
-10. Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gahrns, et al. Informational [Page 6]
-
diff --git a/doc/rfc/rfc3431.txt b/doc/rfc/rfc3431.txt
deleted file mode 100644
index a1673f4..0000000
--- a/doc/rfc/rfc3431.txt
+++ /dev/null
@@ -1,452 +0,0 @@
-
-
-
-
-
-
-Network Working Group W. Segmuller
-Request for Comment: 3431 IBM T.J. Watson Research Center
-Category: Standards Track December 2002
-
-
- Sieve Extension: Relational Tests
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-Abstract
-
- This document describes the RELATIONAL extension to the Sieve mail
- filtering language defined in RFC 3028. This extension extends
- existing conditional tests in Sieve to allow relational operators.
- In addition to testing their content, it also allows for testing of
- the number of entities in header and envelope fields.
-
-1 Introduction
-
- Sieve [SIEVE] is a language for filtering e-mail messages at the time
- of final delivery. It is designed to be implementable on either a
- mail client or mail server. It is meant to be extensible, simple,
- and independent of access protocol, mail architecture, and operating
- system. It is suitable for running on a mail server where users may
- not be allowed to execute arbitrary programs, such as on black box
- Internet Messages Access Protocol (IMAP) servers, as it has no
- variables, loops, nor the ability to shell out to external programs.
-
- The RELATIONAL extension provides relational operators on the
- address, envelope, and header tests. This extension also provides a
- way of counting the entities in a message header or address field.
-
- With this extension, the sieve script may now determine if a field is
- greater than or less than a value instead of just equivalent. One
- use is for the x-priority field: move messages with a priority
- greater than 3 to the "work on later" folder. Mail could also be
- sorted by the from address. Those userids that start with 'a'-'m' go
- to one folder, and the rest go to another folder.
-
-
-
-Segmuller Standards Track [Page 1]
-
-RFC 3431 Sieve Extension: Relational Tests December 2002
-
-
- The sieve script can also determine the number of fields in the
- header, or the number of addresses in a recipient field. For
- example: are there more than 5 addresses in the to and cc fields.
-
-2 Conventions used in this document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14, RFC 2119.
-
- Conventions for notations are as in [SIEVE] section 1.1, including
- the use of [KEYWORDS] and "Syntax:" label for the definition of
- action and tagged arguments syntax, and the use of [ABNF].
-
- The capability string associated with extension defined in this
- document is "relational".
-
-3 Comparators
-
- This document does not define any comparators or exempt any
- comparators from the require clause. Any comparator used, other than
- "i;octet" and "i;ascii-casemap", MUST be declared a require clause as
- defined in [SIEVE].
-
- The "i;ascii-numeric" comparator, as defined in [ACAP], MUST be
- supported for any implementation of this extension. The comparator
- "i;ascii-numeric" MUST support at least 32 bit unsigned integers.
-
- Larger integers MAY be supported. Note: the "i;ascii-numeric"
- comparator does not support negative numbers.
-
-4 Match Type
-
- This document defines two new match types. They are the VALUE match
- type and the COUNT match type.
-
- The syntax is:
-
- MATCH-TYPE =/ COUNT / VALUE
-
- COUNT = ":count" relational-match
-
- VALUE = ":value" relational-match
-
- relational-match = DQUOTE ( "gt" / "ge" / "lt"
- / "le" / "eq" / "ne" ) DQUOTE
-
-
-
-
-
-Segmuller Standards Track [Page 2]
-
-RFC 3431 Sieve Extension: Relational Tests December 2002
-
-
-4.1 Match Type Value
-
- The VALUE match type does a relational comparison between strings.
-
- The VALUE match type may be used with any comparator which returns
- sort information.
-
- Leading and trailing white space MUST be removed from the value of
- the message for the comparison. White space is defined as
-
- SP / HTAB / CRLF
-
- A value from the message is considered the left side of the relation.
- A value from the test expression, the key-list for address, envelope,
- and header tests, is the right side of the relation.
-
- If there are multiple values on either side or both sides, the test
- is considered true, if any pair is true.
-
-4.2 Match Type Count
-
- The COUNT match type first determines the number of the specified
- entities in the message and does a relational comparison of the
- number of entities to the values specified in the test expression.
-
- The COUNT match type SHOULD only be used with numeric comparators.
-
- The Address Test counts the number of recipients in the specified
- fields. Group names are ignored.
-
- The Envelope Test counts the number of recipients in the specified
- envelope parts. The envelope "to" will always have only one entry,
- which is the address of the user for whom the sieve script is
- running. There is no way a sieve script can determine if the message
- was actually sent to someone else using this test. The envelope
- "from" will be 0 if the MAIL FROM is blank, or 1 if MAIL FROM is not
- blank.
-
- The Header Test counts the total number of instances of the specified
- fields. This does not count individual addresses in the "to", "cc",
- and other recipient fields.
-
- In all cases, if more than one field name is specified, the counts
- for all specified fields are added together to obtain the number for
- comparison. Thus, specifying ["to", "cc"] in an address COUNT test,
- comparing the total number of "to" and "cc" addresses; if separate
- counts are desired, they must be done in two comparisons, perhaps
- joined by "allof" or "anyof".
-
-
-
-Segmuller Standards Track [Page 3]
-
-RFC 3431 Sieve Extension: Relational Tests December 2002
-
-
-5 Security Considerations
-
- Security considerations are discussed in [SIEVE].
-
- An implementation MUST ensure that the test for envelope "to" only
- reflects the delivery to the current user. It MUST not be possible
- for a user to determine if this message was delivered to someone else
- using this test.
-
-6 Example
-
- Using the message:
-
- received: ...
- received: ...
- subject: example
- to: address@hidden, address@hidden
- cc: address@hidden
-
- The test:
-
- address :count "ge" :comparator "i;ascii-numeric" ["to", "cc"]
- ["3"]
-
- would be true and the test
-
- anyof ( address :count "ge" :comparator "i;ascii-numeric"
- ["to"] ["3"],
- address :count "ge" :comparator "i;ascii-numeric"
- ["cc"] ["3"] )
-
- would be false.
-
- To check the number of received fields in the header, the
- following test may be used:
-
- header :count "ge" :comparator "i;ascii-numeric"
- ["received"] ["3"]
-
- This would return false. But
-
- header :count "ge" :comparator "i;ascii-numeric"
- ["received", "subject"] ["3"]
-
- would return true.
-
-
-
-
-
-
-Segmuller Standards Track [Page 4]
-
-RFC 3431 Sieve Extension: Relational Tests December 2002
-
-
- The test:
-
- header :count "ge" :comparator "i;ascii-numeric"
- ["to", "cc"] ["3"]
-
- will always return false on an RFC 2822 compliant message [RFC2822],
- since a message can have at most one "to" field and at most one "cc"
- field. This test counts the number of fields, not the number of
- addresses.
-
-7 Extended Example
-
- require ["relational", "comparator-i;ascii-numeric"];
-
- if header :value "lt" :comparator "i;ascii-numeric"
- ["x-priority"] ["3"]
- {
- fileinto "Priority";
- }
-
- elseif address :count "gt" :comparator "i;ascii-numeric"
- ["to"] ["5"]
- {
- # everything with more than 5 recipients in the "to" field
- # is considered SPAM
- fileinto "SPAM";
- }
-
- elseif address :value "gt" :all :comparator "i;ascii-casemap"
- ["from"] ["M"]
- {
- fileinto "From N-Z";
- } else {
- fileinto "From A-M";
- }
-
- if allof ( address :count "eq" :comparator "i;ascii-numeric"
- ["to", "cc"] ["1"] ,
- address :all :comparator "i;ascii-casemap"
- ["to", "cc"] ["address@hidden"]
- {
- fileinto "Only me";
- }
-
-
-
-
-
-
-
-
-Segmuller Standards Track [Page 5]
-
-RFC 3431 Sieve Extension: Relational Tests December 2002
-
-
-8 IANA Considerations
-
- The following template specifies the IANA registration of the Sieve
- extension specified in this document:
-
- To: address@hidden
- Subject: Registration of new Sieve extension
-
- Capability name: RELATIONAL
- Capability keyword: relational
- Capability arguments: N/A
- Standards Track/IESG-approved experimental RFC number: this RFC
- Person and email address to contact for further information:
- Wolfgang Segmuller
- IBM T.J. Watson Research Center
- 30 Saw Mill River Rd
- Hawthorne, NY 10532
-
- Email: address@hidden
-
- This information should be added to the list of sieve extensions
- given on http://www.iana.org/assignments/sieve-extensions.
-
-9 References
-
-9.1 Normative References
-
- [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", RFC
- 3028, January 2001.
-
- [Keywords] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications:
- ABNF", RFC 2234, November 1997.
-
- [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
- 2001.
-
-9.2 Non-Normative References
-
- [ACAP] Newman, C. and J. G. Myers, "ACAP -- Application
- Configuration Access Protocol", RFC 2244, November 1997.
-
-
-
-
-
-
-
-
-Segmuller Standards Track [Page 6]
-
-RFC 3431 Sieve Extension: Relational Tests December 2002
-
-
-10 Author's Address
-
- Wolfgang Segmuller
- IBM T.J. Watson Research Center
- 30 Saw Mill River Rd
- Hawthorne, NY 10532
-
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Segmuller Standards Track [Page 7]
-
-RFC 3431 Sieve Extension: Relational Tests December 2002
-
-
-11 Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Segmuller Standards Track [Page 8]
-
-
diff --git a/doc/rfc/rfc3501.txt b/doc/rfc/rfc3501.txt
deleted file mode 100644
index 65498b1..0000000
--- a/doc/rfc/rfc3501.txt
+++ /dev/null
@@ -1,6052 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Crispin
-Request for Comments: 3501 University of Washington
-Obsoletes: 2060 March 2003
-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.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-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 mailboxes (remote
- message folders) in a way that is functionally equivalent to local
- folders. IMAP4rev1 also provides the capability for an offline
- client to resynchronize with the server.
-
- IMAP4rev1 includes operations for creating, deleting, and renaming
- mailboxes, checking for new messages, permanently removing messages,
- setting and clearing flags, RFC 2822 and RFC 2045 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 RFC 2244.
-
- IMAP4rev1 does not specify a means of posting mail; this function is
- handled by a mail transfer protocol such as RFC 2821.
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 1]
-
-RFC 3501 IMAPv4 March 2003
-
-
-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
- 1.3. Special Notes to Implementors ........................... 5
- 2. Protocol Overview ....................................... 6
- 2.1. Link Level .............................................. 6
- 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 ...................................... 8
- 2.3.1. Message Numbers ......................................... 8
- 2.3.1.1. Unique Identifier (UID) Message Attribute ....... 8
- 2.3.1.2. Message Sequence Number Message Attribute ....... 10
- 2.3.2. Flags Message Attribute ................................. 11
- 2.3.3. Internal Date Message Attribute ......................... 12
- 2.3.4. [RFC-2822] Size Message Attribute ....................... 12
- 2.3.5. Envelope Structure Message Attribute .................... 12
- 2.3.6. Body Structure Message Attribute ........................ 12
- 2.4. Message Texts ........................................... 13
- 3. State and Flow Diagram .................................. 13
- 3.1. Not Authenticated State ................................. 13
- 3.2. Authenticated State ..................................... 13
- 3.3. Selected State .......................................... 13
- 3.4. Logout State ............................................ 14
- 4. Data Formats ............................................ 16
- 4.1. Atom .................................................... 16
- 4.2. Number .................................................. 16
- 4.3. String .................................................. 16
- 4.3.1. 8-bit and Binary Strings ................................ 17
- 4.4. Parenthesized List ...................................... 17
- 4.5. NIL ..................................................... 17
- 5. Operational Considerations .............................. 18
- 5.1. Mailbox Naming .......................................... 18
- 5.1.1. Mailbox Hierarchy Naming ................................ 19
- 5.1.2. Mailbox Namespace Naming Convention ..................... 19
- 5.1.3. Mailbox International Naming Convention ................. 19
- 5.2. Mailbox Size and Message Status Updates ................. 21
- 5.3. Response when no Command in Progress .................... 21
- 5.4. Autologout Timer ........................................ 22
- 5.5. Multiple Commands in Progress ........................... 22
- 6. Client Commands ........................................ 23
- 6.1. Client Commands - Any State ............................ 24
- 6.1.1. CAPABILITY Command ..................................... 24
- 6.1.2. NOOP Command ........................................... 25
- 6.1.3. LOGOUT Command ......................................... 26
-
-
-
-Crispin Standards Track [Page 2]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 6.2. Client Commands - Not Authenticated State .............. 26
- 6.2.1. STARTTLS Command ....................................... 27
- 6.2.2. AUTHENTICATE Command ................................... 28
- 6.2.3. LOGIN Command .......................................... 30
- 6.3. Client Commands - Authenticated State .................. 31
- 6.3.1. SELECT Command ......................................... 32
- 6.3.2. EXAMINE Command ........................................ 34
- 6.3.3. CREATE Command ......................................... 34
- 6.3.4. DELETE Command ......................................... 35
- 6.3.5. RENAME Command ......................................... 37
- 6.3.6. SUBSCRIBE Command ...................................... 39
- 6.3.7. UNSUBSCRIBE Command .................................... 39
- 6.3.8. LIST Command ........................................... 40
- 6.3.9. LSUB Command ........................................... 43
- 6.3.10. STATUS Command ......................................... 44
- 6.3.11. APPEND Command ......................................... 46
- 6.4. Client Commands - Selected State ....................... 47
- 6.4.1. CHECK Command .......................................... 47
- 6.4.2. CLOSE Command .......................................... 48
- 6.4.3. EXPUNGE Command ........................................ 49
- 6.4.4. SEARCH Command ......................................... 49
- 6.4.5. FETCH Command .......................................... 54
- 6.4.6. STORE Command .......................................... 58
- 6.4.7. COPY Command ........................................... 59
- 6.4.8. UID Command ............................................ 60
- 6.5. Client Commands - Experimental/Expansion ............... 62
- 6.5.1. X<atom> Command ........................................ 62
- 7. Server Responses ....................................... 62
- 7.1. Server Responses - Status Responses .................... 63
- 7.1.1. OK Response ............................................ 65
- 7.1.2. NO Response ............................................ 66
- 7.1.3. BAD Response ........................................... 66
- 7.1.4. PREAUTH Response ....................................... 67
- 7.1.5. BYE Response ........................................... 67
- 7.2. Server Responses - Server and Mailbox Status ........... 68
- 7.2.1. CAPABILITY Response .................................... 68
- 7.2.2. LIST Response .......................................... 69
- 7.2.3. LSUB Response .......................................... 70
- 7.2.4 STATUS Response ........................................ 70
- 7.2.5. SEARCH Response ........................................ 71
- 7.2.6. FLAGS Response ......................................... 71
- 7.3. Server Responses - Mailbox Size ........................ 71
- 7.3.1. EXISTS Response ........................................ 71
- 7.3.2. RECENT Response ........................................ 72
- 7.4. Server Responses - Message Status ...................... 72
- 7.4.1. EXPUNGE Response ....................................... 72
- 7.4.2. FETCH Response ......................................... 73
- 7.5. Server Responses - Command Continuation Request ........ 79
-
-
-
-Crispin Standards Track [Page 3]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 8. Sample IMAP4rev1 connection ............................ 80
- 9. Formal Syntax .......................................... 81
- 10. Author's Note .......................................... 92
- 11. Security Considerations ................................ 92
- 11.1. STARTTLS Security Considerations ....................... 92
- 11.2. Other Security Considerations .......................... 93
- 12. IANA Considerations .................................... 94
- Appendices ..................................................... 95
- A. References ............................................. 95
- B. Changes from RFC 2060 .................................. 97
- C. Key Word Index ......................................... 103
- Author's Address ............................................... 107
- Full Copyright Statement ....................................... 108
-
-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
-
- "Conventions" are basic principles or procedures. Document
- conventions are noted in this section.
-
- In examples, "C:" and "S:" indicate lines sent by the client and
- server respectively.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
- be interpreted as described in [KEYWORDS].
-
- The word "can" (not "may") is used to refer to a possible
- circumstance or situation, as opposed to an optional facility of the
- protocol.
-
-
-
-Crispin Standards Track [Page 4]
-
-RFC 3501 IMAPv4 March 2003
-
-
- "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.
-
- There are several protocol conventions in IMAP. These refer to
- aspects of the specification which are not strictly part of the IMAP
- protocol, but reflect generally-accepted practice. Implementations
- need to be aware of these conventions, and avoid conflicts whether or
- not they implement the convention. For example, "&" may not be used
- as a hierarchy delimiter since it conflicts with the Mailbox
- International Naming Convention, and other uses of "&" in mailbox
- names are impacted as well.
-
-1.3. Special Notes to Implementors
-
- Implementors of the IMAP protocol are strongly encouraged to read the
- IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in
- conjunction with this document, to help understand the intricacies of
- this protocol and how best to build an interoperable product.
-
- IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
- unpublished IMAP2bis protocols. IMAP4rev1 is largely compatible with
- the IMAP4 protocol described in RFC 1730; the exception being in
- certain facilities added in RFC 1730 that proved problematic and were
- subsequently removed. In the course of the evolution of IMAP4rev1,
- some aspects in the earlier protocols have become obsolete. Obsolete
- commands, responses, and data formats which an IMAP4rev1
- implementation can encounter when used with an earlier implementation
- are described in [IMAP-OBSOLETE].
-
- 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)
-
-
-
-
-Crispin Standards Track [Page 5]
-
-RFC 3501 IMAPv4 March 2003
-
-
- variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
- primarily of historical interest.
-
- IMAP was originally developed for the older [RFC-822] standard, and
- as a consequence several fetch items in IMAP incorporate "RFC822" in
- their name. With the exception of RFC822.SIZE, there are more modern
- replacements; for example, the modern version of RFC822.HEADER is
- BODY.PEEK[HEADER]. In all cases, "RFC822" should be interpreted as a
- reference to the updated [RFC-2822] standard.
-
-2. Protocol Overview
-
-2.1. Link Level
-
- The IMAP4rev1 protocol assumes a reliable data stream such as that
- provided by TCP. When TCP is used, an IMAP4rev1 server listens on
- port 143.
-
-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.
-
- Clients MUST follow the syntax outlined in this specification
- strictly. It is a syntax error to send a command with missing or
- extraneous spaces or arguments.
-
- 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
-
-
-
-
-Crispin Standards Track [Page 6]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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 a 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.
-
-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 a protocol error such as
- unrecognized command or command syntax error).
-
- Servers SHOULD enforce the syntax outlined in this specification
- strictly. Any client command with a protocol syntax error, including
- (but not limited to) missing or extraneous spaces or arguments,
-
-
-
-Crispin Standards Track [Page 7]
-
-RFC 3501 IMAPv4 March 2003
-
-
- SHOULD be rejected, and the client given a BAD server completion
- response.
-
- 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 can 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 or 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
- that MUST NOT refer to any other message in the mailbox or any
- subsequent mailbox with the same name forever. 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.
-
- The unique identifier of a message MUST NOT change during the
- session, and SHOULD NOT change between sessions. Any change of
- unique identifiers between sessions MUST be detectable using the
- UIDVALIDITY mechanism discussed below. Persistent unique identifiers
- are required for 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].
-
-
-
-
-
-Crispin Standards Track [Page 8]
-
-RFC 3501 IMAPv4 March 2003
-
-
- Associated with every mailbox are two values which aid in unique
- identifier handling: the next unique identifier value and the unique
- identifier validity value.
-
- The next unique identifier value is the predicted value that will be
- assigned to a new message in the mailbox. Unless the unique
- identifier validity also changes (see below), the next unique
- identifier value MUST have the following two characteristics. First,
- the next unique identifier value MUST NOT change unless new messages
- are added to the mailbox; and second, the next unique identifier
- value MUST change whenever new messages are added to the mailbox,
- even if those new messages are subsequently expunged.
-
- Note: The next unique identifier value is intended to
- provide a means for a client to determine whether any
- messages have been delivered to the mailbox since the
- previous time it checked this value. It is not intended to
- provide any guarantee that any message will have this
- unique identifier. A client can only assume, at the time
- that it obtains the next unique identifier value, that
- messages arriving after that time will have a UID greater
- than or equal to that value.
-
- The unique identifier validity value is sent in a UIDVALIDITY
- response code in an OK untagged response at mailbox selection time.
- If unique identifiers from an earlier session fail to persist in this
- session, the unique identifier validity value MUST be greater than
- the one used in the earlier session.
-
- Note: Ideally, unique identifiers SHOULD persist at all
- times. Although this specification recognizes that failure
- to persist can be unavoidable in certain server
- environments, it STRONGLY ENCOURAGES message store
- implementation techniques that avoid this problem. For
- example:
-
- 1) 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 identifiers are no longer strictly
- ascending as a result of the re-ordering.
-
- 2) If the message store has no mechanism to store unique
- identifiers, it must regenerate unique identifiers at
- each session, and each session must have a unique
- UIDVALIDITY value.
-
-
-
-
-Crispin Standards Track [Page 9]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 3) If the mailbox is deleted and a new mailbox with the
- same name is created at a later date, the server must
- either keep track of unique identifiers from the
- previous instance of the mailbox, or it must assign a
- new UIDVALIDITY value to the new instance of the
- mailbox. A good UIDVALIDITY value to use in this case
- 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.
-
- 4) The combination of mailbox name, UIDVALIDITY, and UID
- must refer to a single immutable message on that server
- forever. In particular, the internal date, [RFC-2822]
- size, envelope, body structure, and message texts
- (RFC822, RFC822.HEADER, RFC822.TEXT, and all BODY[...]
- fetch data items) must never change. This does not
- include message numbers, nor does it include attributes
- that can be set by a STORE command (e.g., FLAGS).
-
-
-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. The number of messages in the mailbox is also
- 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 "11 EXISTS" 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.
-
-
-
-
-Crispin Standards Track [Page 10]
-
-RFC 3501 IMAPv4 March 2003
-
-
-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 can 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).
-
- \Recent
- Message is "recently" arrived in this mailbox. This session
- is the first session to have been notified about this
- message; if the session is read-write, 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-arrived 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).
-
-
-
-
-Crispin Standards Track [Page 11]
-
-RFC 3501 IMAPv4 March 2003
-
-
- A flag can 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, concurrent and 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 or APPEND 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-2822] 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.
-
-2.3.4. [RFC-2822] Size Message Attribute
-
- The number of octets in the message, as expressed in [RFC-2822]
- format.
-
-2.3.5. Envelope Structure Message Attribute
-
- A parsed representation of the [RFC-2822] header of the message.
- Note that the IMAP Envelope structure is not the same as an
- [SMTP] envelope.
-
-2.3.6. Body Structure Message Attribute
-
- A parsed representation of the [MIME-IMB] body structure
- information of the message.
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 12]
-
-RFC 3501 IMAPv4 March 2003
-
-
-2.4. Message Texts
-
- In addition to being able to fetch the full [RFC-2822] text of a
- message, IMAP4rev1 permits the fetching of portions of the full
- message text. Specifically, it is possible to fetch the
- [RFC-2822] message header, [RFC-2822] message body, a [MIME-IMB]
- body part, or a [MIME-IMB] header.
-
-3. State and Flow Diagram
-
- Once the connection between client and server is established, an
- IMAP4rev1 connection is in one of four states. The initial
- state is identified in the server greeting. Most commands are
- only valid in certain states. It is a protocol error for the
- client to attempt a command while the connection is in an
- inappropriate state, and the server will respond with a BAD or
- NO (depending upon server implementation) command completion
- result.
-
-3.1. Not Authenticated State
-
- In the not 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 the 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, after an error in
- selecting a mailbox, or after a successful CLOSE command.
-
-3.3. Selected State
-
- In a selected state, a mailbox has been selected to access.
- This state is entered when a mailbox has been successfully
- selected.
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 13]
-
-RFC 3501 IMAPv4 March 2003
-
-
-3.4. Logout State
-
- In the logout state, the connection is being terminated. This
- state can be entered as a result of a client request (via the
- LOGOUT command) or by unilateral action on the part of either
- the client or server.
-
- If the client requests the logout state, the server MUST send an
- untagged BYE response and a tagged OK response to the LOGOUT
- command before the server closes the connection; and the client
- MUST read the tagged OK response to the LOGOUT command before
- the client closes the connection.
-
- A server MUST NOT unilaterally close the connection without
- sending an untagged BYE response that contains the reason for
- having done so. A client SHOULD NOT unilaterally close the
- connection, and instead SHOULD issue a LOGOUT command. If the
- server detects that the client has unilaterally closed the
- connection, the server MAY omit the untagged BYE response and
- simply close its connection.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 14]
-
-RFC 3501 IMAPv4 March 2003
-
-
- +----------------------+
- |connection established|
- +----------------------+
- ||
- \/
- +--------------------------------------+
- | server greeting |
- +--------------------------------------+
- || (1) || (2) || (3)
- \/ || ||
- +-----------------+ || ||
- |Not Authenticated| || ||
- +-----------------+ || ||
- || (7) || (4) || ||
- || \/ \/ ||
- || +----------------+ ||
- || | Authenticated |<=++ ||
- || +----------------+ || ||
- || || (7) || (5) || (6) ||
- || || \/ || ||
- || || +--------+ || ||
- || || |Selected|==++ ||
- || || +--------+ ||
- || || || (7) ||
- \/ \/ \/ \/
- +--------------------------------------+
- | Logout |
- +--------------------------------------+
- ||
- \/
- +-------------------------------+
- |both sides close the connection|
- +-------------------------------+
-
- (1) connection without pre-authentication (OK greeting)
- (2) pre-authenticated connection (PREAUTH greeting)
- (3) rejected connection (BYE greeting)
- (4) successful LOGIN or AUTHENTICATE command
- (5) successful SELECT or EXAMINE command
- (6) CLOSE command, or failed SELECT or EXAMINE command
- (7) LOGOUT command, server shutdown, or connection closed
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 15]
-
-RFC 3501 IMAPv4 March 2003
-
-
-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. Note that a particular data item
- may take more than one form; for example, a data item defined as
- using "astring" syntax may be either an atom or a string.
-
-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: either literal or 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
- which may be used.
-
- 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.
-
-
-
-
-
-
-Crispin Standards Track [Page 16]
-
-RFC 3501 IMAPv4 March 2003
-
-
-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.
-
- 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 form "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 ().
-
- Note: NIL is never used for any data item which takes the
- form of an atom. For example, a mailbox name of "NIL" is a
- mailbox named NIL as opposed to a non-existent mailbox
- name. This is because mailbox uses "astring" syntax which
- is an atom or a string. Conversely, an addr-name of NIL is
- a non-existent personal name, because addr-name uses
- "nstring" syntax which is NIL or a string, but never an
- atom.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 17]
-
-RFC 3501 IMAPv4 March 2003
-
-
-5. Operational Considerations
-
- The following rules are listed here to ensure that all IMAP4rev1
- implementations interoperate properly.
-
-5.1. Mailbox Naming
-
- Mailbox names are 7-bit. Client implementations MUST NOT attempt to
- create 8-bit mailbox names, and SHOULD interpret any 8-bit mailbox
- names returned by LIST or LSUB as UTF-8. Server implementations
- SHOULD prohibit the creation of 8-bit mailbox names, and SHOULD NOT
- return 8-bit mailbox names in LIST or LSUB. See section 5.1.3 for
- more information on how to represent non-ASCII mailbox names.
-
- Note: 8-bit mailbox names were undefined in earlier
- versions of this protocol. Some sites used a local 8-bit
- character set to represent non-ASCII mailbox names. Such
- usage is not interoperable, and is now formally deprecated.
-
- The case-insensitive mailbox name INBOX is a special name reserved to
- mean "the primary mailbox for this user on this server". The
- interpretation of all other names is implementation-dependent.
-
- In particular, this specification takes no position on case
- sensitivity in non-INBOX mailbox names. Some server implementations
- are fully case-sensitive; others preserve case of a newly-created
- name but otherwise are case-insensitive; and yet others coerce names
- to a particular case. Client implementations MUST interact with any
- of these. If a server implementation interprets non-INBOX mailbox
- names as case-insensitive, it MUST treat names using the
- international naming convention specially as described in section
- 5.1.3.
-
- There are certain client considerations when creating a new mailbox
- name:
-
- 1) Any character which is one of the atom-specials (see the Formal
- Syntax) will require that the mailbox name be represented as a
- quoted string or literal.
-
- 2) CTL and other non-graphic characters are difficult to represent
- in a user interface and are best avoided.
-
- 3) Although the list-wildcard characters ("%" and "*") are valid
- in a mailbox name, it is difficult to use such mailbox names
- with the LIST and LSUB commands due to the conflict with
- wildcard interpretation.
-
-
-
-
-Crispin Standards Track [Page 18]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 4) Usually, a character (determined by the server implementation)
- is reserved to delimit levels of hierarchy.
-
- 5) Two characters, "#" and "&", have meanings by convention, and
- should be avoided except when used in that convention.
-
-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.
-
- 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 a mailbox
- name of "#news.comp.mail.misc", and the name
- "comp.mail.misc" can refer to a different object (e.g., a
- user's private mailbox).
-
-5.1.3. Mailbox International Naming Convention
-
- By convention, international mailbox names in IMAP4rev1 are specified
- using a modified version of the UTF-7 encoding described in [UTF-7].
- Modified UTF-7 may also be usable in servers that implement an
- earlier version of this protocol.
-
- 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 and 0x7f-0xff) 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.
-
-
-
-
-
-
-Crispin Standards Track [Page 19]
-
-RFC 3501 IMAPv4 March 2003
-
-
- "&" is used to shift to modified BASE64 and "-" to shift back to
- US-ASCII. There is no implicit shift from BASE64 to US-ASCII, and
- null shifts ("-&" while in BASE64; note that "&-" while in US-ASCII
- means "&") are not permitted. However, all names start in US-ASCII,
- and MUST end in US-ASCII; that is, a name that ends with a non-ASCII
- ISO-10646 character MUST end with a "-").
-
- 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 characters can be
- represented in encoded form.
-
- Although modified UTF-7 is a convention, it establishes certain
- requirements on server handling of any mailbox name with an
- embedded "&" character. In particular, server implementations
- MUST preserve the exact form of the modified BASE64 portion of a
- modified UTF-7 name and treat that text as case-sensitive, even if
- names are otherwise case-insensitive or case-folded.
-
- Server implementations SHOULD verify that any mailbox name with an
- embedded "&" character, used as an argument to CREATE, is: in the
- correctly modified UTF-7 syntax, has no superfluous shifts, and
- has no encoding in modified BASE64 of any printing US-ASCII
- character which can represent itself. However, client
- implementations MUST NOT depend upon the server doing this, and
- SHOULD NOT attempt to create a mailbox name with an embedded "&"
- character unless it complies with the modified UTF-7 syntax.
-
- Server implementations which export a mail store that does not
- follow the modified UTF-7 convention MUST convert to modified
- UTF-7 any mailbox name that contains either non-ASCII characters
- or the "&" character.
-
-
-
-
-Crispin Standards Track [Page 20]
-
-RFC 3501 IMAPv4 March 2003
-
-
- For example, here is a mailbox name which mixes English,
- Chinese, and Japanese text:
- ~peter/mail/&U,BTFw-/&ZeVnLIqe-
-
- For example, the string "&Jjo!" is not a valid mailbox
- name because it does not contain a shift to US-ASCII
- before the "!". The correct form is "&Jjo-!". The
- string "&U,BTFw-&ZeVnLIqe-" is not permitted because it
- contains a superfluous shift. The correct form is
- "&U,BTF2XlZyyKng-".
-
-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 message
- delivery), change the flags of the messages 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. In particular,
- it is NOT permitted to send an EXISTS response that would reduce the
- number of messages in the mailbox; only the EXPUNGE response can do
- this.
-
- 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 the
- initial mailbox selection will return the size of the mailbox.
-
-5.3. Response when no Command in Progress
-
- Server implementations are permitted to send an untagged response
- (except for EXPUNGE) while there is no command in progress. Server
- implementations that send such responses MUST deal with flow control
- considerations. Specifically, they MUST either (1) verify that the
- size of the data does not exceed the underlying transport's available
- window size, or (2) use non-blocking writes.
-
-
-
-
-
-
-
-Crispin Standards Track [Page 21]
-
-RFC 3501 IMAPv4 March 2003
-
-
-5.4. Autologout Timer
-
- If a server has an inactivity autologout timer, the duration of that
- timer MUST be at least 30 minutes. The receipt of ANY command from
- the client during that interval SHOULD suffice to reset the
- autologout timer.
-
-5.5. Multiple Commands in Progress
-
- The client 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, e.g., 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 the completion result response before sending a command
- with message sequence numbers.
-
- Note: UID FETCH, UID STORE, and UID SEARCH are different
- commands from FETCH, STORE, and SEARCH. If the client
- sends a UID command, it must wait for a completion result
- response before sending a command with message sequence
- numbers.
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 22]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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
-
- UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting
- command sequence, depending upon whether or not the second UID
- SEARCH contains message sequence numbers.
-
-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
- 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.
-
- The state of a connection is only changed by successful commands
- which are documented as changing state. A rejected command (BAD
- response) never changes the state of the connection or of the
- selected mailbox. A failed command (NO response) generally does not
- change the state of the connection or of the selected mailbox; the
- exception being the SELECT and EXAMINE commands.
-
-
-
-Crispin Standards Track [Page 23]
-
-RFC 3501 IMAPv4 March 2003
-
-
-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.
-
- 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.
-
- Client and server implementations MUST implement the STARTTLS,
- LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
- capabilities. See the Security Considerations section for
- important information.
-
- See the section entitled "Client Commands -
- Experimental/Expansion" for information about the form of site or
- implementation-specific capabilities.
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 24]
-
-RFC 3501 IMAPv4 March 2003
-
-
- Example: C: abcd CAPABILITY
- S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
- LOGINDISABLED
- S: abcd OK CAPABILITY completed
- C: efgh STARTTLS
- S: efgh OK STARTLS completed
- <TLS negotiation, further commands are under [TLS] layer>
- C: ijkl CAPABILITY
- S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN
- S: ijkl 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 (this is the
- preferred method to do this). 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 25]
-
-RFC 3501 IMAPv4 March 2003
-
-
-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 - Not Authenticated State
-
- In the not authenticated state, the AUTHENTICATE or LOGIN command
- establishes authentication and enters the authenticated state. The
- AUTHENTICATE command provides a general mechanism for a variety of
- authentication techniques, privacy protection, and integrity
- checking; whereas the LOGIN command uses a traditional user name and
- plaintext password pair and has no means of establishing privacy
- protection or integrity checking.
-
- The STARTTLS command is an alternate form of establishing session
- privacy protection and integrity checking, but does not establish
- authentication or enter the authenticated state.
-
- Server implementations MAY allow access to certain mailboxes without
- establishing authentication. This can be done by means of the
- ANONYMOUS [SASL] authenticator described in [ANONYMOUS]. An older
- convention is a LOGIN command using the userid "anonymous"; in this
- case, a password is required although the server may choose to accept
- any password. The restrictions placed on anonymous users are
- implementation-dependent.
-
- Once authenticated (including as anonymous), it is not possible to
- re-enter not authenticated state.
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 26]
-
-RFC 3501 IMAPv4 March 2003
-
-
- In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
- the following commands are valid in the not authenticated state:
- STARTTLS, AUTHENTICATE and LOGIN. See the Security Considerations
- section for important information about these commands.
-
-6.2.1. STARTTLS Command
-
- Arguments: none
-
- Responses: no specific response for this command
-
- Result: OK - starttls completed, begin TLS negotiation
- BAD - command unknown or arguments invalid
-
- A [TLS] negotiation begins immediately after the CRLF at the end
- of the tagged OK response from the server. Once a client issues a
- STARTTLS command, it MUST NOT issue further commands until a
- server response is seen and the [TLS] negotiation is complete.
-
- The server remains in the non-authenticated state, even if client
- credentials are supplied during the [TLS] negotiation. This does
- not preclude an authentication mechanism such as EXTERNAL (defined
- in [SASL]) from using client identity determined by the [TLS]
- negotiation.
-
- Once [TLS] has been started, the client MUST discard cached
- information about server capabilities and SHOULD re-issue the
- CAPABILITY command. This is necessary to protect against man-in-
- the-middle attacks which alter the capabilities list prior to
- STARTTLS. The server MAY advertise different capabilities after
- STARTTLS.
-
- Example: C: a001 CAPABILITY
- S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
- S: a001 OK CAPABILITY completed
- C: a002 STARTTLS
- S: a002 OK Begin TLS negotiation now
- <TLS negotiation, further commands are under [TLS] layer>
- C: a003 CAPABILITY
- S: * CAPABILITY IMAP4rev1 AUTH=PLAIN
- S: a003 OK CAPABILITY completed
- C: a004 LOGIN joe password
- S: a004 OK LOGIN completed
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 27]
-
-RFC 3501 IMAPv4 March 2003
-
-
-6.2.2. 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 a [SASL] authentication
- mechanism 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 security layer 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 AUTHENTICATE command does not support the optional "initial
- response" feature of [SASL]. Section 5.1 of [SASL] specifies how
- to handle an authentication mechanism which uses an initial
- response.
-
- The service name specified by this protocol's profile of [SASL] is
- "imap".
-
- The authentication protocol exchange consists of a series of
- server challenges and client responses 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 response consists of a
- single line consisting of a BASE64 encoded string. If the client
- wishes to cancel an authentication exchange, it issues a line
- consisting of a single "*". If the server receives such a
- response, it MUST reject the AUTHENTICATE command by sending a
- tagged BAD response.
-
- If a security layer is negotiated through the [SASL]
- authentication exchange, it takes effect immediately following the
- CRLF that concludes the authentication exchange for the client,
- and the CRLF of the tagged OK response for the server.
-
- While client and server implementations MUST implement the
- AUTHENTICATE command itself, it is not required to implement any
- authentication mechanisms other than the PLAIN mechanism described
-
-
-
-Crispin Standards Track [Page 28]
-
-RFC 3501 IMAPv4 March 2003
-
-
- in [IMAP-TLS]. Also, an authentication mechanism is not required
- to support any security layers.
-
- Note: a server implementation MUST implement a
- configuration in which it does NOT permit any plaintext
- password mechanisms, unless either the STARTTLS command
- has been negotiated or some other mechanism that
- protects the session from password snooping has been
- provided. Server sites SHOULD NOT use any configuration
- which permits a plaintext password mechanism without
- such a protection mechanism against password snooping.
- Client and server implementations SHOULD implement
- additional [SASL] mechanisms that do not use plaintext
- passwords, such the GSSAPI mechanism described in [SASL]
- and/or the [DIGEST-MD5] mechanism.
-
- Servers and clients can support multiple authentication
- mechanisms. The server SHOULD list its supported authentication
- mechanisms in the response to the CAPABILITY command so that the
- client knows which authentication mechanisms to use.
-
- A server MAY include a CAPABILITY response code in the tagged OK
- response of a successful AUTHENTICATE command in order to send
- capabilities automatically. It is unnecessary for a client to
- send a separate CAPABILITY command if it recognizes these
- automatic capabilities. This should only be done if a security
- layer was not negotiated by the AUTHENTICATE command, because the
- tagged OK response as part of an AUTHENTICATE command is not
- protected by encryption/integrity checking. [SASL] requires the
- client to re-issue a CAPABILITY command in this case.
-
- If an AUTHENTICATE command fails with a NO response, the client
- MAY try another authentication mechanism by issuing another
- AUTHENTICATE command. It MAY also attempt to authenticate by
- using the LOGIN command (see section 6.2.3 for more detail). In
- other words, the client MAY request authentication types in
- decreasing order of preference, with the LOGIN command as a last
- resort.
-
- The authorization identity passed from the client to the server
- during the authentication exchange is interpreted by the server as
- the user name whose privileges the client is requesting.
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 29]
-
-RFC 3501 IMAPv4 March 2003
-
-
- Example: S: * OK IMAP4rev1 Server
- C: A001 AUTHENTICATE GSSAPI
- S: +
- C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw
- MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0
- b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW
- Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA
- cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX
- AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y
- C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb
- I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi
- vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL
- pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n
- FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE
- NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx
- O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB
- vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg==
- S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC
- AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0
- uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg==
- C:
- S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe
- ceP2CWY0SR0fAQAgAAQEBAQ=
- C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP
- wkhbfa2QteAQAgAG1yYwE=
- S: A001 OK GSSAPI authentication successful
-
- Note: The line breaks within server challenges and client
- responses are for editorial clarity and are not in real
- authenticators.
-
-
-6.2.3. 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.
-
-
-
-
-
-
-Crispin Standards Track [Page 30]
-
-RFC 3501 IMAPv4 March 2003
-
-
- A server MAY include a CAPABILITY response code in the tagged OK
- response to a successful LOGIN command in order to send
- capabilities automatically. It is unnecessary for a client to
- send a separate CAPABILITY command if it recognizes these
- automatic capabilities.
-
- Example: C: a001 LOGIN SMITH SESAME
- S: a001 OK LOGIN completed
-
- Note: Use of the LOGIN command over an insecure network
- (such as the Internet) is a security risk, because anyone
- monitoring network traffic can obtain plaintext passwords.
- The LOGIN command SHOULD NOT be used except as a last
- resort, and it is recommended that client implementations
- have a means to disable any automatic use of the LOGIN
- command.
-
- Unless either the STARTTLS command has been negotiated or
- some other mechanism that protects the session from
- password snooping has been provided, a server
- implementation MUST implement a configuration in which it
- advertises the LOGINDISABLED capability and does NOT permit
- the LOGIN command. Server sites SHOULD NOT use any
- configuration which permits the LOGIN command without such
- a protection mechanism against password snooping. A client
- implementation MUST NOT send a LOGIN command if the
- LOGINDISABLED capability is advertised.
-
-6.3. Client Commands - Authenticated State
-
- In the 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 the
- selected state.
-
- In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
- the following commands are valid in the authenticated state: SELECT,
- EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
- STATUS, and APPEND.
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 31]
-
-RFC 3501 IMAPv4 March 2003
-
-
-6.3.1. SELECT Command
-
- Arguments: mailbox name
-
- Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT
- REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS,
- UIDNEXT, UIDVALIDITY
-
- 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.
- Note that earlier versions of this protocol only required the
- FLAGS, EXISTS, and RECENT untagged data; consequently, client
- implementations SHOULD implement default behavior for missing data
- as discussed with the individual item.
-
- 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 [UNSEEN <n>]
- The message sequence number of the first unseen
- message in the mailbox. If this is missing, the
- client can not make any assumptions about the first
- unseen message in the mailbox, and needs to issue a
- SEARCH command if it wants to find it.
-
- OK [PERMANENTFLAGS (<list of flags>)]
- A list of message flags that the client can change
- permanently. If this is missing, the client should
- assume that all flags can be changed permanently.
-
- OK [UIDNEXT <n>]
- The next unique identifier value. Refer to section
- 2.3.1.1 for more information. If this is missing,
- the client can not make any assumptions about the
- next unique identifier value.
-
-
-
-Crispin Standards Track [Page 32]
-
-RFC 3501 IMAPv4 March 2003
-
-
- OK [UIDVALIDITY <n>]
- The unique identifier validity value. Refer to
- section 2.3.1.1 for more information. If this is
- missing, the server does not support unique
- identifiers.
-
- 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.
-
- 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: * OK [UIDNEXT 4392] Predicted next UID
- S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
- S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
- S: A142 OK [READ-WRITE] SELECT completed
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 33]
-
-RFC 3501 IMAPv4 March 2003
-
-
-6.3.2. EXAMINE Command
-
- Arguments: mailbox name
-
- Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT
- REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS,
- UIDNEXT, UIDVALIDITY
-
- 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; in particular, EXAMINE MUST NOT
- cause messages to lose the \Recent flag.
-
- 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: * OK [UIDNEXT 4392] Predicted next UID
- 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.
-
-
-
-Crispin Standards Track [Page 34]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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
- the declaration. In any case, the name created is without the
- trailing hierarchy delimiter.
-
- 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 be successfully
- completed. 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.
-
- 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
-
-
-
-
-
-
-
-Crispin Standards Track [Page 35]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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.
-
- 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
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 36]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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
- 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".
-
- If the server's hierarchy separator character appears in the name,
- the server SHOULD create any superior hierarchical names that are
- needed for the RENAME command to complete successfully. In other
- words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a
- server in which "/" is the hierarchy separator character SHOULD
- create baz/ and baz/rag/ if they do not already exist.
-
-
-
-
-
-Crispin Standards Track [Page 37]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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
-
- 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
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 38]
-
-RFC 3501 IMAPv4 March 2003
-
-
-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 a server site can
- choose to 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
-
-
-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
-
-
-
-Crispin Standards Track [Page 39]
-
-RFC 3501 IMAPv4 March 2003
-
-
-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 the \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 the context in which the mailbox
- name is interpreted.
-
- 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 the empty
- string if the reference is non-rooted or is an empty string. In
- all cases, a hierarchy delimiter (or NIL if there is no hierarchy)
- is returned. This permits a client to get the hierarchy delimiter
- (or find out that the mailbox names are flat) even when no
- mailboxes by that name currently exist.
-
- The reference and mailbox name arguments are interpreted into a
- canonical form that represents an unambiguous left-to-right
- hierarchy. The returned mailbox names will be in the interpreted
- form.
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 40]
-
-RFC 3501 IMAPv4 March 2003
-
-
- Note: The interpretation of the reference argument is
- implementation-defined. It depends upon whether the
- server implementation has a concept of the "current
- working directory" and leading "break out characters",
- which override the current working directory.
-
- For example, on a server which exports a UNIX or NT
- filesystem, the reference argument contains the current
- working directory, and the mailbox name argument would
- contain the name as interpreted in the current working
- directory.
-
- If a server implementation has no concept of break out
- characters, the canonical form is normally the reference
- name appended with the mailbox name. Note that if the
- server implements the namespace convention (section
- 5.1.2), "#" is a break out character and must be treated
- as such.
-
- If the reference argument is not a level of mailbox
- hierarchy (that is, it is a \NoInferiors name), and/or
- the reference argument does not end with the hierarchy
- delimiter, it is implementation-dependent how this is
- interpreted. For example, a reference of "foo/bar" and
- mailbox name of "rag/baz" could be interpreted as
- "foo/bar/rag/baz", "foo/barrag/baz", or "foo/rag/baz".
- A client SHOULD NOT use such a reference argument except
- at the explicit request of the user. A hierarchical
- browser MUST NOT make any assumptions about server
- interpretation of the reference unless the reference is
- a level of mailbox hierarchy AND ends with the hierarchy
- delimiter.
-
- Any part of the reference argument that is included in the
- interpreted form SHOULD prefix the interpreted form. It SHOULD
- also be in the same form as the reference name argument. This
- rule permits the client to determine if the returned mailbox name
- is in the context of the reference argument, or if something about
- the mailbox argument overrode the reference argument. Without
- this rule, the client would have to have knowledge of the server's
- naming semantics including what characters are "breakouts" that
- override a naming context.
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 41]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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).
-
- 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.
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 42]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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.
-
- The returned untagged LSUB response MAY contain different mailbox
- flags from a LIST untagged response. If this should happen, the
- flags in the untagged LIST are considered more authoritative.
-
- A special situation occurs when using LSUB with the % wildcard.
- Consider what happens if "foo/bar" (with a hierarchy delimiter of
- "/") is subscribed but "foo" is not. A "%" wildcard to LSUB must
- return foo, not foo/bar, in the LSUB response, and it MUST be
- flagged with the \Noselect attribute.
-
- The server MUST NOT unilaterally remove an existing mailbox name
- from the subscription list even if a mailbox by that name no
- longer exists.
-
-
-
-
-
-
-
-Crispin Standards Track [Page 43]
-
-RFC 3501 IMAPv4 March 2003
-
-
- Example: C: A002 LSUB "#news." "comp.mail.*"
- S: * LSUB () "." #news.comp.mail.mime
- S: * LSUB () "." #news.comp.mail.misc
- S: A002 OK LSUB completed
- C: A003 LSUB "#news." "comp.%"
- S: * LSUB (\NoSelect) "." #news.comp.mail
- S: A003 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. Under certain circumstances, it can be
- quite slow. 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.
-
- Note: The STATUS command is intended to access the
- status of mailboxes other than the currently selected
- mailbox. Because the STATUS command can cause the
- mailbox to be opened internally, and because this
- information is available by other means on the selected
- mailbox, the STATUS command SHOULD NOT be used on the
- currently selected mailbox.
-
-
-
-
-
-
-Crispin Standards Track [Page 44]
-
-RFC 3501 IMAPv4 March 2003
-
-
- The STATUS command MUST NOT be used as a "check for new
- messages in the selected mailbox" operation (refer to
- sections 7, 7.3.1, and 7.3.2 for more information about
- the proper method for new message checking).
-
- Because the STATUS command is not guaranteed to be fast
- in its results, clients SHOULD NOT expect to be able to
- issue many consecutive STATUS commands and obtain
- reasonable performance.
-
- 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 unique identifier value of the mailbox. Refer to
- section 2.3.1.1 for more information.
-
- UIDVALIDITY
- The unique identifier validity value of the mailbox. Refer to
- section 2.3.1.1 for more information.
-
- 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
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 45]
-
-RFC 3501 IMAPv4 March 2003
-
-
-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-2822] 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-2822] 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 to empty by default. In either case, the
- Recent flag is also set.
-
- 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.
-
- 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.
-
-
-
-Crispin Standards Track [Page 46]
-
-RFC 3501 IMAPv4 March 2003
-
-
- If the mailbox is currently selected, the normal new message
- 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}
- S: + Ready for literal data
- C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
- C: From: Fred Foobar <address@hidden>
- C: Subject: afternoon meeting
- C: To: address@hidden
- C: Message-Id: <address@hidden>
- 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 the 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.
-
-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
-
-
-
-Crispin Standards Track [Page 47]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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
- message 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
- BAD - command unknown or arguments invalid
-
- The CLOSE command permanently removes all messages that have the
- \Deleted flag set from the currently selected mailbox, and returns
- to the authenticated state from the 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
- 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
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 48]
-
-RFC 3501 IMAPv4 March 2003
-
-
-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 all messages that have the
- \Deleted flag set from the currently selected mailbox. 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
-
- 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.
-
-
-
-
-
-
-Crispin Standards Track [Page 49]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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-2822]/[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). This response SHOULD
- contain the BADCHARSET response code, which MAY list the
- [CHARSET]s supported by the server.
-
- 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.
-
- <sequence 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.
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 50]
-
-RFC 3501 IMAPv4 March 2003
-
-
- BCC <string>
- Messages that contain the specified string in the envelope
- structure's BCC field.
-
- BEFORE <date>
- Messages whose internal date (disregarding time and timezone)
- 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-2822]) and that contains the specified string
- in the text of the header (what comes after the colon). If the
- string to search is zero-length, this matches all messages that
- have a header line with the specified field-name regardless of
- the contents.
-
- KEYWORD <flag>
- Messages with the specified keyword flag set.
-
- LARGER <n>
- Messages with an [RFC-2822] size larger than the specified
- number of octets.
-
- NEW
- Messages that have the \Recent flag set but not the \Seen flag.
- This is functionally equivalent to "(RECENT UNSEEN)".
-
-
-
-
-Crispin Standards Track [Page 51]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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 (disregarding time and timezone)
- is within the specified date.
-
- OR <search-key1> <search-key2>
- Messages that match either search key.
-
- RECENT
- Messages that have the \Recent flag set.
-
- SEEN
- Messages that have the \Seen flag set.
-
- SENTBEFORE <date>
- Messages whose [RFC-2822] Date: header (disregarding time and
- timezone) is earlier than the specified date.
-
- SENTON <date>
- Messages whose [RFC-2822] Date: header (disregarding time and
- timezone) is within the specified date.
-
- SENTSINCE <date>
- Messages whose [RFC-2822] Date: header (disregarding time and
- timezone) is within or later than the specified date.
-
- SINCE <date>
- Messages whose internal date (disregarding time and timezone)
- is within or later than the specified date.
-
- SMALLER <n>
- Messages with an [RFC-2822] size smaller than the specified
- number of octets.
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 52]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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 <sequence set>
- Messages with unique identifiers corresponding to the specified
- unique identifier set. Sequence set ranges are permitted.
-
- 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 flag set.
-
- UNSEEN
- Messages that do not have the \Seen flag set.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 53]
-
-RFC 3501 IMAPv4 March 2003
-
-
- Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
- S: * SEARCH 2 84 882
- S: A282 OK SEARCH completed
- C: A283 SEARCH TEXT "string not in mailbox"
- S: * SEARCH
- S: A283 OK SEARCH completed
- C: A284 SEARCH CHARSET UTF-8 TEXT {6}
- C: XXXXXX
- S: * SEARCH 43
- S: A284 OK SEARCH completed
-
- Note: Since this document is restricted to 7-bit ASCII
- text, it is not possible to show actual UTF-8 data. The
- "XXXXXX" is a placeholder for what would be 6 octets of
- 8-bit data in an actual transaction.
-
-
-6.4.5. FETCH Command
-
- Arguments: sequence set
- message data item names or macro
-
- 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.
-
- Most data items, identified in the formal syntax under the
- msg-att-static rule, are static and MUST NOT change for any
- particular message. Other data items, identified in the formal
- syntax under the msg-att-dynamic rule, MAY change, either as a
- result of a STORE command or due to external events.
-
- For example, if a client receives an ENVELOPE for a
- message when it already knows the envelope, it can
- safely ignore the newly transmitted envelope.
-
- There are three macros which specify commonly-used sets of data
- items, and can be used instead of data items. A macro must be
- used by itself, and not in conjunction with other macros or data
- items.
-
-
-
-
-
-Crispin Standards Track [Page 54]
-
-RFC 3501 IMAPv4 March 2003
-
-
- ALL
- Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
-
- FAST
- Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE)
-
- FULL
- Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE
- BODY)
-
- The currently defined data items that can be fetched are:
-
- 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.
-
- 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-2822] 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-2822]) names, and return a
-
-
-
-Crispin Standards Track [Page 55]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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. Subsetting does not
- exclude the [RFC-2822] delimiting blank line between the header
- and the body; the blank line is included in all header fetches,
- except in the case of a message which has no body and no blank
- line.
-
- 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-2822] header.
-
- Here is an example of a complex message with some of its
- part specifiers:
-
- HEADER ([RFC-2822] header of the message)
- TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED
- 1 TEXT/PLAIN
- 2 APPLICATION/OCTET-STREAM
- 3 MESSAGE/RFC822
- 3.HEADER ([RFC-2822] header of the message)
- 3.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED
- 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-2822] header of the message)
- 4.2.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED
- 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.
-
-
-
-
-Crispin Standards Track [Page 56]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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.
-
- 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-2822] header and [MIME-IMB] headers.
-
- ENVELOPE
- The envelope structure of the message. This is computed by the
- server by parsing the [RFC-2822] header into the component
- parts, defaulting various fields as necessary.
-
- FLAGS
- The flags that are set for this message.
-
- 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-2822] size of the message.
-
-
-
-
-Crispin Standards Track [Page 57]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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.
-
-
- 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: sequence 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.
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 58]
-
-RFC 3501 IMAPv4 March 2003
-
-
- The currently defined data items that can be stored are:
-
- FLAGS <flag list>
- Replace the flags for the message (other than \Recent) with the
- argument. The new value of the flags is 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 is 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>
- Remove the argument from the flags for the message. The new
- value of the flags is 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: sequence 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
-
-
-
-
-
-
-
-Crispin Standards Track [Page 59]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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, and the Recent flag SHOULD be set,
- in the copy.
-
- If the destination mailbox does not exist, a server SHOULD return
- an error. It SHOULD NOT automatically create the mailbox. Unless
- it is certain that the destination mailbox can not be created, the
- server MUST send the response code "[TRYCREATE]" as the prefix of
- the text of the tagged NO response. This gives a hint to the
- client that it can attempt a CREATE command and retry the COPY if
- the CREATE is successful.
-
- If the COPY command is unsuccessful for any reason, server
- implementations MUST restore the destination mailbox to its state
- before the COPY attempt.
-
- Example: C: A003 COPY 2:4 MEETING
- S: A003 OK COPY completed
-
-
-6.4.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 sequence set argument are unique identifiers instead of
- message sequence numbers. Sequence set ranges are permitted, but
- there is no guarantee that unique identifiers will be contiguous.
-
- A non-existent unique identifier is ignored without any error
- message generated. Thus, it is possible for a UID FETCH command
- to return an OK without any data or a UID COPY or UID STORE to
- return an OK without performing any operations.
-
- 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
-
-
-
-Crispin Standards Track [Page 60]
-
-RFC 3501 IMAPv4 March 2003
-
-
- of message sequence numbers. For example, the command UID SEARCH
- 1:100 UID 443:557 returns the unique identifiers corresponding to
- the intersection of two sequence sets, the message sequence number
- range 1:100 and the UID range 443:557.
-
- Note: in the above example, the UID range 443:557
- appears. The same comment about a non-existent unique
- identifier being ignored without any error message also
- applies here. Hence, even if neither UID 443 or 557
- exist, this range is valid and would include an existing
- UID 495.
-
- Also note that a UID range of 559:* always includes the
- UID of the last message in the mailbox, even if 559 is
- higher than any assigned UID value. This is because the
- contents of a range are independent of the order of the
- range endpoints. Thus, any UID range with * as one of
- the endpoints indicates at least one message (the
- message with the highest numbered UID), unless the
- mailbox is empty.
-
- 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.
-
-
- Note: The rule about including the UID message data item as part
- of a FETCH response primarily applies to the UID FETCH and UID
- STORE commands, including a UID FETCH command that does not
- include UID as a message data item. Although it is unlikely that
- the other UID commands will cause an untagged FETCH, this rule
- applies to these commands as well.
-
- 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 OK UID FETCH completed
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 61]
-
-RFC 3501 IMAPv4 March 2003
-
-
-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 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.
-
- 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
-
-
-
-Crispin Standards Track [Page 62]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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 the selected state. In the 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
- can 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
- 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.
-
-
-
-
-
-Crispin Standards Track [Page 63]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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.
-
- BADCHARSET
-
- Optionally followed by a parenthesized list of charsets. A
- SEARCH failed because the given charset is not supported by
- this implementation. If the optional list of charsets is
- given, this lists the charsets that are supported by this
- implementation.
-
- CAPABILITY
-
- Followed by a list of capabilities. This can appear in the
- initial OK or PREAUTH response to transmit an initial
- capabilities list. This makes it unnecessary for a client to
- send a separate CAPABILITY command if it recognizes this
- response.
-
- PARSE
-
- The human-readable text represents an error in parsing the
- [RFC-2822] 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 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 ignore the change or store the
- state change 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.
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 64]
-
-RFC 3501 IMAPv4 March 2003
-
-
- READ-ONLY
-
- The mailbox is selected read-only, or its access while selected
- has changed from read-write to read-only.
-
- READ-WRITE
-
- The mailbox is selected read-write, or its access while
- selected has changed from read-only to read-write.
-
- TRYCREATE
-
- An APPEND or COPY attempt is failing because the target mailbox
- does not exist (as opposed to some other reason). This is a
- hint to the client that the operation can succeed if the
- mailbox is first created by the CREATE command.
-
- UIDNEXT
-
- Followed by a decimal number, indicates the next unique
- identifier value. Refer to section 2.3.1.1 for more
- information.
-
- UIDVALIDITY
-
- Followed by a decimal number, indicates the unique identifier
- validity value. Refer to section 2.3.1.1 for more information.
-
- 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
-
-
-
-
-Crispin Standards Track [Page 65]
-
-RFC 3501 IMAPv4 March 2003
-
-
- information-only message; the nature of the information MAY be
- indicated by a response code.
-
- The untagged form is also used as one of three possible greetings
- at connection startup. It indicates that the connection is not
- yet authenticated and that a LOGIN command is needed.
-
- Example: S: * OK IMAP4rev1 server ready
- C: A001 LOGIN fred blurdybloop
- S: * OK [ALERT] System shutdown in 10 minutes
- S: A001 OK LOGIN Completed
-
-
-7.1.2. NO Response
-
- Contents: OPTIONAL response code
- human-readable text
-
- The NO response indicates an operational error message from the
- server. When tagged, it indicates unsuccessful completion of the
- associated command. The untagged form indicates a warning; the
- command can still complete successfully. The human-readable text
- describes the condition.
-
- Example: C: A222 COPY 1:2 owatagusiam
- S: * NO Disk is 98% full, please delete unnecessary data
- S: A222 OK COPY completed
- C: A223 COPY 3:200 blurdybloop
- S: * NO Disk is 98% full, please delete unnecessary data
- S: * NO Disk is 99% full, please delete unnecessary data
- S: A223 NO COPY failed: disk is full
-
-
-7.1.3. BAD Response
-
- Contents: OPTIONAL response code
- human-readable text
-
- The BAD response indicates an error message from the server. When
- tagged, it reports a protocol-level error in the client's command;
- the tag indicates the command that caused the error. The untagged
- form indicates a protocol-level error for which the associated
- command can not be determined; it can also indicate an internal
- server failure. The human-readable text describes the condition.
-
-
-
-
-
-
-
-Crispin Standards Track [Page 66]
-
-RFC 3501 IMAPv4 March 2003
-
-
- Example: C: ...very long command line...
- S: * BAD Command line too long
- C: ...empty line...
- S: * BAD Empty command line
- C: A443 EXPUNGE
- S: * BAD Disk crash, attempting salvage to a new disk!
- S: * OK Salvage successful, no data lost
- S: A443 OK Expunge completed
-
-
-7.1.4. PREAUTH Response
-
- Contents: OPTIONAL response code
- human-readable text
-
- The PREAUTH response is always untagged, and is one of three
- possible greetings at connection startup. It indicates that the
- connection has already been authenticated by external means; thus
- no LOGIN command is needed.
-
- Example: S: * PREAUTH IMAP4rev1 server logged in as Smith
-
-
-7.1.5. BYE Response
-
- Contents: OPTIONAL response code
- human-readable text
-
- The BYE response is always untagged, and indicates that the server
- is about to close the connection. The human-readable text MAY be
- displayed to the user in a status report by the client. The BYE
- response is sent under one of four conditions:
-
- 1) as part of a normal logout sequence. The server will close
- the connection after sending the tagged OK response to the
- LOGOUT command.
-
- 2) as a panic shutdown announcement. The server closes the
- connection immediately.
-
- 3) as an announcement of an inactivity autologout. The server
- closes the connection immediately.
-
- 4) as one of three possible greetings at connection startup,
- indicating that the server is not willing to accept a
- connection from this client. The server closes the
- connection immediately.
-
-
-
-
-Crispin Standards Track [Page 67]
-
-RFC 3501 IMAPv4 March 2003
-
-
- The difference between a BYE that occurs as part of a normal
- LOGOUT sequence (the first case) and a BYE that occurs because of
- a failure (the other three cases) is that the connection closes
- immediately in the failure case. In all cases the client SHOULD
- continue to read response data from the server until the
- connection is closed; this will ensure that any pending untagged
- or completion responses are read and processed.
-
- Example: S: * BYE Autologout; idle for too long
-
-7.2. Server Responses - Server and Mailbox Status
-
- These responses are always untagged. This is how server and mailbox
- status data are transmitted from the server to the client. Many of
- these responses typically result from a command with the same name.
-
-7.2.1. CAPABILITY Response
-
- Contents: capability listing
-
- The CAPABILITY response occurs as a result of a CAPABILITY
- command. The capability listing contains a space-separated
- listing of capability names that the server supports. The
- capability listing MUST include the atom "IMAP4rev1".
-
- In addition, client and server implementations MUST implement the
- STARTTLS, LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
- capabilities. See the Security Considerations section for
- important information.
-
- A capability name which begins with "AUTH=" indicates that the
- server supports that particular authentication mechanism.
-
- The LOGINDISABLED capability indicates that the LOGIN command is
- disabled, and that the server will respond with a tagged NO
- response to any attempt to use the LOGIN command even if the user
- name and password are valid. An IMAP client MUST NOT issue the
- LOGIN command if the server advertises the LOGINDISABLED
- capability.
-
- Other capability names indicate that the server supports an
- extension, revision, or amendment to the IMAP4rev1 protocol.
- Server responses MUST conform to this document until the client
- issues a command that uses the associated capability.
-
- Capability names MUST either begin with "X" or be standard or
- standards-track IMAP4rev1 extensions, revisions, or amendments
- registered with IANA. A server MUST NOT offer unregistered or
-
-
-
-Crispin Standards Track [Page 68]
-
-RFC 3501 IMAPv4 March 2003
-
-
- non-standard capability names, unless such names are prefixed with
- an "X".
-
- Client implementations SHOULD NOT require any capability name
- other than "IMAP4rev1", and MUST ignore any unknown capability
- names.
-
- A server MAY send capabilities automatically, by using the
- CAPABILITY response code in the initial PREAUTH or OK responses,
- and by sending an updated CAPABILITY response code in the tagged
- OK response as part of a successful authentication. It is
- unnecessary for a client to send a separate CAPABILITY command if
- it recognizes these automatic capabilities.
-
- Example: S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN
-
-
-7.2.2. LIST Response
-
- Contents: name attributes
- hierarchy delimiter
- name
-
- The LIST response occurs as a result of a LIST command. It
- returns a single name that matches the LIST specification. There
- can be multiple LIST responses for a single LIST command.
-
- Four name attributes are defined:
-
- \Noinferiors
- It is not possible for any child levels of hierarchy to exist
- under this name; no child levels exist now and none can be
- created in the future.
-
- \Noselect
- It is not possible to use this name as a selectable mailbox.
-
- \Marked
- The mailbox has been marked "interesting" by the server; the
- mailbox probably contains messages that have been added since
- the last time the mailbox was selected.
-
- \Unmarked
- The mailbox does not contain any additional messages since the
- last time the mailbox was selected.
-
-
-
-
-
-
-Crispin Standards Track [Page 69]
-
-RFC 3501 IMAPv4 March 2003
-
-
- If it is not feasible for the server to determine whether or not
- the mailbox is "interesting", or if the name is a \Noselect name,
- the server SHOULD NOT send either \Marked or \Unmarked.
-
- The hierarchy delimiter is a character used to delimit levels of
- hierarchy in a mailbox name. A client can use it to create child
- mailboxes, and to search higher or lower levels of naming
- hierarchy. All children of a top-level hierarchy node MUST use
- the same separator character. A NIL hierarchy delimiter means
- that no hierarchy exists; the name is a "flat" name.
-
- The name represents an unambiguous left-to-right hierarchy, and
- MUST be valid for use as a reference in LIST and LSUB commands.
- Unless \Noselect is indicated, the name MUST also be valid as an
- argument for commands, such as SELECT, that accept mailbox names.
-
- Example: S: * LIST (\Noselect) "/" ~/Mail/foo
-
-
-7.2.3. LSUB Response
-
- Contents: name attributes
- hierarchy delimiter
- name
-
- The LSUB response occurs as a result of an LSUB command. It
- returns a single name that matches the LSUB specification. There
- can be multiple LSUB responses for a single LSUB command. The
- data is identical in format to the LIST response.
-
- Example: S: * LSUB () "." #news.comp.mail.misc
-
-
-7.2.4 STATUS Response
-
- Contents: name
- status parenthesized list
-
- The STATUS response occurs as a result of an STATUS command. It
- returns the mailbox name that matches the STATUS specification and
- the requested mailbox status information.
-
- Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 70]
-
-RFC 3501 IMAPv4 March 2003
-
-
-7.2.5. SEARCH Response
-
- Contents: zero or more numbers
-
- The SEARCH response occurs as a result of a SEARCH or UID SEARCH
- command. The number(s) refer to those messages that match the
- search criteria. For SEARCH, these are message sequence numbers;
- for UID SEARCH, these are unique identifiers. Each number is
- delimited by a space.
-
- Example: S: * SEARCH 2 3 6
-
-
-7.2.6. FLAGS Response
-
- Contents: flag parenthesized list
-
- The FLAGS response occurs as a result of a SELECT or EXAMINE
- command. The flag parenthesized list identifies the flags (at a
- minimum, the system-defined flags) that are applicable for this
- mailbox. Flags other than the system flags can also exist,
- depending on server implementation.
-
- The update from the FLAGS response MUST be recorded by the client.
-
- Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
-
-
-7.3. Server Responses - Mailbox Size
-
- These responses are always untagged. This is how changes in the size
- of the mailbox are transmitted from the server to the client.
- Immediately following the "*" token is a number that represents a
- message count.
-
-7.3.1. EXISTS Response
-
- Contents: none
-
- The EXISTS response reports the number of messages in the mailbox.
- This response occurs as a result of a SELECT or EXAMINE command,
- and if the size of the mailbox changes (e.g., new messages).
-
- The update from the EXISTS response MUST be recorded by the
- client.
-
- Example: S: * 23 EXISTS
-
-
-
-
-Crispin Standards Track [Page 71]
-
-RFC 3501 IMAPv4 March 2003
-
-
-7.3.2. RECENT Response
-
- Contents: none
-
- The RECENT response reports the number of messages with the
- \Recent flag set. This response occurs as a result of a SELECT or
- EXAMINE command, and if the size of the mailbox changes (e.g., new
- messages).
-
- Note: It is not guaranteed that the message sequence
- numbers of recent messages will be a contiguous range of
- the highest n messages in the mailbox (where n is the
- value reported by the RECENT response). Examples of
- situations in which this is not the case are: multiple
- clients having the same mailbox open (the first session
- to be notified will see it as recent, others will
- probably see it as non-recent), and when the mailbox is
- re-ordered by a non-IMAP agent.
-
- The only reliable way to identify recent messages is to
- look at message flags to see which have the \Recent flag
- set, or to do a SEARCH RECENT.
-
- The update from the RECENT response MUST be recorded by the
- client.
-
- Example: S: * 5 RECENT
-
-
-7.4. Server Responses - Message Status
-
- These responses are always untagged. This is how message data are
- transmitted from the server to the client, often as a result of a
- command with the same name. Immediately following the "*" token is a
- number that represents a message sequence number.
-
-7.4.1. EXPUNGE Response
-
- Contents: none
-
- The EXPUNGE response reports that the specified message sequence
- number has been permanently removed from the mailbox. The message
- sequence number for each successive message in the mailbox is
- immediately decremented by 1, and this decrement is reflected in
- message sequence numbers in subsequent responses (including other
- untagged EXPUNGE responses).
-
-
-
-
-
-Crispin Standards Track [Page 72]
-
-RFC 3501 IMAPv4 March 2003
-
-
- The EXPUNGE response also decrements the number of messages in the
- mailbox; it is not necessary to send an EXISTS response with the
- new value.
-
- As a result of the immediate decrement rule, message sequence
- numbers that appear in a set of successive EXPUNGE responses
- depend upon whether the messages are removed starting from lower
- numbers to higher numbers, or from higher numbers to lower
- numbers. For example, if the last 5 messages in a 9-message
- mailbox are expunged, a "lower to higher" server will send five
- untagged EXPUNGE responses for message sequence number 5, whereas
- a "higher to lower server" will send successive untagged EXPUNGE
- responses for message sequence numbers 9, 8, 7, 6, and 5.
-
- An EXPUNGE response MUST NOT be sent when no command is in
- progress, nor while responding to a FETCH, STORE, or SEARCH
- command. This rule is necessary to prevent a loss of
- synchronization of message sequence numbers between client and
- server. A command is not "in progress" until the complete command
- has been received; in particular, a command is not "in progress"
- during the negotiation of command continuation.
-
- Note: UID FETCH, UID STORE, and UID SEARCH are different
- commands from FETCH, STORE, and SEARCH. An EXPUNGE
- response MAY be sent during a UID command.
-
- The update from the EXPUNGE response MUST be recorded by the
- client.
-
- Example: S: * 44 EXPUNGE
-
-
-7.4.2. FETCH Response
-
- Contents: message data
-
- The FETCH response returns data about a message to the client.
- The data are pairs of data item names and their values in
- parentheses. This response occurs as the result of a FETCH or
- STORE command, as well as by unilateral server decision (e.g.,
- flag updates).
-
- The current data items are:
-
- BODY
- A form of BODYSTRUCTURE without extension data.
-
-
-
-
-
-Crispin Standards Track [Page 73]
-
-RFC 3501 IMAPv4 March 2003
-
-
- BODY[<section>]<<origin octet>>
- A string expressing the body contents of the specified section.
- The string SHOULD be interpreted by the client according to the
- content transfer encoding, body type, and subtype.
-
- If the origin octet is specified, this string is a substring of
- the entire body contents, starting at that origin octet. This
- means that BODY[]<0> MAY be truncated, but BODY[] is NEVER
- truncated.
-
- Note: The origin octet facility MUST NOT be used by a server
- in a FETCH response unless the client specifically requested
- it by means of a FETCH of a BODY[<section>]<<partial>> data
- item.
-
- 8-bit textual data is permitted if a [CHARSET] identifier is
- part of the body parameter parenthesized list for this section.
- Note that headers (part specifiers HEADER or MIME, or the
- header portion of a MESSAGE/RFC822 part), MUST be 7-bit; 8-bit
- characters are not permitted in headers. Note also that the
- [RFC-2822] delimiting blank line between the header and the
- body is not affected by header line subsetting; the blank line
- is always included as part of header data, except in the case
- of a message which has no body and no blank line.
-
- Non-textual data such as binary data MUST be transfer encoded
- into a textual form, such as BASE64, prior to being sent to the
- client. To derive the original binary data, the client MUST
- decode the transfer encoded string.
-
- BODYSTRUCTURE
- A parenthesized list that describes the [MIME-IMB] body
- structure of a message. This is computed by the server by
- parsing the [MIME-IMB] header fields, defaulting various fields
- as necessary.
-
- For example, a simple text message of 48 lines and 2279 octets
- can have a body structure of: ("TEXT" "PLAIN" ("CHARSET"
- "US-ASCII") NIL NIL "7BIT" 2279 48)
-
- Multiple parts are indicated by parenthesis nesting. Instead
- of a body type as the first element of the parenthesized list,
- there is a sequence of one or more nested body structures. The
- second element of the parenthesized list is the multipart
- subtype (mixed, digest, parallel, alternative, etc.).
-
-
-
-
-
-
-Crispin Standards Track [Page 74]
-
-RFC 3501 IMAPv4 March 2003
-
-
- For example, a two part message consisting of a text and a
- BASE64-encoded text attachment can have a body structure of:
- (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152
- 23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff")
- "<address@hidden>" "Compiler diff"
- "BASE64" 4554 73) "MIXED")
-
- Extension data follows the multipart subtype. Extension data
- is never returned with the BODY fetch, but can be returned with
- a BODYSTRUCTURE fetch. Extension data, if present, MUST be in
- the defined order. The extension data of a multipart body part
- are in the following order:
-
- body parameter parenthesized list
- A parenthesized list of attribute/value pairs [e.g., ("foo"
- "bar" "baz" "rag") where "bar" is the value of "foo", and
- "rag" is the value of "baz"] as defined in [MIME-IMB].
-
- body disposition
- A parenthesized list, consisting of a disposition type
- string, followed by a parenthesized list of disposition
- attribute/value pairs as defined in [DISPOSITION].
-
- body language
- A string or parenthesized list giving the body language
- value as defined in [LANGUAGE-TAGS].
-
- body location
- A string list giving the body content URI as defined in
- [LOCATION].
-
- Any following extension data are not yet defined in this
- version of the protocol. Such extension data can consist of
- zero or more NILs, strings, numbers, or potentially nested
- parenthesized lists of such data. Client implementations that
- do a BODYSTRUCTURE fetch MUST be prepared to accept such
- extension data. Server implementations MUST NOT send such
- extension data until it has been defined by a revision of this
- protocol.
-
- The basic fields of a non-multipart body part are in the
- following order:
-
- body type
- A string giving the content media type name as defined in
- [MIME-IMB].
-
-
-
-
-
-Crispin Standards Track [Page 75]
-
-RFC 3501 IMAPv4 March 2003
-
-
- body subtype
- A string giving the content subtype name as defined in
- [MIME-IMB].
-
- body parameter parenthesized list
- A parenthesized list of attribute/value pairs [e.g., ("foo"
- "bar" "baz" "rag") where "bar" is the value of "foo" and
- "rag" is the value of "baz"] as defined in [MIME-IMB].
-
- body id
- A string giving the content id as defined in [MIME-IMB].
-
- body description
- A string giving the content description as defined in
- [MIME-IMB].
-
- body encoding
- A string giving the content transfer encoding as defined in
- [MIME-IMB].
-
- body size
- A number giving the size of the body in octets. Note that
- this size is the size in its transfer encoding and not the
- resulting size after any decoding.
-
- A body type of type MESSAGE and subtype RFC822 contains,
- immediately after the basic fields, the envelope structure,
- body structure, and size in text lines of the encapsulated
- message.
-
- A body type of type TEXT contains, immediately after the basic
- fields, the size of the body in text lines. Note that this
- size is the size in its content transfer encoding and not the
- resulting size after any decoding.
-
- Extension data follows the basic fields and the type-specific
- fields listed above. Extension data is never returned with the
- BODY fetch, but can be returned with a BODYSTRUCTURE fetch.
- Extension data, if present, MUST be in the defined order.
-
- The extension data of a non-multipart body part are in the
- following order:
-
- body MD5
- A string giving the body MD5 value as defined in [MD5].
-
-
-
-
-
-
-Crispin Standards Track [Page 76]
-
-RFC 3501 IMAPv4 March 2003
-
-
- body disposition
- A parenthesized list with the same content and function as
- the body disposition for a multipart body part.
-
- body language
- A string or parenthesized list giving the body language
- value as defined in [LANGUAGE-TAGS].
-
- body location
- A string list giving the body content URI as defined in
- [LOCATION].
-
- Any following extension data are not yet defined in this
- version of the protocol, and would be as described above under
- multipart extension data.
-
- ENVELOPE
- A parenthesized list that describes the envelope structure of a
- message. This is computed by the server by parsing the
- [RFC-2822] header into the component parts, defaulting various
- fields as necessary.
-
- The fields of the envelope structure are in the following
- order: date, subject, from, sender, reply-to, to, cc, bcc,
- in-reply-to, and message-id. The date, subject, in-reply-to,
- and message-id fields are strings. The from, sender, reply-to,
- to, cc, and bcc fields are parenthesized lists of address
- structures.
-
- An address structure is a parenthesized list that describes an
- electronic mail address. The fields of an address structure
- are in the following order: personal name, [SMTP]
- at-domain-list (source route), mailbox name, and host name.
-
- [RFC-2822] group syntax is indicated by a special form of
- address structure in which the host name field is NIL. If the
- mailbox name field is also NIL, this is an end of group marker
- (semi-colon in RFC 822 syntax). If the mailbox name field is
- non-NIL, this is a start of group marker, and the mailbox name
- field holds the group name phrase.
-
- If the Date, Subject, In-Reply-To, and Message-ID header lines
- are absent in the [RFC-2822] header, the corresponding member
- of the envelope is NIL; if these header lines are present but
- empty the corresponding member of the envelope is the empty
- string.
-
-
-
-
-
-Crispin Standards Track [Page 77]
-
-RFC 3501 IMAPv4 March 2003
-
-
- Note: some servers may return a NIL envelope member in the
- "present but empty" case. Clients SHOULD treat NIL and
- empty string as identical.
-
- Note: [RFC-2822] requires that all messages have a valid
- Date header. Therefore, the date member in the envelope can
- not be NIL or the empty string.
-
- Note: [RFC-2822] requires that the In-Reply-To and
- Message-ID headers, if present, have non-empty content.
- Therefore, the in-reply-to and message-id members in the
- envelope can not be the empty string.
-
- If the From, To, cc, and bcc header lines are absent in the
- [RFC-2822] header, or are present but empty, the corresponding
- member of the envelope is NIL.
-
- If the Sender or Reply-To lines are absent in the [RFC-2822]
- header, or are present but empty, the server sets the
- corresponding member of the envelope to be the same value as
- the from member (the client is not expected to know to do
- this).
-
- Note: [RFC-2822] requires that all messages have a valid
- From header. Therefore, the from, sender, and reply-to
- members in the envelope can not be NIL.
-
- FLAGS
- A parenthesized list of flags that are set for this message.
-
- INTERNALDATE
- A string representing the internal date of the message.
-
- RFC822
- Equivalent to BODY[].
-
- RFC822.HEADER
- Equivalent to BODY[HEADER]. Note that this did not result in
- \Seen being set, because RFC822.HEADER response data occurs as
- a result of a FETCH of RFC822.HEADER. BODY[HEADER] response
- data occurs as a result of a FETCH of BODY[HEADER] (which sets
- \Seen) or BODY.PEEK[HEADER] (which does not set \Seen).
-
- RFC822.SIZE
- A number expressing the [RFC-2822] size of the message.
-
-
-
-
-
-
-Crispin Standards Track [Page 78]
-
-RFC 3501 IMAPv4 March 2003
-
-
- RFC822.TEXT
- Equivalent to BODY[TEXT].
-
- UID
- A number expressing the unique identifier of the message.
-
-
- Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
-
-
-7.5. Server Responses - Command Continuation Request
-
- The command continuation request response is indicated by a "+" token
- instead of a tag. This form of response indicates that the server is
- ready to accept the continuation of a command from the client. The
- remainder of this response is a line of text.
-
- This response is used in the AUTHENTICATE command to transmit server
- data to the client, and request additional client data. This
- response is also used if an argument to any command is a literal.
-
- The client is not permitted to send the octets of the literal unless
- the server indicates that it is expected. This permits the server to
- process commands and reject errors on a line-by-line basis. The
- remainder of the command, including the CRLF that terminates a
- command, follows the octets of the literal. If there are any
- additional command arguments, the literal octets are followed by a
- space and those arguments.
-
- Example: C: A001 LOGIN {11}
- S: + Ready for additional command text
- C: FRED FOOBAR {7}
- S: + Ready for additional command text
- C: fat man
- S: A001 OK LOGIN completed
- C: A044 BLURDYBLOOP {102856}
- S: A044 BAD No such command as "BLURDYBLOOP"
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 79]
-
-RFC 3501 IMAPv4 March 2003
-
-
-8. Sample IMAP4rev1 connection
-
- The following is a transcript of an IMAP4rev1 connection. A long
- line in this sample is broken for editorial clarity.
-
-S: * OK IMAP4rev1 Service Ready
-C: a001 login mrc secret
-S: a001 OK LOGIN completed
-C: a002 select inbox
-S: * 18 EXISTS
-S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
-S: * 2 RECENT
-S: * OK [UNSEEN 17] Message 17 is the first unseen message
-S: * OK [UIDVALIDITY 3857529045] UIDs valid
-S: a002 OK [READ-WRITE] SELECT completed
-C: a003 fetch 12 full
-S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
- RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
- "IMAP4rev1 WG mtg summary and minutes"
- (("Terry Gray" NIL "gray" "cac.washington.edu"))
- (("Terry Gray" NIL "gray" "cac.washington.edu"))
- (("Terry Gray" NIL "gray" "cac.washington.edu"))
- ((NIL NIL "imap" "cac.washington.edu"))
- ((NIL NIL "minutes" "CNRI.Reston.VA.US")
- ("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
- "<address@hidden>")
- BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028
- 92))
-S: a003 OK FETCH completed
-C: a004 fetch 12 body[header]
-S: * 12 FETCH (BODY[HEADER] {342}
-S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
-S: From: Terry Gray <address@hidden>
-S: Subject: IMAP4rev1 WG mtg summary and minutes
-S: To: address@hidden
-S: cc: address@hidden, John Klensin <address@hidden>
-S: Message-Id: <address@hidden>
-S: MIME-Version: 1.0
-S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
-S:
-S: )
-S: a004 OK FETCH completed
-C: a005 store 12 +flags \deleted
-S: * 12 FETCH (FLAGS (\Seen \Deleted))
-S: a005 OK +FLAGS completed
-C: a006 logout
-S: * BYE IMAP4rev1 server terminating connection
-S: a006 OK LOGOUT completed
-
-
-
-Crispin Standards Track [Page 80]
-
-RFC 3501 IMAPv4 March 2003
-
-
-9. Formal Syntax
-
- The following syntax specification uses the Augmented Backus-Naur
- Form (ABNF) notation as specified in [ABNF].
-
- In the case of alternative or optional rules in which a later rule
- overlaps an earlier rule, the rule which is listed earlier MUST take
- priority. For example, "\Seen" when parsed as a flag is the \Seen
- flag name and not a flag-extension, even though "\Seen" can be parsed
- as a flag-extension. Some, but not all, instances of this rule are
- noted below.
-
- Note: [ABNF] rules MUST be followed strictly; in
- particular:
-
- (1) 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.
-
- (2) In all cases, SP refers to exactly one space. It is
- NOT permitted to substitute TAB, insert additional spaces,
- or otherwise treat SP as being equivalent to LWSP.
-
- (3) The ASCII NUL character, %x00, MUST NOT be used at any
- time.
-
-address = "(" addr-name SP addr-adl SP addr-mailbox SP
- addr-host ")"
-
-addr-adl = nstring
- ; Holds route from [RFC-2822] route-addr if
- ; non-NIL
-
-addr-host = nstring
- ; NIL indicates [RFC-2822] group syntax.
- ; Otherwise, holds [RFC-2822] domain name
-
-addr-mailbox = nstring
- ; NIL indicates end of [RFC-2822] group; if
- ; non-NIL and addr-host is NIL, holds
- ; [RFC-2822] group name.
- ; Otherwise, holds [RFC-2822] local-part
- ; after removing [RFC-2822] quoting
-
-
-
-
-
-
-Crispin Standards Track [Page 81]
-
-RFC 3501 IMAPv4 March 2003
-
-
-addr-name = nstring
- ; If non-NIL, holds phrase from [RFC-2822]
- ; mailbox after removing [RFC-2822] quoting
-
-append = "APPEND" SP mailbox [SP flag-list] [SP date-time] SP
- literal
-
-astring = 1*ASTRING-CHAR / string
-
-ASTRING-CHAR = ATOM-CHAR / resp-specials
-
-atom = 1*ATOM-CHAR
-
-ATOM-CHAR = <any CHAR except atom-specials>
-
-atom-specials = "(" / ")" / "{" / SP / CTL / list-wildcards /
- quoted-specials / resp-specials
-
-authenticate = "AUTHENTICATE" SP auth-type *(CRLF base64)
-
-auth-type = atom
- ; Defined by [SASL]
-
-base64 = *(4base64-char) [base64-terminal]
-
-base64-char = ALPHA / DIGIT / "+" / "/"
- ; Case-sensitive
-
-base64-terminal = (2base64-char "==") / (3base64-char "=")
-
-body = "(" (body-type-1part / body-type-mpart) ")"
-
-body-extension = nstring / number /
- "(" body-extension *(SP body-extension) ")"
- ; Future expansion. Client implementations
- ; MUST accept body-extension fields. Server
- ; implementations MUST NOT generate
- ; body-extension fields except as defined by
- ; future standard or standards-track
- ; revisions of this specification.
-
-body-ext-1part = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang
- [SP body-fld-loc *(SP body-extension)]]]
- ; MUST NOT be returned on non-extensible
- ; "BODY" fetch
-
-
-
-
-
-
-Crispin Standards Track [Page 82]
-
-RFC 3501 IMAPv4 March 2003
-
-
-body-ext-mpart = body-fld-param [SP body-fld-dsp [SP body-fld-lang
- [SP body-fld-loc *(SP body-extension)]]]
- ; MUST NOT be returned on non-extensible
- ; "BODY" fetch
-
-body-fields = body-fld-param SP body-fld-id SP body-fld-desc SP
- body-fld-enc SP body-fld-octets
-
-body-fld-desc = nstring
-
-body-fld-dsp = "(" string SP body-fld-param ")" / nil
-
-body-fld-enc = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
- "QUOTED-PRINTABLE") DQUOTE) / string
-
-body-fld-id = nstring
-
-body-fld-lang = nstring / "(" string *(SP string) ")"
-
-body-fld-loc = nstring
-
-body-fld-lines = number
-
-body-fld-md5 = nstring
-
-body-fld-octets = number
-
-body-fld-param = "(" string SP string *(SP string SP string) ")" / nil
-
-body-type-1part = (body-type-basic / body-type-msg / body-type-text)
- [SP body-ext-1part]
-
-body-type-basic = media-basic SP body-fields
- ; MESSAGE subtype MUST NOT be "RFC822"
-
-body-type-mpart = 1*body SP media-subtype
- [SP body-ext-mpart]
-
-body-type-msg = media-message SP body-fields SP envelope
- SP body SP body-fld-lines
-
-body-type-text = media-text SP body-fields SP body-fld-lines
-
-capability = ("AUTH=" auth-type) / atom
- ; New capabilities MUST begin with "X" or be
- ; registered with IANA as standard or
- ; standards-track
-
-
-
-
-Crispin Standards Track [Page 83]
-
-RFC 3501 IMAPv4 March 2003
-
-
-capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev1"
- *(SP capability)
- ; Servers MUST implement the STARTTLS, AUTH=PLAIN,
- ; and LOGINDISABLED capabilities
- ; Servers which offer RFC 1730 compatibility MUST
- ; list "IMAP4" as the first capability.
-
-CHAR8 = %x01-ff
- ; any OCTET except NUL, %x00
-
-command = tag SP (command-any / command-auth / command-nonauth /
- command-select) CRLF
- ; Modal based on state
-
-command-any = "CAPABILITY" / "LOGOUT" / "NOOP" / x-command
- ; Valid in all states
-
-command-auth = append / create / delete / examine / list / lsub /
- rename / select / status / subscribe / unsubscribe
- ; Valid only in Authenticated or Selected state
-
-command-nonauth = login / authenticate / "STARTTLS"
- ; Valid only when in Not Authenticated state
-
-command-select = "CHECK" / "CLOSE" / "EXPUNGE" / copy / fetch / store /
- uid / search
- ; Valid only when in Selected state
-
-continue-req = "+" SP (resp-text / base64) CRLF
-
-copy = "COPY" SP sequence-set SP mailbox
-
-create = "CREATE" SP mailbox
- ; Use of INBOX gives a NO error
-
-date = date-text / DQUOTE date-text DQUOTE
-
-date-day = 1*2DIGIT
- ; Day of month
-
-date-day-fixed = (SP DIGIT) / 2DIGIT
- ; Fixed-format version of date-day
-
-date-month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
- "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
-
-date-text = date-day "-" date-month "-" date-year
-
-
-
-
-Crispin Standards Track [Page 84]
-
-RFC 3501 IMAPv4 March 2003
-
-
-date-year = 4DIGIT
-
-date-time = DQUOTE date-day-fixed "-" date-month "-" date-year
- SP time SP zone DQUOTE
-
-delete = "DELETE" SP mailbox
- ; Use of INBOX gives a NO error
-
-digit-nz = %x31-39
- ; 1-9
-
-envelope = "(" env-date SP env-subject SP env-from SP
- env-sender SP env-reply-to SP env-to SP env-cc SP
- env-bcc SP env-in-reply-to SP env-message-id ")"
-
-env-bcc = "(" 1*address ")" / nil
-
-env-cc = "(" 1*address ")" / nil
-
-env-date = nstring
-
-env-from = "(" 1*address ")" / nil
-
-env-in-reply-to = nstring
-
-env-message-id = nstring
-
-env-reply-to = "(" 1*address ")" / nil
-
-env-sender = "(" 1*address ")" / nil
-
-env-subject = nstring
-
-env-to = "(" 1*address ")" / nil
-
-examine = "EXAMINE" SP mailbox
-
-fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" /
- fetch-att / "(" fetch-att *(SP fetch-att) ")")
-
-fetch-att = "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
- "RFC822" [".HEADER" / ".SIZE" / ".TEXT"] /
- "BODY" ["STRUCTURE"] / "UID" /
- "BODY" section ["<" number "." nz-number ">"] /
- "BODY.PEEK" section ["<" number "." nz-number ">"]
-
-
-
-
-
-
-Crispin Standards Track [Page 85]
-
-RFC 3501 IMAPv4 March 2003
-
-
-flag = "\Answered" / "\Flagged" / "\Deleted" /
- "\Seen" / "\Draft" / flag-keyword / flag-extension
- ; Does not include "\Recent"
-
-flag-extension = "\" atom
- ; Future expansion. Client implementations
- ; MUST accept flag-extension flags. Server
- ; implementations MUST NOT generate
- ; flag-extension flags except as defined by
- ; future standard or standards-track
- ; revisions of this specification.
-
-flag-fetch = flag / "\Recent"
-
-flag-keyword = atom
-
-flag-list = "(" [flag *(SP flag)] ")"
-
-flag-perm = flag / "\*"
-
-greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF
-
-header-fld-name = astring
-
-header-list = "(" header-fld-name *(SP header-fld-name) ")"
-
-list = "LIST" SP mailbox SP list-mailbox
-
-list-mailbox = 1*list-char / string
-
-list-char = ATOM-CHAR / list-wildcards / resp-specials
-
-list-wildcards = "%" / "*"
-
-literal = "{" number "}" CRLF *CHAR8
- ; Number represents the number of CHAR8s
-
-login = "LOGIN" SP userid SP password
-
-lsub = "LSUB" SP mailbox SP list-mailbox
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 86]
-
-RFC 3501 IMAPv4 March 2003
-
-
-mailbox = "INBOX" / astring
- ; INBOX is case-insensitive. All case variants of
- ; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX
- ; not as an astring. An astring which consists of
- ; the case-insensitive sequence "I" "N" "B" "O" "X"
- ; is considered to be INBOX and not an astring.
- ; Refer to section 5.1 for further
- ; semantic details of mailbox names.
-
-mailbox-data = "FLAGS" SP flag-list / "LIST" SP mailbox-list /
- "LSUB" SP mailbox-list / "SEARCH" *(SP nz-number) /
- "STATUS" SP mailbox SP "(" [status-att-list] ")" /
- number SP "EXISTS" / number SP "RECENT"
-
-mailbox-list = "(" [mbx-list-flags] ")" SP
- (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
-
-mbx-list-flags = *(mbx-list-oflag SP) mbx-list-sflag
- *(SP mbx-list-oflag) /
- mbx-list-oflag *(SP mbx-list-oflag)
-
-mbx-list-oflag = "\Noinferiors" / flag-extension
- ; Other flags; multiple possible per LIST response
-
-mbx-list-sflag = "\Noselect" / "\Marked" / "\Unmarked"
- ; Selectability flags; only one per LIST response
-
-media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /
- "MESSAGE" / "VIDEO") DQUOTE) / string) SP
- media-subtype
- ; Defined in [MIME-IMT]
-
-media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE "RFC822" DQUOTE
- ; Defined in [MIME-IMT]
-
-media-subtype = string
- ; Defined in [MIME-IMT]
-
-media-text = DQUOTE "TEXT" DQUOTE SP media-subtype
- ; Defined in [MIME-IMT]
-
-message-data = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att))
-
-msg-att = "(" (msg-att-dynamic / msg-att-static)
- *(SP (msg-att-dynamic / msg-att-static)) ")"
-
-msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"
- ; MAY change for a message
-
-
-
-Crispin Standards Track [Page 87]
-
-RFC 3501 IMAPv4 March 2003
-
-
-msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time /
- "RFC822" [".HEADER" / ".TEXT"] SP nstring /
- "RFC822.SIZE" SP number /
- "BODY" ["STRUCTURE"] SP body /
- "BODY" section ["<" number ">"] SP nstring /
- "UID" SP uniqueid
- ; MUST NOT change for a message
-
-nil = "NIL"
-
-nstring = string / nil
-
-number = 1*DIGIT
- ; Unsigned 32-bit integer
- ; (0 <= n < 4,294,967,296)
-
-nz-number = digit-nz *DIGIT
- ; Non-zero unsigned 32-bit integer
- ; (0 < n < 4,294,967,296)
-
-password = astring
-
-quoted = DQUOTE *QUOTED-CHAR DQUOTE
-
-QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> /
- "\" quoted-specials
-
-quoted-specials = DQUOTE / "\"
-
-rename = "RENAME" SP mailbox SP mailbox
- ; Use of INBOX as a destination gives a NO error
-
-response = *(continue-req / response-data) response-done
-
-response-data = "*" SP (resp-cond-state / resp-cond-bye /
- mailbox-data / message-data / capability-data) CRLF
-
-response-done = response-tagged / response-fatal
-
-response-fatal = "*" SP resp-cond-bye CRLF
- ; Server closes connection immediately
-
-response-tagged = tag SP resp-cond-state CRLF
-
-resp-cond-auth = ("OK" / "PREAUTH") SP resp-text
- ; Authentication condition
-
-
-
-
-
-Crispin Standards Track [Page 88]
-
-RFC 3501 IMAPv4 March 2003
-
-
-resp-cond-bye = "BYE" SP resp-text
-
-resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
- ; Status condition
-
-resp-specials = "]"
-
-resp-text = ["[" resp-text-code "]" SP] text
-
-resp-text-code = "ALERT" /
- "BADCHARSET" [SP "(" astring *(SP astring) ")" ] /
- capability-data / "PARSE" /
- "PERMANENTFLAGS" SP "("
- [flag-perm *(SP flag-perm)] ")" /
- "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
- "UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number /
- "UNSEEN" SP nz-number /
- atom [SP 1*<any TEXT-CHAR except "]">]
-
-search = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key)
- ; CHARSET argument to MUST be registered with IANA
-
-search-key = "ALL" / "ANSWERED" / "BCC" SP astring /
- "BEFORE" SP date / "BODY" SP astring /
- "CC" SP astring / "DELETED" / "FLAGGED" /
- "FROM" SP astring / "KEYWORD" SP flag-keyword /
- "NEW" / "OLD" / "ON" SP date / "RECENT" / "SEEN" /
- "SINCE" SP date / "SUBJECT" SP astring /
- "TEXT" SP astring / "TO" SP astring /
- "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
- "UNKEYWORD" SP flag-keyword / "UNSEEN" /
- ; Above this line were in [IMAP2]
- "DRAFT" / "HEADER" SP header-fld-name SP astring /
- "LARGER" SP number / "NOT" SP search-key /
- "OR" SP search-key SP search-key /
- "SENTBEFORE" SP date / "SENTON" SP date /
- "SENTSINCE" SP date / "SMALLER" SP number /
- "UID" SP sequence-set / "UNDRAFT" / sequence-set /
- "(" search-key *(SP search-key) ")"
-
-section = "[" [section-spec] "]"
-
-section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list /
- "TEXT"
- ; top-level or MESSAGE/RFC822 part
-
-section-part = nz-number *("." nz-number)
- ; body part nesting
-
-
-
-Crispin Standards Track [Page 89]
-
-RFC 3501 IMAPv4 March 2003
-
-
-section-spec = section-msgtext / (section-part ["." section-text])
-
-section-text = section-msgtext / "MIME"
- ; text other than actual body part (headers, etc.)
-
-select = "SELECT" SP mailbox
-
-seq-number = nz-number / "*"
- ; message sequence number (COPY, FETCH, STORE
- ; commands) or unique identifier (UID COPY,
- ; UID FETCH, UID STORE commands).
- ; * represents the largest number in use. In
- ; the case of message sequence numbers, it is
- ; the number of messages in a non-empty mailbox.
- ; In the case of unique identifiers, it is the
- ; unique identifier of the last message in the
- ; mailbox or, if the mailbox is empty, the
- ; mailbox's current UIDNEXT value.
- ; The server should respond with a tagged BAD
- ; response to a command that uses a message
- ; sequence number greater than the number of
- ; messages in the selected mailbox. This
- ; includes "*" if the selected mailbox is empty.
-
-seq-range = seq-number ":" seq-number
- ; two seq-number values and all values between
- ; these two regardless of order.
- ; Example: 2:4 and 4:2 are equivalent and indicate
- ; values 2, 3, and 4.
- ; Example: a unique identifier sequence range of
- ; 3291:* includes the UID of the last message in
- ; the mailbox, even if that value is less than 3291.
-
-sequence-set = (seq-number / seq-range) *("," sequence-set)
- ; set of seq-number values, regardless of order.
- ; Servers MAY coalesce overlaps and/or execute the
- ; sequence in any order.
- ; Example: a message sequence number set of
- ; 2,4:7,9,12:* for a mailbox with 15 messages is
- ; equivalent to 2,4,5,6,7,9,12,13,14,15
- ; Example: a message sequence number set of *:4,5:7
- ; for a mailbox with 10 messages is equivalent to
- ; 10,9,8,7,6,5,4,5,6,7 and MAY be reordered and
- ; overlap coalesced to be 4,5,6,7,8,9,10.
-
-status = "STATUS" SP mailbox SP
- "(" status-att *(SP status-att) ")"
-
-
-
-
-Crispin Standards Track [Page 90]
-
-RFC 3501 IMAPv4 March 2003
-
-
-status-att = "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" /
- "UNSEEN"
-
-status-att-list = status-att SP number *(SP status-att SP number)
-
-store = "STORE" SP sequence-set SP store-att-flags
-
-store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP
- (flag-list / (flag *(SP flag)))
-
-string = quoted / literal
-
-subscribe = "SUBSCRIBE" SP mailbox
-
-tag = 1*<any ASTRING-CHAR except "+">
-
-text = 1*TEXT-CHAR
-
-TEXT-CHAR = <any CHAR except CR and LF>
-
-time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
- ; Hours minutes seconds
-
-uid = "UID" SP (copy / fetch / search / store)
- ; Unique identifiers used instead of message
- ; sequence numbers
-
-uniqueid = nz-number
- ; Strictly ascending
-
-unsubscribe = "UNSUBSCRIBE" SP mailbox
-
-userid = astring
-
-x-command = "X" atom <experimental command arguments>
-
-zone = ("+" / "-") 4DIGIT
- ; Signed four-digit value of hhmm representing
- ; hours and minutes east of Greenwich (that is,
- ; the amount that the given time differs from
- ; Universal Time). Subtracting the timezone
- ; from the given time will give the UT form.
- ; The Universal Time zone is "+0000".
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 91]
-
-RFC 3501 IMAPv4 March 2003
-
-
-10. Author's Note
-
- This document is a revision or rewrite of earlier documents, and
- supercedes the protocol specification in those documents: RFC 2060,
- RFC 1730, unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064.
-
-11. Security Considerations
-
- IMAP4rev1 protocol transactions, including electronic mail data, are
- sent in the clear over the network unless protection from snooping is
- negotiated. This can be accomplished either by the use of STARTTLS,
- negotiated privacy protection in the AUTHENTICATE command, or some
- other protection mechanism.
-
-11.1. STARTTLS Security Considerations
-
- The specification of the STARTTLS command and LOGINDISABLED
- capability in this document replaces that in [IMAP-TLS]. [IMAP-TLS]
- remains normative for the PLAIN [SASL] authenticator.
-
- IMAP client and server implementations MUST implement the
- TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite, and SHOULD implement the
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite. This is
- important as it assures that any two compliant implementations can be
- configured to interoperate. All other cipher suites are OPTIONAL.
- Note that this is a change from section 2.1 of [IMAP-TLS].
-
- During the [TLS] negotiation, the client MUST check its understanding
- of the server hostname against the server's identity as presented in
- the server Certificate message, in order to prevent man-in-the-middle
- attacks. If the match fails, the client SHOULD either ask for
- explicit user confirmation, or terminate the connection and indicate
- that the server's identity is suspect. Matching is performed
- according to these rules:
-
- The client MUST use the server hostname it used to open the
- connection as the value to compare against the server name
- as expressed in the server certificate. The client MUST
- NOT use any form of the server hostname derived from an
- insecure remote source (e.g., insecure DNS lookup). CNAME
- canonicalization is not done.
-
- If a subjectAltName extension of type dNSName is present in
- the certificate, it SHOULD be used as the source of the
- server's identity.
-
- Matching is case-insensitive.
-
-
-
-
-Crispin Standards Track [Page 92]
-
-RFC 3501 IMAPv4 March 2003
-
-
- A "*" wildcard character MAY be used as the left-most name
- component in the certificate. For example, *.example.com
- would match a.example.com, foo.example.com, etc. but would
- not match example.com.
-
- If the certificate contains multiple names (e.g., more than
- one dNSName field), then a match with any one of the fields
- is considered acceptable.
-
- Both the client and server MUST check the result of the STARTTLS
- command and subsequent [TLS] negotiation to see whether acceptable
- authentication or privacy was achieved.
-
-11.2. Other Security Considerations
-
- A server error message for an AUTHENTICATE command which fails due to
- invalid credentials SHOULD NOT detail why the credentials are
- invalid.
-
- Use of the LOGIN command sends passwords in the clear. This can be
- avoided by using the AUTHENTICATE command with a [SASL] mechanism
- that does not use plaintext passwords, by first negotiating
- encryption via STARTTLS or some other protection mechanism.
-
- A server implementation MUST implement a configuration that, at the
- time of authentication, requires:
- (1) The STARTTLS command has been negotiated.
- OR
- (2) Some other mechanism that protects the session from password
- snooping has been provided.
- OR
- (3) The following measures are in place:
- (a) The LOGINDISABLED capability is advertised, and [SASL]
- mechanisms (such as PLAIN) using plaintext passwords are NOT
- advertised in the CAPABILITY list.
- AND
- (b) The LOGIN command returns an error even if the password is
- correct.
- AND
- (c) The AUTHENTICATE command returns an error with all [SASL]
- mechanisms that use plaintext passwords, even if the password
- is correct.
-
- A server error message for a failing LOGIN command SHOULD NOT specify
- that the user name, as opposed to the password, is invalid.
-
- A server SHOULD have mechanisms in place to limit or delay failed
- AUTHENTICATE/LOGIN attempts.
-
-
-
-Crispin Standards Track [Page 93]
-
-RFC 3501 IMAPv4 March 2003
-
-
- Additional security considerations are discussed in the section
- discussing the AUTHENTICATE and LOGIN commands.
-
-12. IANA Considerations
-
- IMAP4 capabilities are registered by publishing a standards track or
- IESG approved experimental RFC. The registry is currently located
- at:
-
- http://www.iana.org/assignments/imap4-capabilities
-
- As this specification revises the STARTTLS and LOGINDISABLED
- extensions previously defined in [IMAP-TLS], the registry will be
- updated accordingly.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 94]
-
-RFC 3501 IMAPv4 March 2003
-
-
-Appendices
-
-A. Normative References
-
- The following documents contain definitions or specifications that
- are necessary to understand this document properly:
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for
- Syntax Specifications: ABNF", RFC 2234,
- November 1997.
-
- [ANONYMOUS] Newman, C., "Anonymous SASL Mechanism", RFC
- 2245, November 1997.
-
- [CHARSET] Freed, N. and J. Postel, "IANA Character Set
- Registration Procedures", RFC 2978, October
- 2000.
-
- [DIGEST-MD5] Leach, P. and C. Newman, "Using Digest
- Authentication as a SASL Mechanism", RFC 2831,
- May 2000.
-
- [DISPOSITION] Troost, R., Dorner, S. and K. Moore,
- "Communicating Presentation Information in
- Internet Messages: The Content-Disposition
- Header", RFC 2183, August 1997.
-
- [IMAP-TLS] Newman, C., "Using TLS with IMAP, POP3 and
- ACAP", RFC 2595, June 1999.
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to
- Indicate Requirement Levels", BCP 14, RFC 2119,
- March 1997.
-
- [LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of
- Languages", BCP 47, RFC 3066, January 2001.
-
- [LOCATION] Palme, J., Hopmann, A. and N. Shelness, "MIME
- Encapsulation of Aggregate Documents, such as
- HTML (MHTML)", RFC 2557, March 1999.
-
- [MD5] Myers, J. and M. Rose, "The Content-MD5 Header
- Field", RFC 1864, October 1995.
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 95]
-
-RFC 3501 IMAPv4 March 2003
-
-
- [MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail
- Extensions) Part Three: Message Header
- Extensions for Non-ASCII Text", RFC 2047,
- November 1996.
-
- [MIME-IMB] Freed, N. and N. Borenstein, "MIME
- (Multipurpose Internet Mail Extensions) Part
- One: Format of Internet Message Bodies", RFC
- 2045, November 1996.
-
- [MIME-IMT] Freed, N. and N. Borenstein, "MIME
- (Multipurpose Internet Mail Extensions) Part
- Two: Media Types", RFC 2046, November 1996.
-
- [RFC-2822] Resnick, P., "Internet Message Format", RFC
- 2822, April 2001.
-
- [SASL] Myers, J., "Simple Authentication and Security
- Layer (SASL)", RFC 2222, October 1997.
-
- [TLS] Dierks, T. and C. Allen, "The TLS Protocol
- Version 1.0", RFC 2246, January 1999.
-
- [UTF-7] Goldsmith, D. and M. Davis, "UTF-7: A Mail-Safe
- Transformation Format of Unicode", RFC 2152,
- May 1997.
-
- The following documents describe quality-of-implementation issues
- that should be carefully considered when implementing this protocol:
-
- [IMAP-IMPLEMENTATION] Leiba, B., "IMAP Implementation
- Recommendations", RFC 2683, September 1999.
-
- [IMAP-MULTIACCESS] Gahrns, M., "IMAP4 Multi-Accessed Mailbox
- Practice", RFC 2180, July 1997.
-
-A.1 Informative References
-
- The following documents describe related protocols:
-
- [IMAP-DISC] Austein, R., "Synchronization Operations for
- Disconnected IMAP4 Clients", Work in Progress.
-
- [IMAP-MODEL] Crispin, M., "Distributed Electronic Mail
- Models in IMAP4", RFC 1733, December 1994.
-
-
-
-
-
-
-Crispin Standards Track [Page 96]
-
-RFC 3501 IMAPv4 March 2003
-
-
- [ACAP] Newman, C. and J. Myers, "ACAP -- Application
- Configuration Access Protocol", RFC 2244,
- November 1997.
-
- [SMTP] Klensin, J., "Simple Mail Transfer Protocol",
- STD 10, RFC 2821, April 2001.
-
- The following documents are historical or describe historical aspects
- of this protocol:
-
- [IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with
- IMAP2bis", RFC 2061, December 1996.
-
- [IMAP-HISTORICAL] Crispin, M., "IMAP4 Compatibility with IMAP2
- and IMAP2bis", RFC 1732, December 1994.
-
- [IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol
- - Obsolete Syntax", RFC 2062, December 1996.
-
- [IMAP2] Crispin, M., "Interactive Mail Access Protocol
- - Version 2", RFC 1176, August 1990.
-
- [RFC-822] Crocker, D., "Standard for the Format of ARPA
- Internet Text Messages", STD 11, RFC 822,
- August 1982.
-
- [RFC-821] Postel, J., "Simple Mail Transfer Protocol",
- STD 10, RFC 821, August 1982.
-
-B. Changes from RFC 2060
-
- 1) Clarify description of unique identifiers and their semantics.
-
- 2) Fix the SELECT description to clarify that UIDVALIDITY is required
- in the SELECT and EXAMINE responses.
-
- 3) Added an example of a failing search.
-
- 4) Correct store-att-flags: "#flag" should be "1#flag".
-
- 5) Made search and section rules clearer.
-
- 6) Correct the STORE example.
-
- 7) Correct "BASE645" misspelling.
-
- 8) Remove extraneous close parenthesis in example of two-part message
- with text and BASE64 attachment.
-
-
-
-Crispin Standards Track [Page 97]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 9) Remove obsolete "MAILBOX" response from mailbox-data.
-
- 10) A spurious "<" in the rule for mailbox-data was removed.
-
- 11) Add CRLF to continue-req.
-
- 12) Specifically exclude "]" from the atom in resp-text-code.
-
- 13) Clarify that clients and servers should adhere strictly to the
- protocol syntax.
-
- 14) Emphasize in 5.2 that EXISTS can not be used to shrink a mailbox.
-
- 15) Add NEWNAME to resp-text-code.
-
- 16) Clarify that the empty string, not NIL, is used as arguments to
- LIST.
-
- 17) Clarify that NIL can be returned as a hierarchy delimiter for the
- empty string mailbox name argument if the mailbox namespace is flat.
-
- 18) Clarify that addr-mailbox and addr-name have RFC-2822 quoting
- removed.
-
- 19) Update UTF-7 reference.
-
- 20) Fix example in 6.3.11.
-
- 21) Clarify that non-existent UIDs are ignored.
-
- 22) Update DISPOSITION reference.
-
- 23) Expand state diagram.
-
- 24) Clarify that partial fetch responses are only returned in
- response to a partial fetch command.
-
- 25) Add UIDNEXT response code. Correct UIDVALIDITY definition
- reference.
-
- 26) Further clarification of "can" vs. "MAY".
-
- 27) Reference RFC-2119.
-
- 28) Clarify that superfluous shifts are not permitted in modified
- UTF-7.
-
- 29) Clarify that there are no implicit shifts in modified UTF-7.
-
-
-
-Crispin Standards Track [Page 98]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 30) Clarify that "INBOX" in a mailbox name is always INBOX, even if
- it is given as a string.
-
- 31) Add missing open parenthesis in media-basic grammar rule.
-
- 32) Correct attribute syntax in mailbox-data.
-
- 33) Add UIDNEXT to EXAMINE responses.
-
- 34) Clarify UNSEEN, PERMANENTFLAGS, UIDVALIDITY, and UIDNEXT
- responses in SELECT and EXAMINE. They are required now, but weren't
- in older versions.
-
- 35) Update references with RFC numbers.
-
- 36) Flush text-mime2.
-
- 37) Clarify that modified UTF-7 names must be case-sensitive and that
- violating the convention should be avoided.
-
- 38) Correct UID FETCH example.
-
- 39) Clarify UID FETCH, UID STORE, and UID SEARCH vs. untagged EXPUNGE
- responses.
-
- 40) Clarify the use of the word "convention".
-
- 41) Clarify that a command is not "in progress" until it has been
- fully received (specifically, that a command is not "in progress"
- during command continuation negotiation).
-
- 42) Clarify envelope defaulting.
-
- 43) Clarify that SP means one and only one space character.
-
- 44) Forbid silly states in LIST response.
-
- 45) Clarify that the ENVELOPE, INTERNALDATE, RFC822*, BODY*, and UID
- for a message is static.
-
- 46) Add BADCHARSET response code.
-
- 47) Update formal syntax to [ABNF] conventions.
-
- 48) Clarify trailing hierarchy delimiter in CREATE semantics.
-
- 49) Clarify that the "blank line" is the [RFC-2822] delimiting blank
- line.
-
-
-
-Crispin Standards Track [Page 99]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 50) Clarify that RENAME should also create hierarchy as needed for
- the command to complete.
-
- 51) Fix body-ext-mpart to not require language if disposition
- present.
-
- 52) Clarify the RFC822.HEADER response.
-
- 53) Correct missing space after charset astring in search.
-
- 54) Correct missing quote for BADCHARSET in resp-text-code.
-
- 55) Clarify that ALL, FAST, and FULL preclude any other data items
- appearing.
-
- 56) Clarify semantics of reference argument in LIST.
-
- 57) Clarify that a null string for SEARCH HEADER X-FOO means any
- message with a header line with a field-name of X-FOO regardless of
- the text of the header.
-
- 58) Specifically reserve 8-bit mailbox names for future use as UTF-8.
-
- 59) It is not an error for the client to store a flag that is not in
- the PERMANENTFLAGS list; however, the server will either ignore the
- change or make the change in the session only.
-
- 60) Correct/clarify the text regarding superfluous shifts.
-
- 61) Correct typographic errors in the "Changes" section.
-
- 62) Clarify that STATUS must not be used to check for new messages in
- the selected mailbox
-
- 63) Clarify LSUB behavior with "%" wildcard.
-
- 64) Change AUTHORIZATION to AUTHENTICATE in section 7.5.
-
- 65) Clarify description of multipart body type.
-
- 66) Clarify that STORE FLAGS does not affect \Recent.
-
- 67) Change "west" to "east" in description of timezone.
-
- 68) Clarify that commands which break command pipelining must wait
- for a completion result response.
-
- 69) Clarify that EXAMINE does not affect \Recent.
-
-
-
-Crispin Standards Track [Page 100]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 70) Make description of MIME structure consistent.
-
- 71) Clarify that date searches disregard the time and timezone of the
- INTERNALDATE or Date: header. In other words, "ON 13-APR-2000" means
- messages with an INTERNALDATE text which starts with "13-APR-2000",
- even if timezone differential from the local timezone is sufficient
- to move that INTERNALDATE into the previous or next day.
-
- 72) Clarify that the header fetches don't add a blank line if one
- isn't in the [RFC-2822] message.
-
- 73) Clarify (in discussion of UIDs) that messages are immutable.
-
- 74) Add an example of CHARSET searching.
-
- 75) Clarify in SEARCH that keywords are a type of flag.
-
- 76) Clarify the mandatory nature of the SELECT data responses.
-
- 77) Add optional CAPABILITY response code in the initial OK or
- PREAUTH.
-
- 78) Add note that server can send an untagged CAPABILITY command as
- part of the responses to AUTHENTICATE and LOGIN.
-
- 79) Remove statement about it being unnecessary to issue a CAPABILITY
- command more than once in a connection. That statement is no longer
- true.
-
- 80) Clarify that untagged EXPUNGE decrements the number of messages
- in the mailbox.
-
- 81) Fix definition of "body" (concatenation has tighter binding than
- alternation).
-
- 82) Add a new "Special Notes to Implementors" section with reference
- to [IMAP-IMPLEMENTATION].
-
- 83) Clarify that an untagged CAPABILITY response to an AUTHENTICATE
- command should only be done if a security layer was not negotiated.
-
- 84) Change the definition of atom to exclude "]". Update astring to
- include "]" for compatibility with the past. Remove resp-text-atom.
-
- 85) Remove NEWNAME. It can't work because mailbox names can be
- literals and can include "]". Functionality can be addressed via
- referrals.
-
-
-
-
-Crispin Standards Track [Page 101]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 86) Move modified UTF-7 rationale in order to have more logical
- paragraph flow.
-
- 87) Clarify UID uniqueness guarantees with the use of MUST.
-
- 88) Note that clients should read response data until the connection
- is closed instead of immediately closing on a BYE.
-
- 89) Change RFC-822 references to RFC-2822.
-
- 90) Clarify that RFC-2822 should be followed instead of RFC-822.
-
- 91) Change recommendation of optional automatic capabilities in LOGIN
- and AUTHENTICATE to use the CAPABILITY response code in the tagged
- OK. This is more interoperable than an unsolicited untagged
- CAPABILITY response.
-
- 92) STARTTLS and AUTH=PLAIN are mandatory to implement; add
- recommendations for other [SASL] mechanisms.
-
- 93) Clarify that a "connection" (as opposed to "server" or "command")
- is in one of the four states.
-
- 94) Clarify that a failed or rejected command does not change state.
-
- 95) Split references between normative and informative.
-
- 96) Discuss authentication failure issues in security section.
-
- 97) Clarify that a data item is not necessarily of only one data
- type.
-
- 98) Clarify that sequence ranges are independent of order.
-
- 99) Change an example to clarify that superfluous shifts in
- Modified-UTF7 can not be fixed just by omitting the shift. The
- entire string must be recalculated.
-
- 100) Change Envelope Structure definition since [RFC-2822] uses
- "envelope" to refer to the [SMTP] envelope and not the envelope data
- that appears in the [RFC-2822] header.
-
- 101) Expand on RFC822.HEADER response data vs. BODY[HEADER].
-
- 102) Clarify Logout state semantics, change ASCII art.
-
- 103) Security changes to comply with IESG requirements.
-
-
-
-
-Crispin Standards Track [Page 102]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 104) Add definition for body URI.
-
- 105) Break sequence range definition into three rules, with rewritten
- descriptions for each.
-
- 106) Move STARTTLS and LOGINDISABLED here from [IMAP-TLS].
-
- 107) Add IANA Considerations section.
-
- 108) Clarify valid client assumptions for new message UIDs vs.
- UIDNEXT.
-
- 109) Clarify that changes to permanentflags affect concurrent
- sessions as well as subsequent sessions.
-
- 110) Clarify that authenticated state can be entered by the CLOSE
- command.
-
- 111) Emphasize that SELECT and EXAMINE are the exceptions to the rule
- that a failing command does not change state.
-
- 112) Clarify that newly-appended messages have the Recent flag set.
-
- 113) Clarify that newly-copied messages SHOULD have the Recent flag
- set.
-
- 114) Clarify that UID commands always return the UID in FETCH
- responses.
-
-C. Key Word Index
-
- +FLAGS <flag list> (store command data item) ............... 59
- +FLAGS.SILENT <flag list> (store command data item) ........ 59
- -FLAGS <flag list> (store command data item) ............... 59
- -FLAGS.SILENT <flag list> (store command data item) ........ 59
- ALERT (response code) ...................................... 64
- ALL (fetch item) ........................................... 55
- ALL (search key) ........................................... 50
- ANSWERED (search key) ...................................... 50
- APPEND (command) ........................................... 45
- AUTHENTICATE (command) ..................................... 27
- BAD (response) ............................................. 66
- BADCHARSET (response code) ................................. 64
- BCC <string> (search key) .................................. 51
- BEFORE <date> (search key) ................................. 51
- BODY (fetch item) .......................................... 55
- BODY (fetch result) ........................................ 73
- BODY <string> (search key) ................................. 51
-
-
-
-Crispin Standards Track [Page 103]
-
-RFC 3501 IMAPv4 March 2003
-
-
- BODY.PEEK[<section>]<<partial>> (fetch item) ............... 57
- BODYSTRUCTURE (fetch item) ................................. 57
- BODYSTRUCTURE (fetch result) ............................... 74
- BODY[<section>]<<origin octet>> (fetch result) ............. 74
- BODY[<section>]<<partial>> (fetch item) .................... 55
- BYE (response) ............................................. 67
- Body Structure (message attribute) ......................... 12
- CAPABILITY (command) ....................................... 24
- CAPABILITY (response code) ................................. 64
- CAPABILITY (response) ...................................... 68
- CC <string> (search key) ................................... 51
- CHECK (command) ............................................ 47
- CLOSE (command) ............................................ 48
- COPY (command) ............................................. 59
- CREATE (command) ........................................... 34
- DELETE (command) ........................................... 35
- DELETED (search key) ....................................... 51
- DRAFT (search key) ......................................... 51
- ENVELOPE (fetch item) ...................................... 57
- ENVELOPE (fetch result) .................................... 77
- EXAMINE (command) .......................................... 33
- EXISTS (response) .......................................... 71
- EXPUNGE (command) .......................................... 48
- EXPUNGE (response) ......................................... 72
- Envelope Structure (message attribute) ..................... 12
- FAST (fetch item) .......................................... 55
- FETCH (command) ............................................ 54
- FETCH (response) ........................................... 73
- FLAGGED (search key) ....................................... 51
- FLAGS (fetch item) ......................................... 57
- FLAGS (fetch result) ....................................... 78
- FLAGS (response) ........................................... 71
- FLAGS <flag list> (store command data item) ................ 59
- FLAGS.SILENT <flag list> (store command data item) ......... 59
- FROM <string> (search key) ................................. 51
- FULL (fetch item) .......................................... 55
- Flags (message attribute) .................................. 11
- HEADER (part specifier) .................................... 55
- HEADER <field-name> <string> (search key) .................. 51
- HEADER.FIELDS <header-list> (part specifier) ............... 55
- HEADER.FIELDS.NOT <header-list> (part specifier) ........... 55
- INTERNALDATE (fetch item) .................................. 57
- INTERNALDATE (fetch result) ................................ 78
- Internal Date (message attribute) .......................... 12
- KEYWORD <flag> (search key) ................................ 51
- Keyword (type of flag) ..................................... 11
- LARGER <n> (search key) .................................... 51
- LIST (command) ............................................. 40
-
-
-
-Crispin Standards Track [Page 104]
-
-RFC 3501 IMAPv4 March 2003
-
-
- LIST (response) ............................................ 69
- LOGIN (command) ............................................ 30
- LOGOUT (command) ........................................... 25
- LSUB (command) ............................................. 43
- LSUB (response) ............................................ 70
- MAY (specification requirement term) ....................... 4
- MESSAGES (status item) ..................................... 45
- MIME (part specifier) ...................................... 56
- MUST (specification requirement term) ...................... 4
- MUST NOT (specification requirement term) .................. 4
- Message Sequence Number (message attribute) ................ 10
- NEW (search key) ........................................... 51
- NO (response) .............................................. 66
- NOOP (command) ............................................. 25
- NOT <search-key> (search key) .............................. 52
- OK (response) .............................................. 65
- OLD (search key) ........................................... 52
- ON <date> (search key) ..................................... 52
- OPTIONAL (specification requirement term) .................. 4
- OR <search-key1> <search-key2> (search key) ................ 52
- PARSE (response code) ...................................... 64
- PERMANENTFLAGS (response code) ............................. 64
- PREAUTH (response) ......................................... 67
- Permanent Flag (class of flag) ............................. 12
- READ-ONLY (response code) .................................. 65
- READ-WRITE (response code) ................................. 65
- RECENT (response) .......................................... 72
- RECENT (search key) ........................................ 52
- RECENT (status item) ....................................... 45
- RENAME (command) ........................................... 37
- REQUIRED (specification requirement term) .................. 4
- RFC822 (fetch item) ........................................ 57
- RFC822 (fetch result) ...................................... 78
- RFC822.HEADER (fetch item) ................................. 57
- RFC822.HEADER (fetch result) ............................... 78
- RFC822.SIZE (fetch item) ................................... 57
- RFC822.SIZE (fetch result) ................................. 78
- RFC822.TEXT (fetch item) ................................... 58
- RFC822.TEXT (fetch result) ................................. 79
- SEARCH (command) ........................................... 49
- SEARCH (response) .......................................... 71
- SEEN (search key) .......................................... 52
- SELECT (command) ........................................... 31
- SENTBEFORE <date> (search key) ............................. 52
- SENTON <date> (search key) ................................. 52
- SENTSINCE <date> (search key) .............................. 52
- SHOULD (specification requirement term) .................... 4
- SHOULD NOT (specification requirement term) ................ 4
-
-
-
-Crispin Standards Track [Page 105]
-
-RFC 3501 IMAPv4 March 2003
-
-
- SINCE <date> (search key) .................................. 52
- SMALLER <n> (search key) ................................... 52
- STARTTLS (command) ......................................... 27
- STATUS (command) ........................................... 44
- STATUS (response) .......................................... 70
- STORE (command) ............................................ 58
- SUBJECT <string> (search key) .............................. 53
- SUBSCRIBE (command) ........................................ 38
- Session Flag (class of flag) ............................... 12
- System Flag (type of flag) ................................. 11
- TEXT (part specifier) ...................................... 56
- TEXT <string> (search key) ................................. 53
- TO <string> (search key) ................................... 53
- TRYCREATE (response code) .................................. 65
- UID (command) .............................................. 60
- UID (fetch item) ........................................... 58
- UID (fetch result) ......................................... 79
- UID <sequence set> (search key) ............................ 53
- UIDNEXT (response code) .................................... 65
- UIDNEXT (status item) ...................................... 45
- UIDVALIDITY (response code) ................................ 65
- UIDVALIDITY (status item) .................................. 45
- UNANSWERED (search key) .................................... 53
- UNDELETED (search key) ..................................... 53
- UNDRAFT (search key) ....................................... 53
- UNFLAGGED (search key) ..................................... 53
- UNKEYWORD <flag> (search key) .............................. 53
- UNSEEN (response code) ..................................... 65
- UNSEEN (search key) ........................................ 53
- UNSEEN (status item) ....................................... 45
- UNSUBSCRIBE (command) ...................................... 39
- Unique Identifier (UID) (message attribute) ................ 8
- X<atom> (command) .......................................... 62
- [RFC-2822] Size (message attribute) ........................ 12
- \Answered (system flag) .................................... 11
- \Deleted (system flag) ..................................... 11
- \Draft (system flag) ....................................... 11
- \Flagged (system flag) ..................................... 11
- \Marked (mailbox name attribute) ........................... 69
- \Noinferiors (mailbox name attribute) ...................... 69
- \Noselect (mailbox name attribute) ......................... 69
- \Recent (system flag) ...................................... 11
- \Seen (system flag) ........................................ 11
- \Unmarked (mailbox name attribute) ......................... 69
-
-
-
-
-
-
-
-Crispin Standards Track [Page 106]
-
-RFC 3501 IMAPv4 March 2003
-
-
-Author's Address
-
- Mark R. Crispin
- Networks and Distributed Computing
- University of Washington
- 4545 15th Avenue NE
- Seattle, WA 98105-4527
-
- Phone: (206) 543-5762
-
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 107]
-
-RFC 3501 IMAPv4 March 2003
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns. v This
- document and the information contained herein is provided on an "AS
- IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
- FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
- LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
- NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
- OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 108]
-
-
diff --git a/doc/rfc/rfc3691.txt b/doc/rfc/rfc3691.txt
deleted file mode 100644
index 2f4e9b4..0000000
--- a/doc/rfc/rfc3691.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group A. Melnikov
-Request for Comments: 3691 Isode Ltd.
-Category: Standards Track February 2004
-
-
- Internet Message Access Protocol (IMAP) UNSELECT 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.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- This document defines an UNSELECT command that can be used to close
- the current mailbox in an Internet Message Access Protocol - version
- 4 (IMAP4) session without expunging it. Certain types of IMAP
- clients need to release resources associated with the selected
- mailbox without selecting a different mailbox. While IMAP4 provides
- this functionality (via a SELECT command with a nonexistent mailbox
- name or reselecting the same mailbox with EXAMINE command), a more
- clean solution is desirable.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. UNSELECT command . . . . . . . . . . . . . . . . . . . . . . . 2
- 3. Security Considerations. . . . . . . . . . . . . . . . . . . . 3
- 4. Formal Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 3
- 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 3
- 6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 3
- 7. Normative References . . . . . . . . . . . . . . . . . . . . . 4
- 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4
- 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 5
-
-
-
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 1]
-
-RFC 3691 IMAP UNSELECT command February 2004
-
-
-1. Introduction
-
- Certain types of IMAP clients need to release resources associated
- with the selected mailbox without selecting a different mailbox.
- While [IMAP4] provides this functionality (via a SELECT command with
- a nonexistent mailbox name or reselecting the same mailbox with
- EXAMINE command), a more clean solution is desirable.
-
- [IMAP4] defines the CLOSE command that closes the selected mailbox as
- well as permanently removes all messages with the \Deleted flag set.
-
- However [IMAP4] lacks a command that simply closes the mailbox
- without expunging it. This document defines the UNSELECT command for
- this purpose.
-
- A server which supports this extension indicates this with a
- capability name of "UNSELECT".
-
- "C:" and "S:" in examples show lines sent by the client and server
- respectively.
-
- The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
- this document when typed in uppercase are to be interpreted as
- defined in "Key words for use in RFCs to Indicate Requirement Levels"
- [KEYWORDS].
-
-2. UNSELECT Command
-
- Arguments: none
-
- Responses: no specific responses for this command
-
- Result: OK - unselect completed, now in authenticated state
- BAD - no mailbox selected, or argument supplied but
- none permitted
-
- The UNSELECT command frees server's resources associated with the
- selected mailbox and returns the server to the authenticated
- state. This command performs the same actions as CLOSE, except
- that no messages are permanently removed from the currently
- selected mailbox.
-
- Example: C: A341 UNSELECT
- S: A341 OK Unselect completed
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 2]
-
-RFC 3691 IMAP UNSELECT command February 2004
-
-
-3. Security Considerations
-
- It is believed that this extension doesn't raise any additional
- security concerns not already discussed in [IMAP4].
-
-4. Formal Syntax
-
- The following syntax specification uses the Augmented Backus-Naur
- Form (ABNF) notation as specified in [ABNF]. Non-terminals
- referenced but not defined below are as defined by [IMAP4].
-
- 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.
-
- command-select /= "UNSELECT"
-
-5. IANA Considerations
-
- IMAP4 capabilities are registered by publishing a standards track or
- IESG approved experimental RFC. The registry is currently located
- at:
-
- http://www.iana.org/assignments/imap4-capabilities
-
- This document defines the UNSELECT IMAP capabilities. IANA has added
- this capability to the registry.
-
-6. Acknowledgments
-
- UNSELECT command was originally implemented by Tim Showalter in Cyrus
- IMAP server.
-
- Also, the author of the document would like to thank Vladimir Butenko
- and Mark Crispin for reminding that UNSELECT has to be documented.
- Also thanks to Simon Josefsson for pointing out that there are
- multiple ways to implement UNSELECT.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 3]
-
-RFC 3691 IMAP UNSELECT command February 2004
-
-
-7. Normative References
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
- 4rev1", RFC 3501, March 2003.
-
- [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
-8. Author's Address
-
- Alexey Melnikov
- Isode Limited
- 5 Castle Business Village
- Hampton, Middlesex TW12 2BX
-
- EMail: address@hidden
- URI: http://www.melnikov.ca/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 4]
-
-RFC 3691 IMAP UNSELECT command February 2004
-
-
-9. Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). This document is subject
- to the rights, licenses and restrictions contained in BCP 78 and
- except as set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
- REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
- INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
- IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed
- to pertain to the implementation or use of the technology
- described in this document or the extent to which any license
- under such rights might or might not be available; nor does it
- represent that it has made any independent effort to identify any
- such rights. Information on the procedures with respect to
- rights in RFC documents can be found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use
- of such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository
- at http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention
- any copyrights, patents or patent applications, or other
- proprietary rights that may cover technology that may be required
- to implement this standard. Please address the information to the
- IETF at address@hidden
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 5]
-
diff --git a/doc/rfc/rfc4314.txt b/doc/rfc/rfc4314.txt
deleted file mode 100644
index e73a56f..0000000
--- a/doc/rfc/rfc4314.txt
+++ /dev/null
@@ -1,1515 +0,0 @@
-
-
-
-
-
-
-Network Working Group A. Melnikov
-Request for Comments: 4314 Isode Ltd.
-Obsoletes: 2086 December 2005
-Category: Standards Track
-
-
- IMAP4 Access Control List (ACL) Extension
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- The Access Control List (ACL) extension (RFC 2086) of the Internet
- Message Access Protocol (IMAP) permits mailbox access control lists
- to be retrieved and manipulated through the IMAP protocol.
-
- This document is a revision of RFC 2086. It defines several new
- access control rights and clarifies which rights are required for
- different IMAP commands.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 1]
-
-RFC 4314 IMAP ACL December 2005
-
-
-Table of Contents
-
- 1. Introduction and Overview .......................................3
- 1.1. Conventions Used in This Document ..........................3
- 2. Access Control ..................................................3
- 2.1. Standard Rights ............................................5
- 2.1.1. Obsolete Rights .....................................5
- 2.2. Rights Defined in RFC 2086 .................................8
- 3. Access control management commands and responses ................8
- 3.1. SETACL Command .............................................8
- 3.2. DELETEACL Command ..........................................9
- 3.3. GETACL Command ............................................10
- 3.4. LISTRIGHTS Command ........................................10
- 3.5. MYRIGHTS Command ..........................................11
- 3.6. ACL Response ..............................................11
- 3.7. LISTRIGHTS Response .......................................12
- 3.8. MYRIGHTS Response .........................................12
- 4. Rights Required to Perform Different IMAP4rev1 Commands ........12
- 5. Other Considerations ...........................................17
- 5.1. Additional Requirements and Implementation Notes ..........17
- 5.1.1. Servers ............................................17
- 5.1.2. Clients ............................................18
- 5.2. Mapping of ACL Rights to READ-WRITE and READ-ONLY
- Response Codes ............................................19
- 6. Security Considerations ........................................20
- 7. Formal Syntax ..................................................21
- 8. IANA Considerations ............................................22
- 9. Internationalization Considerations ............................22
- Appendix A. Changes since RFC 2086 ................................23
- Appendix B. Compatibility with RFC 2086 ...........................24
- Appendix C. Known Deficiencies ....................................24
- Appendix D. Acknowledgements ......................................25
- Normative References ..............................................25
- Informative References ............................................25
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 2]
-
-RFC 4314 IMAP ACL December 2005
-
-
-1. Introduction and Overview
-
- The ACL (Access Control List) extension of the Internet Message
- Access Protocol [IMAP4] permits mailbox access control lists to be
- retrieved and manipulated through the IMAP protocol.
-
- This document is a revision of RFC 2086 [RFC2086]. It tries to
- clarify different ambiguities in RFC 2086, in particular, the use of
- UTF-8 [UTF-8] in access identifiers, which rights are required for
- different IMAP4 commands, and how READ-WRITE/READ-ONLY response codes
- are related to ACL.
-
-1.1. Conventions Used in This Document
-
- In examples, "C:" and "S:" indicate lines sent by the client and
- server respectively.
-
- In all examples "/" character is used as hierarchy separator.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [KEYWORDS].
-
- The phrase "ACL server" is just a shortcut for saying "IMAP server
- that supports ACL extension as defined in this document".
-
-2. Access Control
-
- The ACL extension is present in any IMAP4 implementation that returns
- "ACL" as one of the supported capabilities to the CAPABILITY command.
-
- A server implementation conformant to this document MUST also return
- rights (see below) not defined in Section 2.2 in the "RIGHTS="
- capability.
-
- An access control list is a set of <access identifier,rights> pairs.
- An ACL applies to a mailbox name.
-
- Access identifier (or just "identifier") is a UTF-8 [UTF-8] string.
- The identifier "anyone" is reserved to refer to the universal
- identity (all authentications, including anonymous). All user name
- strings accepted by the LOGIN or AUTHENTICATE commands to
- authenticate to the IMAP server are reserved as identifiers for the
- corresponding users. Identifiers starting with a dash ("-") are
- reserved for "negative rights", described below. All other
- identifier strings are interpreted in an implementation-defined
- manner.
-
-
-
-
-Melnikov Standards Track [Page 3]
-
-RFC 4314 IMAP ACL December 2005
-
-
- Rights is a string listing a (possibly empty) set of alphanumeric
- characters, each character listing a set of operations that is being
- controlled. Lowercase letters are reserved for "standard" rights,
- listed in Section 2.1. (Note that for compatibility with deployed
- clients and servers uppercase rights are not allowed.) The set of
- standard rights can only be extended by a standards-track document.
- Digits are reserved for implementation- or site-defined rights.
-
- An implementation MAY tie rights together or MAY force rights to
- always or never be granted to particular identifiers. For example,
- in an implementation that uses UNIX mode bits, the rights "swite" are
- tied, the "a" right is always granted to the owner of a mailbox and
- is never granted to another user. If rights are tied in an
- implementation, the implementation must be conservative in granting
- rights in response to SETACL commands--unless all rights in a tied
- set are specified, none of that set should be included in the ACL
- entry for that identifier. A client can discover the set of rights
- that may be granted to a given identifier in the ACL for a given
- mailbox name by using the LISTRIGHTS command.
-
- It is possible for multiple identifiers in an access control list to
- apply to a given user. For example, an ACL may include rights to be
- granted to the identifier matching the user, one or more
- implementation-defined identifiers matching groups that include the
- user, and/or the identifier "anyone". How these rights are combined
- to determine the user's access is implementation defined. An
- implementation may choose, for example, to use the union of the
- rights granted to the applicable identifiers. An implementation may
- instead choose, for example, to use only those rights granted to the
- most specific identifier present in the ACL. A client can determine
- the set of rights granted to the logged-in user for a given mailbox
- name by using the MYRIGHTS command.
-
- When an identifier in an ACL starts with a dash ("-"), that indicates
- that associated rights are to be removed from the identifier prefixed
- by the dash. This is referred to as a "negative right". This
- differs from DELETEACL in that a negative right is added to the ACL
- and is a part of the calculation of the rights.
-
- Let's assume that an identifier "fred" refers to a user with login
- "fred". If the identifier "-fred" is granted the "w" right, that
- indicates that the "w" right is to be removed from users matching the
- identifier "fred", even though the user "fred" might have the "w"
- right as a consequence of some other identifier in the ACL. A
- DELETEACL of "fred" simply deletes the identifier "fred" from the
- ACL; it does not affect any rights that the user "fred" may get from
- another entry in the ACL, in particular it doesn't affect rights
- granted to the identifier "-fred".
-
-
-
-Melnikov Standards Track [Page 4]
-
-RFC 4314 IMAP ACL December 2005
-
-
- Server implementations are not required to support "negative right"
- identifiers.
-
-2.1. Standard Rights
-
- The currently defined standard rights are (note that the list below
- doesn't list all commands that use a particular right):
-
- l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE
- mailbox)
- r - read (SELECT the mailbox, perform STATUS)
- s - keep seen/unseen information across sessions (set or clear
- \SEEN flag via STORE, also set \SEEN during APPEND/COPY/
- FETCH BODY[...])
- w - write (set or clear flags other than \SEEN and \DELETED via
- STORE, also set them during APPEND/COPY)
- i - insert (perform APPEND, COPY into mailbox)
- p - post (send mail to submission address for mailbox,
- not enforced by IMAP4 itself)
- k - create mailboxes (CREATE new sub-mailboxes in any
- implementation-defined hierarchy, parent mailbox for the new
- mailbox name in RENAME)
- x - delete mailbox (DELETE mailbox, old mailbox name in RENAME)
- t - delete messages (set or clear \DELETED flag via STORE, set
- \DELETED flag during APPEND/COPY)
- e - perform EXPUNGE and expunge as a part of CLOSE
- a - administer (perform SETACL/DELETEACL/GETACL/LISTRIGHTS)
-
-2.1.1. Obsolete Rights
-
- Due to ambiguity in RFC 2086, some existing RFC 2086 server
- implementations use the "c" right to control the DELETE command.
- Others chose to use the "d" right to control the DELETE command. For
- the former group, let's define the "create" right as union of the "k"
- and "x" rights, and the "delete" right as union of the "e" and "t"
- rights. For the latter group, let's define the "create" rights as a
- synonym to the "k" right, and the "delete" right as union of the "e",
- "t", and "x" rights.
-
- For compatibility with RFC 2086, this section defines two virtual
- rights "d" and "c".
-
- If a client includes the "d" right in a rights list, then it MUST be
- treated as if the client had included every member of the "delete"
- right. (It is not an error for a client to specify both the "d"
- right and one or more members of the "delete" right, but the effect
- is no different than if just the "d" right or all members of the
- "delete" right had been specified.)
-
-
-
-Melnikov Standards Track [Page 5]
-
-RFC 4314 IMAP ACL December 2005
-
-
- When any of the "delete" member rights is set in a list of rights,
- the server MUST also include the "d" right when returning the list in
- a MYRIGHTS or ACL response. This is to enable older clients
- conforming to RFC 2086 to work with newer servers. (*)
-
- Example: C: A001 SeTacl INBOX/Drafts David lrswida
- S: A001 OK Setacl complete
-
- The client has specified the "d" right in the SETACL command above
- and it expands to "et" on the server:
-
- C: A002 getacl INBOX/Drafts
- S: * ACL INBOX Fred rwipslxcetda David lrswideta
- S: A002 OK Getacl complete
-
- If the identifier specified in the LISTRIGHTS command can be granted
- any of the "delete" member rights on a mailbox, then the server MUST
- include the "d" right in the corresponding LISTRIGHTS response. (*)
- If the member rights aren't tied to non-member rights, then the "d"
- right is returned by itself in the LISTRIGHTS response. If any of
- the member rights needs to be tied to one (or more) non-member right,
- then the "d" right and all of the member rights need to be tied to
- the same non-member right(s) (**).
-
- If a client includes the "c" right in a rights list, then it MUST be
- treated as if the client had included every member of the "create"
- right. (It is not an error for a client to specify both the "c"
- right and one or more members of the "create" right, but the effect
- is no different than if just the "c" right or all members of the
- "create" right had been specified.)
-
- When any of the "create" member rights is set in a list of rights,
- the server MUST also include the "c" right when returning the list in
- a MYRIGHTS or ACL response. This is to enable older clients
- conforming to RFC 2086 to work with newer servers. (*)
-
- Example: C: A003 Setacl INBOX/Drafts Byron lrswikda
- S: A001 OK Setacl complete
- C: A002 getAcl INBOX/Drafts
- S: * ACL INBOX Fred rwipslxcetda Byron lrswikcdeta
- S: A002 OK Getacl complete
-
- The client has specified the "d" right in the SETACL command above
- and it expands to "et" on the server: As the client has specified the
- "k" right (which is a member of the "c" right), the server also
- returns the "c" right.
-
-
-
-
-
-Melnikov Standards Track [Page 6]
-
-RFC 4314 IMAP ACL December 2005
-
-
- If the identifier specified in the LISTRIGHTS command can be granted
- any of the "create" member rights on a mailbox, then the server MUST
- include the "c" right in the corresponding LISTRIGHTS response. (*)
- If the member rights aren't tied to non-member rights, then the "c"
- right is returned by itself in the LISTRIGHTS response. If any of
- the member rights needs to be tied to one (or more) non-member right,
- then the "c" right and all of the member rights need to be tied to
- the same non-member right(s) (**).
-
- Example: The server that ties the rights as follows:
-
- lr s w i p k x t
-
- and c=k
-
- will return:
-
- S: * LISTRIGHTS archive/imap anyone ""
- lr s w i p k x t c d
-
- Example: The server that ties the rights as follows:
-
- lr s w i p k xte
-
- and c=k
-
- will return:
-
- S: * LISTRIGHTS archive/imap anyone ""
- lr s w i p k xte c d
-
- Example: The server that ties the rights as follows:
-
- lr s w i p k x te
-
- and c=k
-
- will return:
-
- S: * LISTRIGHTS archive/imap anyone ""
- lr s w i p k c x te d
-
- Example: The server that ties the rights as follows:
-
- lr swte i p k x
-
- and c=kx
-
-
-
-
-Melnikov Standards Track [Page 7]
-
-RFC 4314 IMAP ACL December 2005
-
-
- will return:
-
- S: * LISTRIGHTS archive/imap anyone ""
- lr swted i p k x c
-
- (*) Clients conforming to this document MUST ignore the virtual "d"
- and "c" rights in MYRIGHTS, ACL, and LISTRIGHTS responses.
-
- (**) The IMAPEXT Working Group has debated this issue in great length
- and after reviewing existing ACL implementations concluded that
- this is a reasonable restriction.
-
-2.2. Rights Defined in RFC 2086
-
- The "RIGHTS=" capability MUST NOT include any of the rights defined
- in RFC 2086: "l", "r", "s", "w", "i", "p", "a", "c", "d", and the
- digits ("0" .. "9").
-
-3. Access control management commands and responses
-
- Servers, when processing a command that has an identifier as a
- parameter (i.e., any of SETACL, DELETEACL, and LISTRIGHTS commands),
- SHOULD first prepare the received identifier using "SASLprep" profile
- [SASLprep] of the "stringprep" algorithm [Stringprep]. If the
- preparation of the identifier fails or results in an empty string,
- the server MUST refuse to perform the command with a BAD response.
- Note that Section 6 recommends additional identifier's verification
- steps.
-
-3.1. SETACL Command
-
- Arguments: mailbox name
- identifier
- access right modification
-
- Data: no specific data for this command
-
- Result: OK - setacl completed
- NO - setacl failure: can't set acl
- BAD - arguments invalid
-
- The SETACL command changes the access control list on the specified
- mailbox so that the specified identifier is granted permissions as
- specified in the third argument.
-
- The third argument is a string containing an optional plus ("+") or
- minus ("-") prefix, followed by zero or more rights characters. If
- the string starts with a plus, the following rights are added to any
-
-
-
-Melnikov Standards Track [Page 8]
-
-RFC 4314 IMAP ACL December 2005
-
-
- existing rights for the identifier. If the string starts with a
- minus, the following rights are removed from any existing rights for
- the identifier. If the string does not start with a plus or minus,
- the rights replace any existing rights for the identifier.
-
- Note that an unrecognized right MUST cause the command to return the
- BAD response. In particular, the server MUST NOT silently ignore
- unrecognized rights.
-
- Example: C: A001 GETACL INBOX/Drafts
- S: * ACL INBOX/Drafts Fred rwipslxetad Chris lrswi
- S: A001 OK Getacl complete
- C: A002 SETACL INBOX/Drafts Chris +cda
- S: A002 OK Setacl complete
- C: A003 GETACL INBOX/Drafts
- S: * ACL INBOX/Drafts Fred rwipslxetad Chris lrswicdakxet
- S: A003 OK Getacl complete
-
-
- C: A035 SETACL INBOX/Drafts John lrQswicda
- S: A035 BAD Uppercase rights are not allowed
-
-
- C: A036 SETACL INBOX/Drafts John lrqswicda
- S: A036 BAD The q right is not supported
-
-3.2. DELETEACL Command
-
- Arguments: mailbox name
- identifier
-
- Data: no specific data for this command
-
- Result: OK - deleteacl completed
- NO - deleteacl failure: can't delete acl
- BAD - arguments invalid
-
- The DELETEACL command removes any <identifier,rights> pair for the
- specified identifier from the access control list for the specified
- mailbox.
-
- Example: C: B001 getacl INBOX
- S: * ACL INBOX Fred rwipslxetad -Fred wetd $team w
- S: B001 OK Getacl complete
- C: B002 DeleteAcl INBOX Fred
- S: B002 OK Deleteacl complete
-
-
-
-
-
-Melnikov Standards Track [Page 9]
-
-RFC 4314 IMAP ACL December 2005
-
-
- C: B003 GETACL INBOX
- S: * ACL INBOX -Fred wetd $team w
- S: B003 OK Getacl complete
-
-3.3. GETACL Command
-
- Arguments: mailbox name
-
- Data: untagged responses: ACL
-
- Result: OK - getacl completed
- NO - getacl failure: can't get acl
- BAD - arguments invalid
-
- The GETACL command returns the access control list for mailbox in an
- untagged ACL response.
-
- Some implementations MAY permit multiple forms of an identifier to
- reference the same IMAP account. Usually, such implementations will
- have a canonical form that is stored internally. An ACL response
- caused by a GETACL command MAY include a canonicalized form of the
- identifier that might be different from the one used in the
- corresponding SETACL command.
-
- Example: C: A002 GETACL INBOX
- S: * ACL INBOX Fred rwipsldexta
- S: A002 OK Getacl complete
-
-3.4. LISTRIGHTS Command
-
- Arguments: mailbox name
- identifier
-
- Data: untagged responses: LISTRIGHTS
-
- Result: OK - listrights completed
- NO - listrights failure: can't get rights list
- BAD - arguments invalid
-
- The LISTRIGHTS command takes a mailbox name and an identifier and
- returns information about what rights can be granted to the
- identifier in the ACL for the mailbox.
-
- Some implementations MAY permit multiple forms of an identifier to
- reference the same IMAP account. Usually, such implementations will
- have a canonical form that is stored internally. A LISTRIGHTS
-
-
-
-
-
-Melnikov Standards Track [Page 10]
-
-RFC 4314 IMAP ACL December 2005
-
-
- response caused by a LISTRIGHTS command MUST always return the same
- form of an identifier as specified by the client. This is to allow
- the client to correlate the response with the command.
-
- Example: C: a001 LISTRIGHTS ~/Mail/saved smith
- S: * LISTRIGHTS ~/Mail/saved smith la r swicdkxte
- S: a001 OK Listrights completed
-
- Example: C: a005 listrights archive/imap anyone
- S: * LISTRIGHTS archive.imap anyone ""
- l r s w i p k x t e c d a 0 1 2 3 4 5 6 7 8 9
- S: a005 Listrights successful
-
-3.5. MYRIGHTS Command
-
- Arguments: mailbox name
-
- Data: untagged responses: MYRIGHTS
-
- Result: OK - myrights completed
- NO - myrights failure: can't get rights
- BAD - arguments invalid
-
- The MYRIGHTS command returns the set of rights that the user has to
- mailbox in an untagged MYRIGHTS reply.
-
- Example: C: A003 MYRIGHTS INBOX
- S: * MYRIGHTS INBOX rwiptsldaex
- S: A003 OK Myrights complete
-
-3.6. ACL Response
-
- Data: mailbox name
- zero or more identifier rights pairs
-
- The ACL response occurs as a result of a GETACL command. The first
- string is the mailbox name for which this ACL applies. This is
- followed by zero or more pairs of strings; each pair contains the
- identifier for which the entry applies followed by the set of rights
- that the identifier has.
-
- Section 2.1.1 details additional server requirements related to
- handling of the virtual "d" and "c" rights.
-
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 11]
-
-RFC 4314 IMAP ACL December 2005
-
-
-3.7. LISTRIGHTS Response
-
- Data: mailbox name
- identifier
- required rights
- list of optional rights
-
- The LISTRIGHTS response occurs as a result of a LISTRIGHTS command.
- The first two strings are the mailbox name and identifier for which
- this rights list applies. Following the identifier is a string
- containing the (possibly empty) set of rights the identifier will
- always be granted in the mailbox.
-
- Following this are zero or more strings each containing a set of
- rights the identifier can be granted in the mailbox. Rights
- mentioned in the same string are tied together. The server MUST
- either grant all tied rights to the identifier in the mailbox or
- grant none. Section 2.1.1 details additional server requirements
- related to handling of the virtual "d" and "c" rights.
-
- The same right MUST NOT be listed more than once in the LISTRIGHTS
- command.
-
-3.8. MYRIGHTS Response
-
- Data: mailbox name
- rights
-
- The MYRIGHTS response occurs as a result of a MYRIGHTS command. The
- first string is the mailbox name for which these rights apply. The
- second string is the set of rights that the client has.
-
- Section 2.1.1 details additional server requirements related to
- handling of the virtual "d" and "c" rights.
-
-4. Rights Required to Perform Different IMAP4rev1 Commands
-
- Before executing a command, an ACL-compliant server MUST check which
- rights are required to perform it. This section groups command by
- functions they perform and list the rights required. It also gives
- the detailed description of any special processing required.
-
- For the purpose of this section the UID counterpart of a command is
- considered to be the same command, e.g., both UID COPY and COPY
- commands require the same set of rights.
-
-
-
-
-
-
-Melnikov Standards Track [Page 12]
-
-RFC 4314 IMAP ACL December 2005
-
-
- The table below summarizes different rights or their combinations
- that are required in order to perform different IMAP operations. As
- it is not always possible to express complex right checking and
- interactions, the description after the table should be used as the
- primary reference.
-
- +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+
- |Operations\Rights | l | r | s | w | i | k | x | t | e | a |Any|Non|
- +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+
- | commands in authenticated state |
- +-------------------------------------------------------------------+
- | LIST | + | | | | | | | | | | | |
- | SUBSCRIBE | * | | | | | | | | | | | * |
- | UNSUBSCRIBE | | | | | | | | | | | | + |
- | LSUB | * | | | | | | | | | | | * |
- |CREATE (for parent)| | | | | | + | | | | | | |
- | DELETE | | ? | | | | | + | ? | ? | | | |
- | RENAME | | | | | | + | + | | | | | |
- | SELECT/EXAMINE | | + | | | | | | | | | | |
- | STATUS | | + | | | | | | | | | | |
- | SETACL/DELETEACL | | | | | | | | | | + | | |
- | GETACL/LISTRIGHTS | | | | | | | | | | + | | |
- | MYRIGHTS | | | | | | | | | | | + | |
- | APPEND | | | ? | ? | + | | | ? | | | | |
- +-------------------------------------------------------------------+
- | commands in selected state |
- +-------------------------------------------------------------------+
- | COPY | | | ? | ? | + | | | ? | | | | |
- | EXPUNGE | | | | | | | | | + | | | |
- | CLOSE | | | | | | | | | ? | | | |
- | FETCH | | | ? | | | | | | | | | |
- | STORE flags | | | ? | ? | | | | ? | | | | |
- +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+
-
- Note: for all commands in the selected state, the "r" is implied,
- because it is required to SELECT/EXAMINE a mailbox. Servers are not
- required to check presence of the "r" right once a mailbox is
- successfully selected.
-
- Legend:
- + - The right is required
- * - Only one of the rights marked with * is required
- (see description below)
- ? - The right is OPTIONAL (see description below)
- "Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is
- required
- "Non" - No rights required to perform the command
-
-
-
-
-Melnikov Standards Track [Page 13]
-
-RFC 4314 IMAP ACL December 2005
-
-
- Listing and subscribing/unsubscribing mailboxes:
- LIST - "l" right is required. However, unlike other commands
- (e.g., SELECT) the server MUST NOT return a NO response if it
- can't list a mailbox.
- Note that if the user has "l" right to a mailbox "A/B", but not to
- its parent mailbox "A", the LIST command should behave as if the
- mailbox "A" doesn't exist, for example:
-
- C: A777 LIST "" *
- S: * LIST (\NoInferiors) "/" "A/B"
- S: * LIST () "/" "C"
- S: * LIST (\NoInferiors) "/" "C/D"
- S: A777 OK LIST completed
-
-
- SUBSCRIBE - "l" right is required only if the server checks for
- mailbox existence when performing SUBSCRIBE.
-
- UNSUBSCRIBE - no rights required to perform this operation.
-
- LSUB - "l" right is required only if the server checks for mailbox
- existence when performing SUBSCRIBE. However, unlike other
- commands (e.g., SELECT) the server MUST NOT return a NO response
- if it can't list a subscribed mailbox.
-
- Mailbox management:
- CREATE - "k" right on a nearest existing parent mailbox. When a
- new mailbox is created, it SHOULD inherit the ACL from the parent
- mailbox (if one exists) in the defined hierarchy.
-
- DELETE - "x" right on the mailbox. Note that some servers don't
- allow to delete a non-empty mailbox. If this is the case, the
- user would also need "r", "e", and "t" rights, in order to open
- the mailbox and empty it.
-
- The DELETE command MUST delete the ACL associated with the deleted
- mailbox.
-
- RENAME - Moving a mailbox from one parent to another requires the
- "x" right on the mailbox itself and the "k" right for the new
- parent. For example, if the user wants to rename the mailbox
- named "A/B/C" to "D/E", the user must have the "x" right for the
- mailbox "A/B/C" and the "k" right for the mailbox "D".
- The RENAME command SHOULD NOT change the ACLs on the renamed
- mailbox and submailboxes.
-
-
-
-
-
-
-Melnikov Standards Track [Page 14]
-
-RFC 4314 IMAP ACL December 2005
-
-
- Copying or appending messages:
- Before performing a COPY/APPEND command, the server MUST check if
- the user has "i" right for the target mailbox. If the user
- doesn't have "i" right, the operation fails. Otherwise for each
- copied/appended message the server MUST check if the user has
- "t" right - when the message has \Deleted flag set
- "s" right - when the message has \Seen flag set
- "w" right - for all other message flags.
- Only when the user has a particular right are the corresponding
- flags stored for the newly created message. The server MUST NOT
- fail a COPY/APPEND if the user has no rights to set a particular
- flag.
-
- Example: C: A003 MYRIGHTS TargetMailbox
- S: * MYRIGHTS TargetMailbox rwis
- S: A003 OK Myrights complete
-
- C: A004 FETCH 1:3 (FLAGS)
- S: * 1 FETCH (FLAGS (\Draft \Deleted)
- S: * 2 FETCH (FLAGS (\Answered)
- S: * 3 FETCH (FLAGS ($Forwarded \Seen)
- S: A004 OK Fetch Completed
-
- C: A005 COPY 1:3 TargetMailbox
- S: A005 OK Copy completed
-
- C: A006 SELECT TargetMailbox
- ...
- S: A006 Select Completed
-
- Let's assume that the copied messages received message numbers
- 77:79.
-
- C: A007 FETCH 77:79 (FLAGS)
- S: * 77 FETCH (FLAGS (\Draft))
- S: * 78 FETCH (FLAGS (\Answered))
- S: * 79 FETCH (FLAGS ($Forwarded \Seen))
- S: A007 OK Fetch Completed
-
- \Deleted flag was lost on COPY, as the user has no "t" right in
- the target mailbox.
- If the MYRIGHTS command with the tag A003 would have returned:
-
- S: * MYRIGHTS TargetMailbox rsti
-
- the response from the FETCH with the tag A007 would have been:
-
- C: A007 FETCH 77:79 (FLAGS)
-
-
-
-Melnikov Standards Track [Page 15]
-
-RFC 4314 IMAP ACL December 2005
-
-
- S: * 77 FETCH (FLAGS (\Deleted))
- S: * 78 FETCH (FLAGS ())
- S: * 79 FETCH (FLAGS (\Seen))
- S: A007 OK Fetch Completed
-
- In the latter case, \Answered, $Forwarded, and \Draft flags were
- lost on COPY, as the user has no "w" right in the target mailbox.
-
- Expunging the selected mailbox:
- EXPUNGE - "e" right on the selected mailbox.
-
- CLOSE - "e" right on the selected mailbox. If the server is
- unable to expunge the mailbox because the user doesn't have the
- "e" right, the server MUST ignore the expunge request, close the
- mailbox, and return the tagged OK response.
-
- Fetch information about a mailbox and its messages:
- SELECT/EXAMINE/STATUS - "r" right on the mailbox.
-
- FETCH - A FETCH request that implies setting \Seen flag MUST NOT
- set it, if the current user doesn't have "s" right.
-
- Changing flags:
- STORE - the server MUST check if the user has
- "t" right - when the user modifies \Deleted flag
- "s" right - when the user modifies \Seen flag
- "w" right - for all other message flags.
- STORE operation SHOULD NOT fail if the user has rights to modify
- at least one flag specified in the STORE, as the tagged NO
- response to a STORE command is not handled very well by deployed
- clients.
-
- Changing ACLs:
- SETACL/DELETEACL - "a" right on the mailbox.
-
- Reading ACLs:
- GETACL - "a" right on the mailbox.
-
- MYRIGHTS - any of the following rights is required to perform the
- operation: "l", "r", "i", "k", "x", "a".
-
- LISTRIGHTS - "a" right on the mailbox.
-
-
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 16]
-
-RFC 4314 IMAP ACL December 2005
-
-
-5. Other Considerations
-
-5.1. Additional Requirements and Implementation Notes
-
-5.1.1. Servers
-
- This document defines an additional capability that is used to
- announce the list of extra rights (excluding the ones defined in RFC
- 2086) supported by the server. The set of rights MUST include "t",
- "e", "x", and "k". Note that the extra rights can appear in any
- order.
-
- Example: C: 1 capability
- S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+
- ACL RIGHTS=texk
- S: 1 OK completed
-
- Any server implementing an ACL extension MUST accurately reflect the
- current user's rights in FLAGS and PERMANENTFLAGS responses.
-
- 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: * OK [UIDNEXT 4392] Predicted next UID
- S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
- S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L
- S: A142 OK [READ-WRITE] SELECT completed
- C: A143 MYRIGHTS INBOX
- S: * MYRIGHTS INBOX lrwis
- S: A143 OK completed
-
- Note that in order to get better performance the client MAY pipeline
- SELECT and MYRIGHTS commands:
-
- C: A142 SELECT INBOX
- C: A143 MYRIGHTS INBOX
- S: * 172 EXISTS
- S: * 1 RECENT
- S: * OK [UNSEEN 12] Message 12 is first unseen
- S: * OK [UIDVALIDITY 3857529045] UIDs valid
- S: * OK [UIDNEXT 4392] Predicted next UID
- S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
- S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L
- S: A142 OK [READ-WRITE] SELECT completed
- S: * MYRIGHTS INBOX lrwis
- S: A143 OK completed
-
-
-
-Melnikov Standards Track [Page 17]
-
-RFC 4314 IMAP ACL December 2005
-
-
- Servers MAY cache the rights a user has on a mailbox when the mailbox
- is selected, so that if a client's rights on a mailbox are changed
- with SETACL or DELETEACL, commands specific to the selected state
- (e.g., STORE, EXPUNGE) might not reflect the changed rights until the
- mailbox is re-selected. If the server checks the rights on each
- command, then it SHOULD send FLAGS and PERMANENTFLAGS responses if
- they have changed. If such server detects that the user no longer
- has read access to the mailbox, it MAY send an untagged BYE response
- and close connection. It MAY also refuse to execute all commands
- specific to the selected state until the mailbox is closed; however,
- server implementors should note that most clients don't handle NO
- responses very well.
-
- An ACL server MAY modify one or more ACLs for one or more identifiers
- as a side effect of modifying the ACL specified in a
- SETACL/DELETEACL. If the server does that, it MUST send untagged ACL
- response(s) to notify the client about the changes made.
-
- An ACL server implementation MUST treat received ACL modification
- commands as a possible ambiguity with respect to subsequent commands
- affected by the ACL, as described in Section 5.5 of [IMAP4]. Hence a
- pipeline SETACL + MYRIGHTS is an ambiguity with respect to the
- server, meaning that the server must execute the SETACL command to
- completion before the MYRIGHTS. However, clients are permitted to
- send such a pipeline.
-
-5.1.2. Clients
-
- The following requirement is put on clients in order to allow for
- future extensibility. A client implementation that allows a user to
- read and update ACLs MUST preserve unrecognized rights that it
- doesn't allow the user to change. That is, if the client
-
- 1) can read ACLs
- and
- 2) can update ACLs
- but
- 3) doesn't allow the user to change the rights the client doesn't
- recognize, then it MUST preserve unrecognized rights.
-
- Otherwise the client could risk unintentionally removing permissions
- it doesn't understand.
-
-
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 18]
-
-RFC 4314 IMAP ACL December 2005
-
-
-5.2. Mapping of ACL Rights to READ-WRITE and READ-ONLY Response Codes
-
- A particular ACL server implementation MAY allow "shared multiuser
- access" to some mailboxes. "Shared multiuser access" to a mailbox
- means that multiple different users are able to access the same
- mailbox, if they have proper access rights. "Shared multiuser
- access" to the mailbox doesn't mean that the ACL for the mailbox is
- currently set to allow access by multiple users. Let's denote a
- "shared multiuser write access" as a "shared multiuser access" when a
- user can be granted flag modification rights (any of "w", "s", or
- "t").
-
- Section 4 describes which rights are required for modifying different
- flags.
-
- If the ACL server implements some flags as shared for a mailbox
- (i.e., the ACL for the mailbox MAY be set up so that changes to those
- flags are visible to another user), let's call the set of rights
- associated with these flags (as described in Section 4) for that
- mailbox collectively as "shared flag rights". Note that the "shared
- flag rights" set MAY be different for different mailboxes.
-
- If the server doesn't support "shared multiuser write access" to a
- mailbox or doesn't implement shared flags on the mailbox, "shared
- flag rights" for the mailbox is defined to be the empty set.
-
- Example 1: Mailbox "banan" allows "shared multiuser write access" and
- implements flags \Deleted, \Answered, and $MDNSent as
- shared flags. "Shared flag rights" for the mailbox "banan"
- is a set containing flags "t" (because system flag
- \Deleted requires "t" right) and "w" (because both
- \Answered and $MDNSent require "w" right).
-
- Example 2: Mailbox "apple" allows "shared multiuser write access" and
- implements \Seen system flag as shared flag. "Shared flag
- rights" for the mailbox "apple" contains "s" right
- because system flag \Seen requires "s" right.
-
- Example 3: Mailbox "pear" allows "shared multiuser write access" and
- implements flags \Seen, \Draft as shared flags. "Shared
- flag rights" for the mailbox "apple" is a set containing
- flags "s" (because system flag \Seen requires "s" right)
- and "w" (because system flag \Draft requires "w" right).
-
- The server MUST include a READ-ONLY response code in the tagged OK
- response to a SELECT command if none of the following rights is
- granted to the current user:
-
-
-
-
-Melnikov Standards Track [Page 19]
-
-RFC 4314 IMAP ACL December 2005
-
-
- "i", "e", and "shared flag rights"(***).
-
- The server SHOULD include a READ-WRITE response code in the tagged OK
- response if at least one of the "i", "e", or "shared flag
- rights"(***) is granted to the current user.
-
- (***) Note that a future extension to this document can extend the
- list of rights that causes the server to return the READ-WRITE
- response code.
-
- Example 1 (continued): The user that has "lrs" rights for the mailbox
- "banan". The server returns READ-ONLY
- response code on SELECT, as none of "iewt"
- rights is granted to the user.
-
- Example 2 (continued): The user that has "rit" rights for the mailbox
- "apple". The server returns READ-WRITE
- response code on SELECT, as the user has "i"
- right.
-
- Example 3 (continued): The user that has "rset" rights for the
- mailbox "pear". The server returns READ-WRITE
- response code on SELECT, as the user has "e"
- and "s" rights.
-
-6. Security Considerations
-
- An implementation MUST make sure the ACL commands themselves do not
- give information about mailboxes with appropriately restricted ACLs.
- For example, when a user agent executes a GETACL command on a mailbox
- that the user has no permission to LIST, the server would respond to
- that request with the same error that would be used if the mailbox
- did not exist, thus revealing no existence information, much less the
- mailbox's ACL.
-
- IMAP clients implementing ACL that are able to modify ACLs SHOULD
- warn a user that wants to give full access (or even just the "a"
- right) to the special identifier "anyone".
-
- This document relies on [SASLprep] to describe steps required to
- perform identifier canonicalization (preparation). The preparation
- algorithm in SASLprep was specifically designed such that its output
- is canonical, and it is well-formed. However, due to an anomaly
- [PR29] in the specification of Unicode normalization, canonical
- equivalence is not guaranteed for a select few character sequences.
- Identifiers prepared with SASLprep can be stored and returned by an
- ACL server. The anomaly affects ACL manipulation and evaluation of
- identifiers containing the selected character sequences. These
-
-
-
-Melnikov Standards Track [Page 20]
-
-RFC 4314 IMAP ACL December 2005
-
-
- sequences, however, do not appear in well-formed text. In order to
- address this problem, an ACL server MAY reject identifiers containing
- sequences described in [PR29] by sending the tagged BAD response.
- This is in addition to the requirement to reject identifiers that
- fail SASLprep preparation as described in Section 3.
-
- Other security considerations described in [IMAP4] are relevant to
- this document. In particular, ACL information is sent in the clear
- over the network unless confidentiality protection is negotiated.
-
- This can be accomplished either by the use of STARTTLS, negotiated
- privacy protection in the AUTHENTICATE command, or some other
- protection mechanism.
-
-7. Formal Syntax
-
- Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
- in Section 9 of [IMAP4]. Elements not defined here can be found in
- [ABNF] and [IMAP4].
-
- Except as noted otherwise, all alphabetic characters are case
- insensitive. The use of uppercase or lowercase characters to define
- token strings is for editorial clarity only. Implementations MUST
- accept these strings in a case-insensitive fashion.
-
- LOWER-ALPHA = %x61-7A ;; a-z
-
- acl-data = "ACL" SP mailbox *(SP identifier SP
- rights)
-
- capability =/ rights-capa
- ;;capability is defined in [IMAP4]
-
- command-auth =/ setacl / deleteacl / getacl /
- listrights / myrights
- ;;command-auth is defined in [IMAP4]
-
- deleteacl = "DELETEACL" SP mailbox SP identifier
-
- getacl = "GETACL" SP mailbox
-
- identifier = astring
-
- listrights = "LISTRIGHTS" SP mailbox SP identifier
-
- listrights-data = "LISTRIGHTS" SP mailbox SP identifier
- SP rights *(SP rights)
-
-
-
-
-Melnikov Standards Track [Page 21]
-
-RFC 4314 IMAP ACL December 2005
-
-
- mailbox-data =/ acl-data / listrights-data / myrights-data
- ;;mailbox-data is defined in [IMAP4]
-
- mod-rights = astring
- ;; +rights to add, -rights to remove
- ;; rights to replace
-
- myrights = "MYRIGHTS" SP mailbox
-
- myrights-data = "MYRIGHTS" SP mailbox SP rights
-
- new-rights = 1*LOWER-ALPHA
- ;; MUST include "t", "e", "x", and "k".
- ;; MUST NOT include standard rights listed
- ;; in section 2.2
-
- rights = astring
- ;; only lowercase ASCII letters and digits
- ;; are allowed.
-
- rights-capa = "RIGHTS=" new-rights
- ;; RIGHTS=... capability
-
- setacl = "SETACL" SP mailbox SP identifier
- SP mod-rights
-
-8. IANA Considerations
-
- IMAP4 capabilities are registered by publishing a standards-track or
- IESG-approved experimental RFC. The registry is currently located
- at:
-
- http://www.iana.org/assignments/imap4-capabilities
-
- This document defines the RIGHTS= IMAP capability. IANA has added
- this capability to the registry.
-
-9. Internationalization Considerations
-
- Section 3 states requirements on servers regarding
- internationalization of identifiers.
-
-
-
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 22]
-
-RFC 4314 IMAP ACL December 2005
-
-
-Appendix A. Changes since RFC 2086
-
- 1. Changed the charset of "identifier" from US-ASCII to UTF-8.
- 2. Specified that mailbox deletion is controlled by the "x" right
- and EXPUNGE is controlled by the "e" right.
- 3. Added the "t" right that controls STORE \Deleted. Redefined the
- "d" right to be a macro for "e", "t", and possibly "x".
- 4. Added the "k" right that controls CREATE. Redefined the "c"
- right to be a macro for "k" and possibly "x".
- 5. Specified that the "a" right also controls DELETEACL.
- 6. Specified that the "r" right also controls STATUS.
- 7. Removed the requirement to check the "r" right for CHECK, SEARCH
- and FETCH, as this is required for SELECT/EXAMINE to be
- successful.
- 8. LISTRIGHTS requires the "a" right on the mailbox (same as
- SETACL).
- 9. Deleted "PARTIAL", this is a deprecated feature of RFC 1730.
- 10. Specified that the "w" right controls setting flags other than
- \Seen and \Deleted on APPEND. Also specified that the "s" right
- controls the \Seen flag and that the "t" right controls the
- \Deleted flag.
- 11. Specified that SUBSCRIBE is NOT allowed with the "r" right.
- 12. Specified that the "l" right controls SUBSCRIBE.
- 13. GETACL is NOT allowed with the "r" right, even though there are
- several implementations that allows that. If a user only has
- "r" right, GETACL can disclose information about identifiers
- existing on the mail system.
- 14. Clarified that RENAME requires the "k" right for the new parent
- and the "x" right for the old name.
- 15. Added new section that describes which rights are required
- and/or checked when performing various IMAP commands.
- 16. Added mail client security considerations when dealing with
- special identifier "anyone".
- 17. Clarified that negative rights are not the same as DELETEACL.
- 18. Added "Compatibility with RFC 2086" section.
- 19. Added section about mapping of ACL rights to READ-WRITE and
- READ-ONLY response codes.
- 20. Changed BNF to ABNF.
- 21. Added "Implementation Notes" section.
- 22. Updated "References" section.
- 23. Added more examples.
- 24. Clarified when the virtual "c" and "d" rights are returned in
- ACL, MYRIGHTS, and LISTRIGHTS responses.
-
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 23]
-
-RFC 4314 IMAP ACL December 2005
-
-
-Appendix B. Compatibility with RFC 2086
-
- This non-normative section gives guidelines as to how an existing RFC
- 2086 server implementation may be updated to comply with this
- document.
-
- This document splits the "d" right into several new different rights:
- "t", "e", and possibly "x" (see Section 2.1.1 for more details). The
- "d" right remains for backward-compatibility, but it is a virtual
- right. There are two approaches for RFC 2086 server implementors to
- handle the "d" right and the new rights that have replaced it:
-
- a. Tie "t", "e" (and possibly "x) together - almost no changes.
- b. Implement separate "x", "t" and "e". Return the "d" right in a
- MYRIGHTS response or an ACL response containing ACL information
- when any of the "t", "e" (and "x") is granted.
-
- In a similar manner this document splits the "c" right into several
- new different rights: "k" and possibly "x" (see Section 2.1.1 for
- more details). The "c" right remains for backwards-compatibility but
- it is a virtual right. Again, RFC 2086 server implementors can
- choose to tie rights or to implement separate rights, as described
- above.
-
- Also check Sections 5.1.1 and 5.1.2, as well as Appendix A, to see
- other changes required. Server implementors should check which
- rights are required to invoke different IMAP4 commands as described
- in Section 4.
-
-Appendix C. Known Deficiencies
-
- This specification has some known deficiencies including:
-
- 1. This is inadequate to provide complete read-write access to
- mailboxes protected by Unix-style rights bits because there is no
- equivalent to "chown" and "chgrp" commands nor is there a good
- way to discover such limitations are present.
- 2. Because this extension leaves the specific semantics of how
- rights are combined by the server as implementation defined, the
- ability to build a user-friendly interface is limited.
- 3. Users, groups, and special identifiers (e.g., anyone) exist in
- the same namespace.
-
- The work-in-progress "ACL2" extension is intended to redesign this
- extension to address these deficiencies without the constraint of
- backward-compatibility and may eventually supercede this facility.
-
-
-
-
-
-Melnikov Standards Track [Page 24]
-
-RFC 4314 IMAP ACL December 2005
-
-
- However, RFC 2086 is deployed in multiple implementations so this
- intermediate step, which fixes the straightforward deficiencies in a
- backward-compatible fashion, is considered worthwhile.
-
-Appendix D. Acknowledgements
-
- This document is a revision of RFC 2086 written by John G. Myers.
-
- Editor appreciates comments received from Mark Crispin, Chris Newman,
- Cyrus Daboo, John G. Myers, Dave Cridland, Ken Murchison, Steve Hole,
- Vladimir Butenko, Larry Greenfield, Robert Siemborski, Harrie
- Hazewinkel, Philip Guenther, Brian Candler, Curtis King, Lyndon
- Nerenberg, Lisa Dusseault, Arnt Gulbrandsen, and other participants
- of the IMAPEXT working group.
-
-Normative References
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 4234, October 2005.
-
- [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
- 4rev1", RFC 3501, March 2003.
-
- [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", STD 63, RFC 3629, November 2003.
-
- [Stringprep] Hoffman, P. and M. Blanchet, "Preparation of
- Internationalized Strings ("stringprep")", RFC 3454,
- December 2002.
-
- [SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User
- Names and Passwords", RFC 4013, February 2005.
-
-Informative References
-
- [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086,
- January 1997.
-
- [PR29] "Public Review Issue #29: Normalization Issue",
- February 2004,
- <http://www.unicode.org/review/pr-29.html>.
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 25]
-
-RFC 4314 IMAP ACL December 2005
-
-
-Author's Address
-
- Alexey Melnikov
- Isode Ltd.
- 5 Castle Business Village
- 36 Station Road
- Hampton, Middlesex TW12 2BX
- GB
-
- EMail: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 26]
-
-RFC 4314 IMAP ACL December 2005
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2005).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- address@hidden
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 27]
-
diff --git a/doc/rfc/rfc821.txt b/doc/rfc/rfc821.txt
deleted file mode 100644
index d877b72..0000000
--- a/doc/rfc/rfc821.txt
+++ /dev/null
@@ -1,4050 +0,0 @@
-
-
-
- RFC 821
-
-
-
-
-
- SIMPLE MAIL TRANSFER PROTOCOL
-
-
-
- Jonathan B. Postel
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- August 1982
-
-
-
- Information Sciences Institute
- University of Southern California
- 4676 Admiralty Way
- Marina del Rey, California 90291
-
- (213) 822-1511
-
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- TABLE OF CONTENTS
-
- 1. INTRODUCTION .................................................. 1
-
- 2. THE SMTP MODEL ................................................ 2
-
- 3. THE SMTP PROCEDURE ............................................ 4
-
- 3.1. Mail ..................................................... 4
- 3.2. Forwarding ............................................... 7
- 3.3. Verifying and Expanding .................................. 8
- 3.4. Sending and Mailing ..................................... 11
- 3.5. Opening and Closing ..................................... 13
- 3.6. Relaying ................................................ 14
- 3.7. Domains ................................................. 17
- 3.8. Changing Roles .......................................... 18
-
- 4. THE SMTP SPECIFICATIONS ...................................... 19
-
- 4.1. SMTP Commands ........................................... 19
- 4.1.1. Command Semantics ..................................... 19
- 4.1.2. Command Syntax ........................................ 27
- 4.2. SMTP Replies ............................................ 34
- 4.2.1. Reply Codes by Function Group ......................... 35
- 4.2.2. Reply Codes in Numeric Order .......................... 36
- 4.3. Sequencing of Commands and Replies ...................... 37
- 4.4. State Diagrams .......................................... 39
- 4.5. Details ................................................. 41
- 4.5.1. Minimum Implementation ................................ 41
- 4.5.2. Transparency .......................................... 41
- 4.5.3. Sizes ................................................. 42
-
- APPENDIX A: TCP ................................................. 44
- APPENDIX B: NCP ................................................. 45
- APPENDIX C: NITS ................................................ 46
- APPENDIX D: X.25 ................................................ 47
- APPENDIX E: Theory of Reply Codes ............................... 48
- APPENDIX F: Scenarios ........................................... 51
-
- GLOSSARY ......................................................... 64
-
- REFERENCES ....................................................... 67
-
-
-
-
-Network Working Group J. Postel
-Request for Comments: DRAFT ISI
-Replaces: RFC 788, 780, 772 August 1982
-
- SIMPLE MAIL TRANSFER PROTOCOL
-
-
-1. INTRODUCTION
-
- The objective of Simple Mail Transfer Protocol (SMTP) is to transfer
- mail reliably and efficiently.
-
- SMTP is independent of the particular transmission subsystem and
- requires only a reliable ordered data stream channel. Appendices A,
- B, C, and D describe the use of SMTP with various transport services.
- A Glossary provides the definitions of terms as used in this
- document.
-
- An important feature of SMTP is its capability to relay mail across
- transport service environments. A transport service provides an
- interprocess communication environment (IPCE). An IPCE may cover one
- network, several networks, or a subset of a network. It is important
- to realize that transport systems (or IPCEs) are not one-to-one with
- networks. A process can communicate directly with another process
- through any mutually known IPCE. Mail is an application or use of
- interprocess communication. Mail can be communicated between
- processes in different IPCEs by relaying through a process connected
- to two (or more) IPCEs. More specifically, mail can be relayed
- between hosts on different transport systems by a host on both
- transport systems.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Postel [Page 1]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
-2. THE SMTP MODEL
-
- The SMTP design is based on the following model of communication: as
- the result of a user mail request, the sender-SMTP establishes a
- two-way transmission channel to a receiver-SMTP. The receiver-SMTP
- may be either the ultimate destination or an intermediate. SMTP
- commands are generated by the sender-SMTP and sent to the
- receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the
- sender-SMTP in response to the commands.
-
- Once the transmission channel is established, the SMTP-sender sends a
- MAIL command indicating the sender of the mail. If the SMTP-receiver
- can accept mail it responds with an OK reply. The SMTP-sender then
- sends a RCPT command identifying a recipient of the mail. If the
- SMTP-receiver can accept mail for that recipient it responds with an
- OK reply; if not, it responds with a reply rejecting that recipient
- (but not the whole mail transaction). The SMTP-sender and
- SMTP-receiver may negotiate several recipients. When the recipients
- have been negotiated the SMTP-sender sends the mail data, terminating
- with a special sequence. If the SMTP-receiver successfully processes
- the mail data it responds with an OK reply. The dialog is purposely
- lock-step, one-at-a-time.
-
- -------------------------------------------------------------
-
-
- +----------+ +----------+
- +------+ | | | |
- | User |<-->| | SMTP | |
- +------+ | Sender- |Commands/Replies| Receiver-|
- +------+ | SMTP |<-------------->| SMTP | +------+
- | File |<-->| | and Mail | |<-->| File |
- |System| | | | | |System|
- +------+ +----------+ +----------+ +------+
-
-
- Sender-SMTP Receiver-SMTP
-
- Model for SMTP Use
-
- Figure 1
-
- -------------------------------------------------------------
-
- The SMTP provides mechanisms for the transmission of mail; directly
- from the sending user's host to the receiving user's host when the
-
-
-
-[Page 2] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- two host are connected to the same transport service, or via one or
- more relay SMTP-servers when the source and destination hosts are not
- connected to the same transport service.
-
- To be able to provide the relay capability the SMTP-server must be
- supplied with the name of the ultimate destination host as well as
- the destination mailbox name.
-
- The argument to the MAIL command is a reverse-path, which specifies
- who the mail is from. The argument to the RCPT command is a
- forward-path, which specifies who the mail is to. The forward-path
- is a source route, while the reverse-path is a return route (which
- may be used to return a message to the sender when an error occurs
- with a relayed message).
-
- When the same message is sent to multiple recipients the SMTP
- encourages the transmission of only one copy of the data for all the
- recipients at the same destination host.
-
- The mail commands and replies have a rigid syntax. Replies also have
- a numeric code. In the following, examples appear which use actual
- commands and replies. The complete lists of commands and replies
- appears in Section 4 on specifications.
-
- Commands and replies are not case sensitive. That is, a command or
- reply word may be upper case, lower case, or any mixture of upper and
- lower case. Note that this is not true of mailbox user names. For
- some hosts the user name is case sensitive, and SMTP implementations
- must take case to preserve the case of user names as they appear in
- mailbox arguments. Host names are not case sensitive.
-
- Commands and replies are composed of characters from the ASCII
- character set [1]. When the transport service provides an 8-bit byte
- (octet) transmission channel, each 7-bit character is transmitted
- right justified in an octet with the high order bit cleared to zero.
-
- When specifying the general form of a command or reply, an argument
- (or special symbol) will be denoted by a meta-linguistic variable (or
- constant), for example, "<string>" or "<reverse-path>". Here the
- angle brackets indicate these are meta-linguistic variables.
- However, some arguments use the angle brackets literally. For
- example, an actual reverse-path is enclosed in angle brackets, i.e.,
- "<address@hidden>" is an instance of <reverse-path> (the
- angle brackets are actually transmitted in the command or reply).
-
-
-
-
-
-Postel [Page 3]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
-3. THE SMTP PROCEDURES
-
- This section presents the procedures used in SMTP in several parts.
- First comes the basic mail procedure defined as a mail transaction.
- Following this are descriptions of forwarding mail, verifying mailbox
- names and expanding mailing lists, sending to terminals instead of or
- in combination with mailboxes, and the opening and closing exchanges.
- At the end of this section are comments on relaying, a note on mail
- domains, and a discussion of changing roles. Throughout this section
- are examples of partial command and reply sequences, several complete
- scenarios are presented in Appendix F.
-
- 3.1. MAIL
-
- There are three steps to SMTP mail transactions. The transaction
- is started with a MAIL command which gives the sender
- identification. A series of one or more RCPT commands follows
- giving the receiver information. Then a DATA command gives the
- mail data. And finally, the end of mail data indicator confirms
- the transaction.
-
- The first step in the procedure is the MAIL command. The
- <reverse-path> contains the source mailbox.
-
- MAIL <SP> FROM:<reverse-path> <CRLF>
-
- This command tells the SMTP-receiver that a new mail
- transaction is starting and to reset all its state tables and
- buffers, including any recipients or mail data. It gives the
- reverse-path which can be used to report errors. If accepted,
- the receiver-SMTP returns a 250 OK reply.
-
- The <reverse-path> can contain more than just a mailbox. The
- <reverse-path> is a reverse source routing list of hosts and
- source mailbox. The first host in the <reverse-path> should be
- the host sending this command.
-
- The second step in the procedure is the RCPT command.
-
- RCPT <SP> TO:<forward-path> <CRLF>
-
- This command gives a forward-path identifying one recipient.
- If accepted, the receiver-SMTP returns a 250 OK reply, and
- stores the forward-path. If the recipient is unknown the
- receiver-SMTP returns a 550 Failure reply. This second step of
- the procedure can be repeated any number of times.
-
-
-
-[Page 4] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- The <forward-path> can contain more than just a mailbox. The
- <forward-path> is a source routing list of hosts and the
- destination mailbox. The first host in the <forward-path>
- should be the host receiving this command.
-
- The third step in the procedure is the DATA command.
-
- DATA <CRLF>
-
- If accepted, the receiver-SMTP returns a 354 Intermediate reply
- and considers all succeeding lines to be the message text.
- When the end of text is received and stored the SMTP-receiver
- sends a 250 OK reply.
-
- Since the mail data is sent on the transmission channel the end
- of the mail data must be indicated so that the command and
- reply dialog can be resumed. SMTP indicates the end of the
- mail data by sending a line containing only a period. A
- transparency procedure is used to prevent this from interfering
- with the user's text (see Section 4.5.2).
-
- Please note that the mail data includes the memo header
- items such as Date, Subject, To, Cc, From [2].
-
- The end of mail data indicator also confirms the mail
- transaction and tells the receiver-SMTP to now process the
- stored recipients and mail data. If accepted, the
- receiver-SMTP returns a 250 OK reply. The DATA command should
- fail only if the mail transaction was incomplete (for example,
- no recipients), or if resources are not available.
-
- The above procedure is an example of a mail transaction. These
- commands must be used only in the order discussed above.
- Example 1 (below) illustrates the use of these commands in a mail
- transaction.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Postel [Page 5]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- -------------------------------------------------------------
-
- Example of the SMTP Procedure
-
- This SMTP example shows mail sent by Smith at host Alpha.ARPA,
- to Jones, Green, and Brown at host Beta.ARPA. Here we assume
- that host Alpha contacts host Beta directly.
-
- S: MAIL FROM:<address@hidden>
- R: 250 OK
-
- S: RCPT TO:<address@hidden>
- R: 250 OK
-
- S: RCPT TO:<address@hidden>
- R: 550 No such user here
-
- S: RCPT TO:<address@hidden>
- R: 250 OK
-
- S: DATA
- R: 354 Start mail input; end with <CRLF>.<CRLF>
- S: Blah blah blah...
- S: ...etc. etc. etc.
- S: <CRLF>.<CRLF>
- R: 250 OK
-
- The mail has now been accepted for Jones and Brown. Green did
- not have a mailbox at host Beta.
-
- Example 1
-
- -------------------------------------------------------------
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 6] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- 3.2. FORWARDING
-
- There are some cases where the destination information in the
- <forward-path> is incorrect, but the receiver-SMTP knows the
- correct destination. In such cases, one of the following replies
- should be used to allow the sender to contact the correct
- destination.
-
- 251 User not local; will forward to <forward-path>
-
- This reply indicates that the receiver-SMTP knows the user's
- mailbox is on another host and indicates the correct
- forward-path to use in the future. Note that either the
- host or user or both may be different. The receiver takes
- responsibility for delivering the message.
-
- 551 User not local; please try <forward-path>
-
- This reply indicates that the receiver-SMTP knows the user's
- mailbox is on another host and indicates the correct
- forward-path to use. Note that either the host or user or
- both may be different. The receiver refuses to accept mail
- for this user, and the sender must either redirect the mail
- according to the information provided or return an error
- response to the originating user.
-
- Example 2 illustrates the use of these responses.
-
- -------------------------------------------------------------
-
- Example of Forwarding
-
- Either
-
- S: RCPT TO:<address@hidden>
- R: 251 User not local; will forward to <address@hidden>
-
- Or
-
- S: RCPT TO:<address@hidden>
- R: 551 User not local; please try <address@hidden>
-
- Example 2
-
- -------------------------------------------------------------
-
-
-
-
-Postel [Page 7]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- 3.3. VERIFYING AND EXPANDING
-
- SMTP provides as additional features, commands to verify a user
- name or expand a mailing list. This is done with the VRFY and
- EXPN commands, which have character string arguments. For the
- VRFY command, the string is a user name, and the response may
- include the full name of the user and must include the mailbox of
- the user. For the EXPN command, the string identifies a mailing
- list, and the multiline response may include the full name of the
- users and must give the mailboxes on the mailing list.
-
- "User name" is a fuzzy term and used purposely. If a host
- implements the VRFY or EXPN commands then at least local mailboxes
- must be recognized as "user names". If a host chooses to
- recognize other strings as "user names" that is allowed.
-
- In some hosts the distinction between a mailing list and an alias
- for a single mailbox is a bit fuzzy, since a common data structure
- may hold both types of entries, and it is possible to have mailing
- lists of one mailbox. If a request is made to verify a mailing
- list a positive response can be given if on receipt of a message
- so addressed it will be delivered to everyone on the list,
- otherwise an error should be reported (e.g., "550 That is a
- mailing list, not a user"). If a request is made to expand a user
- name a positive response can be formed by returning a list
- containing one name, or an error can be reported (e.g., "550 That
- is a user name, not a mailing list").
-
- In the case of a multiline reply (normal for EXPN) exactly one
- mailbox is to be specified on each line of the reply. In the case
- of an ambiguous request, for example, "VRFY Smith", where there
- are two Smith's the response must be "553 User ambiguous".
-
- The case of verifying a user name is straightforward as shown in
- example 3.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 8] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- -------------------------------------------------------------
-
- Example of Verifying a User Name
-
- Either
-
- S: VRFY Smith
- R: 250 Fred Smith <address@hidden>
-
- Or
-
- S: VRFY Smith
- R: 251 User not local; will forward to <address@hidden>
-
- Or
-
- S: VRFY Jones
- R: 550 String does not match anything.
-
- Or
-
- S: VRFY Jones
- R: 551 User not local; please try <address@hidden>
-
- Or
-
- S: VRFY Gourzenkyinplatz
- R: 553 User ambiguous.
-
- Example 3
-
- -------------------------------------------------------------
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Postel [Page 9]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- The case of expanding a mailbox list requires a multiline reply as
- shown in example 4.
-
- -------------------------------------------------------------
-
- Example of Expanding a Mailing List
-
- Either
-
- S: EXPN Example-People
- R: 250-Jon Postel <address@hidden>
- R: 250-Fred Fonebone <address@hidden>
- R: 250-Sam Q. Smith <address@hidden>
- R: 250-Quincy Smith <@USC-ISIF.ARPA:address@hidden>
- R: 250-<address@hidden>
- R: 250 <address@hidden>
-
- Or
-
- S: EXPN Executive-Washroom-List
- R: 550 Access Denied to You.
-
- Example 4
-
- -------------------------------------------------------------
-
- The character string arguments of the VRFY and EXPN commands
- cannot be further restricted due to the variety of implementations
- of the user name and mailbox list concepts. On some systems it
- may be appropriate for the argument of the EXPN command to be a
- file name for a file containing a mailing list, but again there is
- a variety of file naming conventions in the Internet.
-
- The VRFY and EXPN commands are not included in the minimum
- implementation (Section 4.5.1), and are not required to work
- across relays when they are implemented.
-
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 10] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- 3.4. SENDING AND MAILING
-
- The main purpose of SMTP is to deliver messages to user's
- mailboxes. A very similar service provided by some hosts is to
- deliver messages to user's terminals (provided the user is active
- on the host). The delivery to the user's mailbox is called
- "mailing", the delivery to the user's terminal is called
- "sending". Because in many hosts the implementation of sending is
- nearly identical to the implementation of mailing these two
- functions are combined in SMTP. However the sending commands are
- not included in the required minimum implementation
- (Section 4.5.1). Users should have the ability to control the
- writing of messages on their terminals. Most hosts permit the
- users to accept or refuse such messages.
-
- The following three command are defined to support the sending
- options. These are used in the mail transaction instead of the
- MAIL command and inform the receiver-SMTP of the special semantics
- of this transaction:
-
- SEND <SP> FROM:<reverse-path> <CRLF>
-
- The SEND command requires that the mail data be delivered to
- the user's terminal. If the user is not active (or not
- accepting terminal messages) on the host a 450 reply may
- returned to a RCPT command. The mail transaction is
- successful if the message is delivered the terminal.
-
- SOML <SP> FROM:<reverse-path> <CRLF>
-
- The Send Or MaiL command requires that the mail data be
- delivered to the user's terminal if the user is active (and
- accepting terminal messages) on the host. If the user is
- not active (or not accepting terminal messages) then the
- mail data is entered into the user's mailbox. The mail
- transaction is successful if the message is delivered either
- to the terminal or the mailbox.
-
- SAML <SP> FROM:<reverse-path> <CRLF>
-
- The Send And MaiL command requires that the mail data be
- delivered to the user's terminal if the user is active (and
- accepting terminal messages) on the host. In any case the
- mail data is entered into the user's mailbox. The mail
- transaction is successful if the message is delivered the
- mailbox.
-
-
-
-Postel [Page 11]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- The same reply codes that are used for the MAIL commands are used
- for these commands.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 12] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- 3.5. OPENING AND CLOSING
-
- At the time the transmission channel is opened there is an
- exchange to ensure that the hosts are communicating with the hosts
- they think they are.
-
- The following two commands are used in transmission channel
- opening and closing:
-
- HELO <SP> <domain> <CRLF>
-
- QUIT <CRLF>
-
- In the HELO command the host sending the command identifies
- itself; the command may be interpreted as saying "Hello, I am
- <domain>".
-
- -------------------------------------------------------------
-
- Example of Connection Opening
-
- R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
- S: HELO USC-ISIF.ARPA
- R: 250 BBN-UNIX.ARPA
-
- Example 5
-
- -------------------------------------------------------------
-
- -------------------------------------------------------------
-
- Example of Connection Closing
-
- S: QUIT
- R: 221 BBN-UNIX.ARPA Service closing transmission channel
-
- Example 6
-
- -------------------------------------------------------------
-
-
-
-
-
-
-
-
-
-
-Postel [Page 13]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- 3.6. RELAYING
-
- The forward-path may be a source route of the form
- "@ONE,@TWO:address@hidden", where ONE, TWO, and THREE are hosts. This
- form is used to emphasize the distinction between an address and a
- route. The mailbox is an absolute address, and the route is
- information about how to get there. The two concepts should not
- be confused.
-
- Conceptually the elements of the forward-path are moved to the
- reverse-path as the message is relayed from one server-SMTP to
- another. The reverse-path is a reverse source route, (i.e., a
- source route from the current location of the message to the
- originator of the message). When a server-SMTP deletes its
- identifier from the forward-path and inserts it into the
- reverse-path, it must use the name it is known by in the
- environment it is sending into, not the environment the mail came
- from, in case the server-SMTP is known by different names in
- different environments.
-
- If when the message arrives at an SMTP the first element of the
- forward-path is not the identifier of that SMTP the element is not
- deleted from the forward-path and is used to determine the next
- SMTP to send the message to. In any case, the SMTP adds its own
- identifier to the reverse-path.
-
- Using source routing the receiver-SMTP receives mail to be relayed
- to another server-SMTP The receiver-SMTP may accept or reject the
- task of relaying the mail in the same way it accepts or rejects
- mail for a local user. The receiver-SMTP transforms the command
- arguments by moving its own identifier from the forward-path to
- the beginning of the reverse-path. The receiver-SMTP then becomes
- a sender-SMTP, establishes a transmission channel to the next SMTP
- in the forward-path, and sends it the mail.
-
- The first host in the reverse-path should be the host sending the
- SMTP commands, and the first host in the forward-path should be
- the host receiving the SMTP commands.
-
- Notice that the forward-path and reverse-path appear in the SMTP
- commands and replies, but not necessarily in the message. That
- is, there is no need for these paths and especially this syntax to
- appear in the "To:" , "From:", "CC:", etc. fields of the message
- header.
-
- If a server-SMTP has accepted the task of relaying the mail and
-
-
-
-[Page 14] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- later finds that the forward-path is incorrect or that the mail
- cannot be delivered for whatever reason, then it must construct an
- "undeliverable mail" notification message and send it to the
- originator of the undeliverable mail (as indicated by the
- reverse-path).
-
- This notification message must be from the server-SMTP at this
- host. Of course, server-SMTPs should not send notification
- messages about problems with notification messages. One way to
- prevent loops in error reporting is to specify a null reverse-path
- in the MAIL command of a notification message. When such a
- message is relayed it is permissible to leave the reverse-path
- null. A MAIL command with a null reverse-path appears as follows:
-
- MAIL FROM:<>
-
- An undeliverable mail notification message is shown in example 7.
- This notification is in response to a message originated by JOE at
- HOSTW and sent via HOSTX to HOSTY with instructions to relay it on
- to HOSTZ. What we see in the example is the transaction between
- HOSTY and HOSTX, which is the first step in the return of the
- notification message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Postel [Page 15]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- -------------------------------------------------------------
-
- Example Undeliverable Mail Notification Message
-
- S: MAIL FROM:<>
- R: 250 ok
- S: RCPT TO:<@HOSTX.ARPA:address@hidden>
- R: 250 ok
- S: DATA
- R: 354 send the mail data, end with .
- S: Date: 23 Oct 81 11:22:33
- S: From: address@hidden
- S: To: address@hidden
- S: Subject: Mail System Problem
- S:
- S: Sorry JOE, your message to address@hidden lost.
- S: HOSTZ.ARPA said this:
- S: "550 No Such User"
- S: .
- R: 250 ok
-
- Example 7
-
- -------------------------------------------------------------
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 16] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- 3.7. DOMAINS
-
- Domains are a recently introduced concept in the ARPA Internet
- mail system. The use of domains changes the address space from a
- flat global space of simple character string host names to a
- hierarchically structured rooted tree of global addresses. The
- host name is replaced by a domain and host designator which is a
- sequence of domain element strings separated by periods with the
- understanding that the domain elements are ordered from the most
- specific to the most general.
-
- For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and
- "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers.
-
- Whenever domain names are used in SMTP only the official names are
- used, the use of nicknames or aliases is not allowed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Postel [Page 17]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- 3.8. CHANGING ROLES
-
- The TURN command may be used to reverse the roles of the two
- programs communicating over the transmission channel.
-
- If program-A is currently the sender-SMTP and it sends the TURN
- command and receives an ok reply (250) then program-A becomes the
- receiver-SMTP.
-
- If program-B is currently the receiver-SMTP and it receives the
- TURN command and sends an ok reply (250) then program-B becomes
- the sender-SMTP.
-
- To refuse to change roles the receiver sends the 502 reply.
-
- Please note that this command is optional. It would not normally
- be used in situations where the transmission channel is TCP.
- However, when the cost of establishing the transmission channel is
- high, this command may be quite useful. For example, this command
- may be useful in supporting be mail exchange using the public
- switched telephone system as a transmission channel, especially if
- some hosts poll other hosts for mail exchanges.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 18] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
-4. THE SMTP SPECIFICATIONS
-
- 4.1. SMTP COMMANDS
-
- 4.1.1. COMMAND SEMANTICS
-
- The SMTP commands define the mail transfer or the mail system
- function requested by the user. SMTP commands are character
- strings terminated by <CRLF>. The command codes themselves are
- alphabetic characters terminated by <SP> if parameters follow
- and <CRLF> otherwise. The syntax of mailboxes must conform to
- receiver site conventions. The SMTP commands are discussed
- below. The SMTP replies are discussed in the Section 4.2.
-
- A mail transaction involves several data objects which are
- communicated as arguments to different commands. The
- reverse-path is the argument of the MAIL command, the
- forward-path is the argument of the RCPT command, and the mail
- data is the argument of the DATA command. These arguments or
- data objects must be transmitted and held pending the
- confirmation communicated by the end of mail data indication
- which finalizes the transaction. The model for this is that
- distinct buffers are provided to hold the types of data
- objects, that is, there is a reverse-path buffer, a
- forward-path buffer, and a mail data buffer. Specific commands
- cause information to be appended to a specific buffer, or cause
- one or more buffers to be cleared.
-
- HELLO (HELO)
-
- This command is used to identify the sender-SMTP to the
- receiver-SMTP. The argument field contains the host name of
- the sender-SMTP.
-
- The receiver-SMTP identifies itself to the sender-SMTP in
- the connection greeting reply, and in the response to this
- command.
-
- This command and an OK reply to it confirm that both the
- sender-SMTP and the receiver-SMTP are in the initial state,
- that is, there is no transaction in progress and all state
- tables and buffers are cleared.
-
-
-
-
-
-
-
-Postel [Page 19]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- MAIL (MAIL)
-
- This command is used to initiate a mail transaction in which
- the mail data is delivered to one or more mailboxes. The
- argument field contains a reverse-path.
-
- The reverse-path consists of an optional list of hosts and
- the sender mailbox. When the list of hosts is present, it
- is a "reverse" source route and indicates that the mail was
- relayed through each host on the list (the first host in the
- list was the most recent relay). This list is used as a
- source route to return non-delivery notices to the sender.
- As each relay host adds itself to the beginning of the list,
- it must use its name as known in the IPCE to which it is
- relaying the mail rather than the IPCE from which the mail
- came (if they are different). In some types of error
- reporting messages (for example, undeliverable mail
- notifications) the reverse-path may be null (see Example 7).
-
- This command clears the reverse-path buffer, the
- forward-path buffer, and the mail data buffer; and inserts
- the reverse-path information from this command into the
- reverse-path buffer.
-
- RECIPIENT (RCPT)
-
- This command is used to identify an individual recipient of
- the mail data; multiple recipients are specified by multiple
- use of this command.
-
- The forward-path consists of an optional list of hosts and a
- required destination mailbox. When the list of hosts is
- present, it is a source route and indicates that the mail
- must be relayed to the next host on the list. If the
- receiver-SMTP does not implement the relay function it may
- user the same reply it would for an unknown local user
- (550).
-
- When mail is relayed, the relay host must remove itself from
- the beginning forward-path and put itself at the beginning
- of the reverse-path. When mail reaches its ultimate
- destination (the forward-path contains only a destination
- mailbox), the receiver-SMTP inserts it into the destination
- mailbox in accordance with its host mail conventions.
-
-
-
-
-
-[Page 20] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- For example, mail received at relay host A with arguments
-
- FROM:<address@hidden>
- TO:<@HOSTA.ARPA,@HOSTB.ARPA:address@hidden>
-
- will be relayed on to host B with arguments
-
- FROM:<@HOSTA.ARPA:address@hidden>
- TO:<@HOSTB.ARPA:address@hidden>.
-
- This command causes its forward-path argument to be appended
- to the forward-path buffer.
-
- DATA (DATA)
-
- The receiver treats the lines following the command as mail
- data from the sender. This command causes the mail data
- from this command to be appended to the mail data buffer.
- The mail data may contain any of the 128 ASCII character
- codes.
-
- The mail data is terminated by a line containing only a
- period, that is the character sequence "<CRLF>.<CRLF>" (see
- Section 4.5.2 on Transparency). This is the end of mail
- data indication.
-
- The end of mail data indication requires that the receiver
- must now process the stored mail transaction information.
- This processing consumes the information in the reverse-path
- buffer, the forward-path buffer, and the mail data buffer,
- and on the completion of this command these buffers are
- cleared. If the processing is successful the receiver must
- send an OK reply. If the processing fails completely the
- receiver must send a failure reply.
-
- When the receiver-SMTP accepts a message either for relaying
- or for final delivery it inserts at the beginning of the
- mail data a time stamp line. The time stamp line indicates
- the identity of the host that sent the message, and the
- identity of the host that received the message (and is
- inserting this time stamp), and the date and time the
- message was received. Relayed messages will have multiple
- time stamp lines.
-
- When the receiver-SMTP makes the "final delivery" of a
- message it inserts at the beginning of the mail data a
-
-
-
-Postel [Page 21]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- return path line. The return path line preserves the
- information in the <reverse-path> from the MAIL command.
- Here, final delivery means the message leaves the SMTP
- world. Normally, this would mean it has been delivered to
- the destination user, but in some cases it may be further
- processed and transmitted by another mail system.
-
- It is possible for the mailbox in the return path be
- different from the actual sender's mailbox, for example,
- if error responses are to be delivered a special error
- handling mailbox rather than the message senders.
-
- The preceding two paragraphs imply that the final mail data
- will begin with a return path line, followed by one or more
- time stamp lines. These lines will be followed by the mail
- data header and body [2]. See Example 8.
-
- Special mention is needed of the response and further action
- required when the processing following the end of mail data
- indication is partially successful. This could arise if
- after accepting several recipients and the mail data, the
- receiver-SMTP finds that the mail data can be successfully
- delivered to some of the recipients, but it cannot be to
- others (for example, due to mailbox space allocation
- problems). In such a situation, the response to the DATA
- command must be an OK reply. But, the receiver-SMTP must
- compose and send an "undeliverable mail" notification
- message to the originator of the message. Either a single
- notification which lists all of the recipients that failed
- to get the message, or separate notification messages must
- be sent for each failed recipient (see Example 7). All
- undeliverable mail notification messages are sent using the
- MAIL command (even if they result from processing a SEND,
- SOML, or SAML command).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 22] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- -------------------------------------------------------------
-
- Example of Return Path and Received Time Stamps
-
- Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:address@hidden>
- Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST
- Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST
- Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST
- Date: 27 Oct 81 15:01:01 PST
- From: address@hidden
- Subject: Improved Mailing System Installed
- To: address@hidden
-
- This is to inform you that ...
-
- Example 8
-
- -------------------------------------------------------------
-
- SEND (SEND)
-
- This command is used to initiate a mail transaction in which
- the mail data is delivered to one or more terminals. The
- argument field contains a reverse-path. This command is
- successful if the message is delivered to a terminal.
-
- The reverse-path consists of an optional list of hosts and
- the sender mailbox. When the list of hosts is present, it
- is a "reverse" source route and indicates that the mail was
- relayed through each host on the list (the first host in the
- list was the most recent relay). This list is used as a
- source route to return non-delivery notices to the sender.
- As each relay host adds itself to the beginning of the list,
- it must use its name as known in the IPCE to which it is
- relaying the mail rather than the IPCE from which the mail
- came (if they are different).
-
- This command clears the reverse-path buffer, the
- forward-path buffer, and the mail data buffer; and inserts
- the reverse-path information from this command into the
- reverse-path buffer.
-
- SEND OR MAIL (SOML)
-
- This command is used to initiate a mail transaction in which
- the mail data is delivered to one or more terminals or
-
-
-
-Postel [Page 23]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- mailboxes. For each recipient the mail data is delivered to
- the recipient's terminal if the recipient is active on the
- host (and accepting terminal messages), otherwise to the
- recipient's mailbox. The argument field contains a
- reverse-path. This command is successful if the message is
- delivered to a terminal or the mailbox.
-
- The reverse-path consists of an optional list of hosts and
- the sender mailbox. When the list of hosts is present, it
- is a "reverse" source route and indicates that the mail was
- relayed through each host on the list (the first host in the
- list was the most recent relay). This list is used as a
- source route to return non-delivery notices to the sender.
- As each relay host adds itself to the beginning of the list,
- it must use its name as known in the IPCE to which it is
- relaying the mail rather than the IPCE from which the mail
- came (if they are different).
-
- This command clears the reverse-path buffer, the
- forward-path buffer, and the mail data buffer; and inserts
- the reverse-path information from this command into the
- reverse-path buffer.
-
- SEND AND MAIL (SAML)
-
- This command is used to initiate a mail transaction in which
- the mail data is delivered to one or more terminals and
- mailboxes. For each recipient the mail data is delivered to
- the recipient's terminal if the recipient is active on the
- host (and accepting terminal messages), and for all
- recipients to the recipient's mailbox. The argument field
- contains a reverse-path. This command is successful if the
- message is delivered to the mailbox.
-
- The reverse-path consists of an optional list of hosts and
- the sender mailbox. When the list of hosts is present, it
- is a "reverse" source route and indicates that the mail was
- relayed through each host on the list (the first host in the
- list was the most recent relay). This list is used as a
- source route to return non-delivery notices to the sender.
- As each relay host adds itself to the beginning of the list,
- it must use its name as known in the IPCE to which it is
- relaying the mail rather than the IPCE from which the mail
- came (if they are different).
-
- This command clears the reverse-path buffer, the
-
-
-
-[Page 24] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- forward-path buffer, and the mail data buffer; and inserts
- the reverse-path information from this command into the
- reverse-path buffer.
-
- RESET (RSET)
-
- This command specifies that the current mail transaction is
- to be aborted. Any stored sender, recipients, and mail data
- must be discarded, and all buffers and state tables cleared.
- The receiver must send an OK reply.
-
- VERIFY (VRFY)
-
- This command asks the receiver to confirm that the argument
- identifies a user. If it is a user name, the full name of
- the user (if known) and the fully specified mailbox are
- returned.
-
- This command has no effect on any of the reverse-path
- buffer, the forward-path buffer, or the mail data buffer.
-
- EXPAND (EXPN)
-
- This command asks the receiver to confirm that the argument
- identifies a mailing list, and if so, to return the
- membership of that list. The full name of the users (if
- known) and the fully specified mailboxes are returned in a
- multiline reply.
-
- This command has no effect on any of the reverse-path
- buffer, the forward-path buffer, or the mail data buffer.
-
- HELP (HELP)
-
- This command causes the receiver to send helpful information
- to the sender of the HELP command. The command may take an
- argument (e.g., any command name) and return more specific
- information as a response.
-
- This command has no effect on any of the reverse-path
- buffer, the forward-path buffer, or the mail data buffer.
-
-
-
-
-
-
-
-
-Postel [Page 25]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- NOOP (NOOP)
-
- This command does not affect any parameters or previously
- entered commands. It specifies no action other than that
- the receiver send an OK reply.
-
- This command has no effect on any of the reverse-path
- buffer, the forward-path buffer, or the mail data buffer.
-
- QUIT (QUIT)
-
- This command specifies that the receiver must send an OK
- reply, and then close the transmission channel.
-
- The receiver should not close the transmission channel until
- it receives and replies to a QUIT command (even if there was
- an error). The sender should not close the transmission
- channel until it send a QUIT command and receives the reply
- (even if there was an error response to a previous command).
- If the connection is closed prematurely the receiver should
- act as if a RSET command had been received (canceling any
- pending transaction, but not undoing any previously
- completed transaction), the sender should act as if the
- command or transaction in progress had received a temporary
- error (4xx).
-
- TURN (TURN)
-
- This command specifies that the receiver must either (1)
- send an OK reply and then take on the role of the
- sender-SMTP, or (2) send a refusal reply and retain the role
- of the receiver-SMTP.
-
- If program-A is currently the sender-SMTP and it sends the
- TURN command and receives an OK reply (250) then program-A
- becomes the receiver-SMTP. Program-A is then in the initial
- state as if the transmission channel just opened, and it
- then sends the 220 service ready greeting.
-
- If program-B is currently the receiver-SMTP and it receives
- the TURN command and sends an OK reply (250) then program-B
- becomes the sender-SMTP. Program-B is then in the initial
- state as if the transmission channel just opened, and it
- then expects to receive the 220 service ready greeting.
-
- To refuse to change roles the receiver sends the 502 reply.
-
-
-
-[Page 26] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- There are restrictions on the order in which these command may
- be used.
-
- The first command in a session must be the HELO command.
- The HELO command may be used later in a session as well. If
- the HELO command argument is not acceptable a 501 failure
- reply must be returned and the receiver-SMTP must stay in
- the same state.
-
- The NOOP, HELP, EXPN, and VRFY commands can be used at any
- time during a session.
-
- The MAIL, SEND, SOML, or SAML commands begin a mail
- transaction. Once started a mail transaction consists of
- one of the transaction beginning commands, one or more RCPT
- commands, and a DATA command, in that order. A mail
- transaction may be aborted by the RSET command. There may
- be zero or more transactions in a session.
-
- If the transaction beginning command argument is not
- acceptable a 501 failure reply must be returned and the
- receiver-SMTP must stay in the same state. If the commands
- in a transaction are out of order a 503 failure reply must
- be returned and the receiver-SMTP must stay in the same
- state.
-
- The last command in a session must be the QUIT command. The
- QUIT command can not be used at any other time in a session.
-
- 4.1.2. COMMAND SYNTAX
-
- The commands consist of a command code followed by an argument
- field. Command codes are four alphabetic characters. Upper
- and lower case alphabetic characters are to be treated
- identically. Thus, any of the following may represent the mail
- command:
-
- MAIL Mail mail MaIl mAIl
-
- This also applies to any symbols representing parameter values,
- such as "TO" or "to" for the forward-path. Command codes and
- the argument fields are separated by one or more spaces.
- However, within the reverse-path and forward-path arguments
- case is important. In particular, in some hosts the user
- "smith" is different from the user "Smith".
-
-
-
-
-Postel [Page 27]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- The argument field consists of a variable length character
- string ending with the character sequence <CRLF>. The receiver
- is to take no action until this sequence is received.
-
- Square brackets denote an optional argument field. If the
- option is not taken, the appropriate default is implied.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 28] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- The following are the SMTP commands:
-
- HELO <SP> <domain> <CRLF>
-
- MAIL <SP> FROM:<reverse-path> <CRLF>
-
- RCPT <SP> TO:<forward-path> <CRLF>
-
- DATA <CRLF>
-
- RSET <CRLF>
-
- SEND <SP> FROM:<reverse-path> <CRLF>
-
- SOML <SP> FROM:<reverse-path> <CRLF>
-
- SAML <SP> FROM:<reverse-path> <CRLF>
-
- VRFY <SP> <string> <CRLF>
-
- EXPN <SP> <string> <CRLF>
-
- HELP [<SP> <string>] <CRLF>
-
- NOOP <CRLF>
-
- QUIT <CRLF>
-
- TURN <CRLF>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Postel [Page 29]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- The syntax of the above argument fields (using BNF notation
- where applicable) is given below. The "..." notation indicates
- that a field may be repeated one or more times.
-
- <reverse-path> ::= <path>
-
- <forward-path> ::= <path>
-
- <path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">"
-
- <a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l>
-
- <at-domain> ::= "@" <domain>
-
- <domain> ::= <element> | <element> "." <domain>
-
- <element> ::= <name> | "#" <number> | "[" <dotnum> "]"
-
- <mailbox> ::= <local-part> "@" <domain>
-
- <local-part> ::= <dot-string> | <quoted-string>
-
- <name> ::= <a> <ldh-str> <let-dig>
-
- <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
-
- <let-dig> ::= <a> | <d>
-
- <let-dig-hyp> ::= <a> | <d> | "-"
-
- <dot-string> ::= <string> | <string> "." <dot-string>
-
- <string> ::= <char> | <char> <string>
-
- <quoted-string> ::= """ <qtext> """
-
- <qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
-
- <char> ::= <c> | "\" <x>
-
- <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
-
- <number> ::= <d> | <d> <number>
-
- <CRLF> ::= <CR> <LF>
-
-
-
-
-[Page 30] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- <CR> ::= the carriage return character (ASCII code 13)
-
- <LF> ::= the line feed character (ASCII code 10)
-
- <SP> ::= the space character (ASCII code 32)
-
- <snum> ::= one, two, or three digits representing a decimal
- integer value in the range 0 through 255
-
- <a> ::= any one of the 52 alphabetic characters A through Z
- in upper case and a through z in lower case
-
- <c> ::= any one of the 128 ASCII characters, but not any
- <special> or <SP>
-
- <d> ::= any one of the ten digits 0 through 9
-
- <q> ::= any one of the 128 ASCII characters except <CR>,
- <LF>, quote ("), or backslash (\)
-
- <x> ::= any one of the 128 ASCII characters (no exceptions)
-
- <special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
- | "," | ";" | ":" | "@" """ | the control
- characters (ASCII codes 0 through 31 inclusive and
- 127)
-
- Note that the backslash, "\", is a quote character, which is
- used to indicate that the next character is to be used
- literally (instead of its normal interpretation). For example,
- "Joe\,Smith" could be used to indicate a single nine character
- user field with comma being the fourth character of the field.
-
- Hosts are generally known by names which are translated to
- addresses in each host. Note that the name elements of domains
- are the official names -- no use of nicknames or aliases is
- allowed.
-
- Sometimes a host is not known to the translation function and
- communication is blocked. To bypass this barrier two numeric
- forms are also allowed for host "names". One form is a decimal
- integer prefixed by a pound sign, "#", which indicates the
- number is the address of the host. Another form is four small
- decimal integers separated by dots and enclosed by brackets,
- e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet
- Address in four 8-bit fields.
-
-
-
-Postel [Page 31]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- The time stamp line and the return path line are formally
- defined as follows:
-
- <return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF>
-
- <time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF>
-
- <stamp> ::= <from-domain> <by-domain> <opt-info> ";"
- <daytime>
-
- <from-domain> ::= "FROM" <SP> <domain> <SP>
-
- <by-domain> ::= "BY" <SP> <domain> <SP>
-
- <opt-info> ::= [<via>] [<with>] [<id>] [<for>]
-
- <via> ::= "VIA" <SP> <link> <SP>
-
- <with> ::= "WITH" <SP> <protocol> <SP>
-
- <id> ::= "ID" <SP> <string> <SP>
-
- <for> ::= "FOR" <SP> <path> <SP>
-
- <link> ::= The standard names for links are registered with
- the Network Information Center.
-
- <protocol> ::= The standard names for protocols are
- registered with the Network Information Center.
-
- <daytime> ::= <SP> <date> <SP> <time>
-
- <date> ::= <dd> <SP> <mon> <SP> <yy>
-
- <time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>
-
- <dd> ::= the one or two decimal integer day of the month in
- the range 1 to 31.
-
- <mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
- "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
-
- <yy> ::= the two decimal integer year of the century in the
- range 00 to 99.
-
-
-
-
-
-[Page 32] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- <hh> ::= the two decimal integer hour of the day in the
- range 00 to 24.
-
- <mm> ::= the two decimal integer minute of the hour in the
- range 00 to 59.
-
- <ss> ::= the two decimal integer second of the minute in the
- range 00 to 59.
-
- <zone> ::= "UT" for Universal Time (the default) or other
- time zone designator (as in [2]).
-
-
-
- -------------------------------------------------------------
-
- Return Path Example
-
- Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:address@hidden>
-
- Example 9
-
- -------------------------------------------------------------
-
- -------------------------------------------------------------
-
- Time Stamp Line Example
-
- Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT
-
- Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25
- id M12345 for address@hidden ; 22 OCT 81 09:23:59 PDT
-
- Example 10
-
- -------------------------------------------------------------
-
-
-
-
-
-
-
-
-
-
-
-
-
-Postel [Page 33]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- 4.2. SMTP REPLIES
-
- Replies to SMTP commands are devised to ensure the synchronization
- of requests and actions in the process of mail transfer, and to
- guarantee that the sender-SMTP always knows the state of the
- receiver-SMTP. Every command must generate exactly one reply.
-
- The details of the command-reply sequence are made explicit in
- Section 5.3 on Sequencing and Section 5.4 State Diagrams.
-
- An SMTP reply consists of a three digit number (transmitted as
- three alphanumeric characters) followed by some text. The number
- is intended for use by automata to determine what state to enter
- next; the text is meant for the human user. It is intended that
- the three digits contain enough encoded information that the
- sender-SMTP need not examine the text and may either discard it or
- pass it on to the user, as appropriate. In particular, the text
- may be receiver-dependent and context dependent, so there are
- likely to be varying texts for each reply code. A discussion of
- the theory of reply codes is given in Appendix E. Formally, a
- reply is defined to be the sequence: a three-digit code, <SP>,
- one line of text, and <CRLF>, or a multiline reply (as defined in
- Appendix E). Only the EXPN and HELP commands are expected to
- result in multiline replies in normal circumstances, however
- multiline replies are allowed for any command.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 34] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- 4.2.1. REPLY CODES BY FUNCTION GROUPS
-
- 500 Syntax error, command unrecognized
- [This may include errors such as command line too long]
- 501 Syntax error in parameters or arguments
- 502 Command not implemented
- 503 Bad sequence of commands
- 504 Command parameter not implemented
-
- 211 System status, or system help reply
- 214 Help message
- [Information on how to use the receiver or the meaning of a
- particular non-standard command; this reply is useful only
- to the human user]
-
- 220 <domain> Service ready
- 221 <domain> Service closing transmission channel
- 421 <domain> Service not available,
- closing transmission channel
- [This may be a reply to any command if the service knows it
- must shut down]
-
- 250 Requested mail action okay, completed
- 251 User not local; will forward to <forward-path>
- 450 Requested mail action not taken: mailbox unavailable
- [E.g., mailbox busy]
- 550 Requested action not taken: mailbox unavailable
- [E.g., mailbox not found, no access]
- 451 Requested action aborted: error in processing
- 551 User not local; please try <forward-path>
- 452 Requested action not taken: insufficient system storage
- 552 Requested mail action aborted: exceeded storage allocation
- 553 Requested action not taken: mailbox name not allowed
- [E.g., mailbox syntax incorrect]
- 354 Start mail input; end with <CRLF>.<CRLF>
- 554 Transaction failed
-
-
-
-
-
-
-
-
-
-
-
-
-
-Postel [Page 35]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- 4.2.2. NUMERIC ORDER LIST OF REPLY CODES
-
- 211 System status, or system help reply
- 214 Help message
- [Information on how to use the receiver or the meaning of a
- particular non-standard command; this reply is useful only
- to the human user]
- 220 <domain> Service ready
- 221 <domain> Service closing transmission channel
- 250 Requested mail action okay, completed
- 251 User not local; will forward to <forward-path>
-
- 354 Start mail input; end with <CRLF>.<CRLF>
-
- 421 <domain> Service not available,
- closing transmission channel
- [This may be a reply to any command if the service knows it
- must shut down]
- 450 Requested mail action not taken: mailbox unavailable
- [E.g., mailbox busy]
- 451 Requested action aborted: local error in processing
- 452 Requested action not taken: insufficient system storage
-
- 500 Syntax error, command unrecognized
- [This may include errors such as command line too long]
- 501 Syntax error in parameters or arguments
- 502 Command not implemented
- 503 Bad sequence of commands
- 504 Command parameter not implemented
- 550 Requested action not taken: mailbox unavailable
- [E.g., mailbox not found, no access]
- 551 User not local; please try <forward-path>
- 552 Requested mail action aborted: exceeded storage allocation
- 553 Requested action not taken: mailbox name not allowed
- [E.g., mailbox syntax incorrect]
- 554 Transaction failed
-
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 36] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- 4.3. SEQUENCING OF COMMANDS AND REPLIES
-
- The communication between the sender and receiver is intended to
- be an alternating dialogue, controlled by the sender. As such,
- the sender issues a command and the receiver responds with a
- reply. The sender must wait for this response before sending
- further commands.
-
- One important reply is the connection greeting. Normally, a
- receiver will send a 220 "Service ready" reply when the connection
- is completed. The sender should wait for this greeting message
- before sending any commands.
-
- Note: all the greeting type replies have the official name of
- the server host as the first word following the reply code.
-
- For example,
-
- 220 <SP> USC-ISIF.ARPA <SP> Service ready <CRLF>
-
- The table below lists alternative success and failure replies for
- each command. These must be strictly adhered to; a receiver may
- substitute text in the replies, but the meaning and action implied
- by the code numbers and by the specific command reply sequence
- cannot be altered.
-
- COMMAND-REPLY SEQUENCES
-
- Each command is listed with its possible replies. The prefixes
- used before the possible replies are "P" for preliminary (not
- used in SMTP), "I" for intermediate, "S" for success, "F" for
- failure, and "E" for error. The 421 reply (service not
- available, closing transmission channel) may be given to any
- command if the SMTP-receiver knows it must shut down. This
- listing forms the basis for the State Diagrams in Section 4.4.
-
- CONNECTION ESTABLISHMENT
- S: 220
- F: 421
- HELO
- S: 250
- E: 500, 501, 504, 421
- MAIL
- S: 250
- F: 552, 451, 452
- E: 500, 501, 421
-
-
-
-Postel [Page 37]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- RCPT
- S: 250, 251
- F: 550, 551, 552, 553, 450, 451, 452
- E: 500, 501, 503, 421
- DATA
- I: 354 -> data -> S: 250
- F: 552, 554, 451, 452
- F: 451, 554
- E: 500, 501, 503, 421
- RSET
- S: 250
- E: 500, 501, 504, 421
- SEND
- S: 250
- F: 552, 451, 452
- E: 500, 501, 502, 421
- SOML
- S: 250
- F: 552, 451, 452
- E: 500, 501, 502, 421
- SAML
- S: 250
- F: 552, 451, 452
- E: 500, 501, 502, 421
- VRFY
- S: 250, 251
- F: 550, 551, 553
- E: 500, 501, 502, 504, 421
- EXPN
- S: 250
- F: 550
- E: 500, 501, 502, 504, 421
- HELP
- S: 211, 214
- E: 500, 501, 502, 504, 421
- NOOP
- S: 250
- E: 500, 421
- QUIT
- S: 221
- E: 500
- TURN
- S: 250
- F: 502
- E: 500, 503
-
-
-
-
-[Page 38] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- 4.4. STATE DIAGRAMS
-
- Following are state diagrams for a simple-minded SMTP
- implementation. Only the first digit of the reply codes is used.
- There is one state diagram for each group of SMTP commands. The
- command groupings were determined by constructing a model for each
- command and then collecting together the commands with
- structurally identical models.
-
- For each command there are three possible outcomes: "success"
- (S), "failure" (F), and "error" (E). In the state diagrams below
- we use the symbol B for "begin", and the symbol W for "wait for
- reply".
-
- First, the diagram that represents most of the SMTP commands:
-
-
- 1,3 +---+
- ----------->| E |
- | +---+
- |
- +---+ cmd +---+ 2 +---+
- | B |---------->| W |---------->| S |
- +---+ +---+ +---+
- |
- | 4,5 +---+
- ----------->| F |
- +---+
-
-
- This diagram models the commands:
-
- HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP,
- NOOP, QUIT, TURN.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Postel [Page 39]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- A more complex diagram models the DATA command:
-
-
- +---+ DATA +---+ 1,2 +---+
- | B |---------->| W |-------------------->| E |
- +---+ +---+ ------------>+---+
- 3| |4,5 |
- | | |
- -------------- ----- |
- | | | +---+
- | ---------- -------->| S |
- | | | | +---+
- | | ------------
- | | | |
- V 1,3| |2 |
- +---+ data +---+ --------------->+---+
- | |---------->| W | | F |
- +---+ +---+-------------------->+---+
- 4,5
-
-
- Note that the "data" here is a series of lines sent from the
- sender to the receiver with no response expected until the last
- line is sent.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 40] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- 4.5. DETAILS
-
- 4.5.1. MINIMUM IMPLEMENTATION
-
- In order to make SMTP workable, the following minimum
- implementation is required for all receivers:
-
- COMMANDS -- HELO
- MAIL
- RCPT
- DATA
- RSET
- NOOP
- QUIT
-
- 4.5.2. TRANSPARENCY
-
- Without some provision for data transparency the character
- sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent
- by the user. In general, users are not aware of such
- "forbidden" sequences. To allow all user composed text to be
- transmitted transparently the following procedures are used.
-
- 1. Before sending a line of mail text the sender-SMTP checks
- the first character of the line. If it is a period, one
- additional period is inserted at the beginning of the line.
-
- 2. When a line of mail text is received by the receiver-SMTP
- it checks the line. If the line is composed of a single
- period it is the end of mail. If the first character is a
- period and there are other characters on the line, the first
- character is deleted.
-
- The mail data may contain any of the 128 ASCII characters. All
- characters are to be delivered to the recipient's mailbox
- including format effectors and other control characters. If
- the transmission channel provides an 8-bit byte (octets) data
- stream, the 7-bit ASCII codes are transmitted right justified
- in the octets with the high order bits cleared to zero.
-
- In some systems it may be necessary to transform the data as
- it is received and stored. This may be necessary for hosts
- that use a different character set than ASCII as their local
- character set, or that store data in records rather than
-
-
-
-
-
-Postel [Page 41]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- strings. If such transforms are necessary, they must be
- reversible -- especially if such transforms are applied to
- mail being relayed.
-
- 4.5.3. SIZES
-
- There are several objects that have required minimum maximum
- sizes. That is, every implementation must be able to receive
- objects of at least these sizes, but must not send objects
- larger than these sizes.
-
-
- ****************************************************
- * *
- * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION *
- * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
- * OF THESE OBJECTS SHOULD BE USED. *
- * *
- ****************************************************
-
- user
-
- The maximum total length of a user name is 64 characters.
-
- domain
-
- The maximum total length of a domain name or number is 64
- characters.
-
- path
-
- The maximum total length of a reverse-path or
- forward-path is 256 characters (including the punctuation
- and element separators).
-
- command line
-
- The maximum total length of a command line including the
- command word and the <CRLF> is 512 characters.
-
- reply line
-
- The maximum total length of a reply line including the
- reply code and the <CRLF> is 512 characters.
-
-
-
-
-
-[Page 42] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- text line
-
- The maximum total length of a text line including the
- <CRLF> is 1000 characters (but not counting the leading
- dot duplicated for transparency).
-
- recipients buffer
-
- The maximum total number of recipients that must be
- buffered is 100 recipients.
-
-
- ****************************************************
- * *
- * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION *
- * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
- * OF THESE OBJECTS SHOULD BE USED. *
- * *
- ****************************************************
-
- Errors due to exceeding these limits may be reported by using
- the reply codes, for example:
-
- 500 Line too long.
-
- 501 Path too long
-
- 552 Too many recipients.
-
- 552 Too much mail data.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Postel [Page 43]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
-APPENDIX A
-
- TCP Transport service
-
- The Transmission Control Protocol [3] is used in the ARPA
- Internet, and in any network following the US DoD standards for
- internetwork protocols.
-
- Connection Establishment
-
- The SMTP transmission channel is a TCP connection established
- between the sender process port U and the receiver process port
- L. This single full duplex connection is used as the
- transmission channel. This protocol is assigned the service
- port 25 (31 octal), that is L=25.
-
- Data Transfer
-
- The TCP connection supports the transmission of 8-bit bytes.
- The SMTP data is 7-bit ASCII characters. Each character is
- transmitted as an 8-bit byte with the high-order bit cleared to
- zero.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 44] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
-APPENDIX B
-
- NCP Transport service
-
- The ARPANET Host-to-Host Protocol [4] (implemented by the Network
- Control Program) may be used in the ARPANET.
-
- Connection Establishment
-
- The SMTP transmission channel is established via NCP between
- the sender process socket U and receiver process socket L. The
- Initial Connection Protocol [5] is followed resulting in a pair
- of simplex connections. This pair of connections is used as
- the transmission channel. This protocol is assigned the
- contact socket 25 (31 octal), that is L=25.
-
- Data Transfer
-
- The NCP data connections are established in 8-bit byte mode.
- The SMTP data is 7-bit ASCII characters. Each character is
- transmitted as an 8-bit byte with the high-order bit cleared to
- zero.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Postel [Page 45]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
-APPENDIX C
-
- NITS
-
- The Network Independent Transport Service [6] may be used.
-
- Connection Establishment
-
- The SMTP transmission channel is established via NITS between
- the sender process and receiver process. The sender process
- executes the CONNECT primitive, and the waiting receiver
- process executes the ACCEPT primitive.
-
- Data Transfer
-
- The NITS connection supports the transmission of 8-bit bytes.
- The SMTP data is 7-bit ASCII characters. Each character is
- transmitted as an 8-bit byte with the high-order bit cleared to
- zero.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 46] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
-APPENDIX D
-
- X.25 Transport service
-
- It may be possible to use the X.25 service [7] as provided by the
- Public Data Networks directly, however, it is suggested that a
- reliable end-to-end protocol such as TCP be used on top of X.25
- connections.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Postel [Page 47]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
-APPENDIX E
-
- Theory of Reply Codes
-
- The three digits of the reply each have a special significance.
- The first digit denotes whether the response is good, bad or
- incomplete. An unsophisticated sender-SMTP will be able to
- determine its next action (proceed as planned, redo, retrench,
- etc.) by simply examining this first digit. A sender-SMTP that
- wants to know approximately what kind of error occurred (e.g.,
- mail system error, command syntax error) may examine the second
- digit, reserving the third digit for the finest gradation of
- information.
-
- There are five values for the first digit of the reply code:
-
- 1yz Positive Preliminary reply
-
- The command has been accepted, but the requested action
- is being held in abeyance, pending confirmation of the
- information in this reply. The sender-SMTP should send
- another command specifying whether to continue or abort
- the action.
-
- [Note: SMTP does not have any commands that allow this
- type of reply, and so does not have the continue or
- abort commands.]
-
- 2yz Positive Completion reply
-
- The requested action has been successfully completed. A
- new request may be initiated.
-
- 3yz Positive Intermediate reply
-
- The command has been accepted, but the requested action
- is being held in abeyance, pending receipt of further
- information. The sender-SMTP should send another command
- specifying this information. This reply is used in
- command sequence groups.
-
- 4yz Transient Negative Completion reply
-
- The command was not accepted and the requested action did
- not occur. However, the error condition is temporary and
- the action may be requested again. The sender should
-
-
-
-[Page 48] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- return to the beginning of the command sequence (if any).
- It is difficult to assign a meaning to "transient" when
- two different sites (receiver- and sender- SMTPs) must
- agree on the interpretation. Each reply in this category
- might have a different time value, but the sender-SMTP is
- encouraged to try again. A rule of thumb to determine if
- a reply fits into the 4yz or the 5yz category (see below)
- is that replies are 4yz if they can be repeated without
- any change in command form or in properties of the sender
- or receiver. (E.g., the command is repeated identically
- and the receiver does not put up a new implementation.)
-
- 5yz Permanent Negative Completion reply
-
- The command was not accepted and the requested action did
- not occur. The sender-SMTP is discouraged from repeating
- the exact request (in the same sequence). Even some
- "permanent" error conditions can be corrected, so the
- human user may want to direct the sender-SMTP to
- reinitiate the command sequence by direct action at some
- point in the future (e.g., after the spelling has been
- changed, or the user has altered the account status).
-
- The second digit encodes responses in specific categories:
-
- x0z Syntax -- These replies refer to syntax errors,
- syntactically correct commands that don't fit any
- functional category, and unimplemented or superfluous
- commands.
-
- x1z Information -- These are replies to requests for
- information, such as status or help.
-
- x2z Connections -- These are replies referring to the
- transmission channel.
-
- x3z Unspecified as yet.
-
- x4z Unspecified as yet.
-
- x5z Mail system -- These replies indicate the status of
- the receiver mail system vis-a-vis the requested
- transfer or other mail system action.
-
- The third digit gives a finer gradation of meaning in each
- category specified by the second digit. The list of replies
-
-
-
-Postel [Page 49]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- illustrates this. Each reply text is recommended rather than
- mandatory, and may even change according to the command with
- which it is associated. On the other hand, the reply codes
- must strictly follow the specifications in this section.
- Receiver implementations should not invent new codes for
- slightly different situations from the ones described here, but
- rather adapt codes already defined.
-
- For example, a command such as NOOP whose successful execution
- does not offer the sender-SMTP any new information will return
- a 250 reply. The response is 502 when the command requests an
- unimplemented non-site-specific action. A refinement of that
- is the 504 reply for a command that is implemented, but that
- requests an unimplemented parameter.
-
- The reply text may be longer than a single line; in these cases
- the complete text must be marked so the sender-SMTP knows when it
- can stop reading the reply. This requires a special format to
- indicate a multiple line reply.
-
- The format for multiline replies requires that every line,
- except the last, begin with the reply code, followed
- immediately by a hyphen, "-" (also known as minus), followed by
- text. The last line will begin with the reply code, followed
- immediately by <SP>, optionally some text, and <CRLF>.
-
- For example:
- 123-First line
- 123-Second line
- 123-234 text beginning with numbers
- 123 The last line
-
- In many cases the sender-SMTP then simply needs to search for
- the reply code followed by <SP> at the beginning of a line, and
- ignore all preceding lines. In a few cases, there is important
- data for the sender in the reply "text". The sender will know
- these cases from the current context.
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 50] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
-APPENDIX F
-
- Scenarios
-
- This section presents complete scenarios of several types of SMTP
- sessions.
-
- A Typical SMTP Transaction Scenario
-
- This SMTP example shows mail sent by Smith at host USC-ISIF, to
- Jones, Green, and Brown at host BBN-UNIX. Here we assume that
- host USC-ISIF contacts host BBN-UNIX directly. The mail is
- accepted for Jones and Brown. Green does not have a mailbox at
- host BBN-UNIX.
-
- -------------------------------------------------------------
-
- R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
- S: HELO USC-ISIF.ARPA
- R: 250 BBN-UNIX.ARPA
-
- S: MAIL FROM:<address@hidden>
- R: 250 OK
-
- S: RCPT TO:<address@hidden>
- R: 250 OK
-
- S: RCPT TO:<address@hidden>
- R: 550 No such user here
-
- S: RCPT TO:<address@hidden>
- R: 250 OK
-
- S: DATA
- R: 354 Start mail input; end with <CRLF>.<CRLF>
- S: Blah blah blah...
- S: ...etc. etc. etc.
- S: .
- R: 250 OK
-
- S: QUIT
- R: 221 BBN-UNIX.ARPA Service closing transmission channel
-
- Scenario 1
-
- -------------------------------------------------------------
-
-
-
-Postel [Page 51]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- Aborted SMTP Transaction Scenario
-
- -------------------------------------------------------------
-
- R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready
- S: HELO ISI-VAXA.ARPA
- R: 250 MIT-Multics.ARPA
-
- S: MAIL FROM:<address@hidden>
- R: 250 OK
-
- S: RCPT TO:<address@hidden>
- R: 250 OK
-
- S: RCPT TO:<address@hidden>
- R: 550 No such user here
-
- S: RSET
- R: 250 OK
-
- S: QUIT
- R: 221 MIT-Multics.ARPA Service closing transmission channel
-
- Scenario 2
-
- -------------------------------------------------------------
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 52] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- Relayed Mail Scenario
-
- -------------------------------------------------------------
-
- Step 1 -- Source Host to Relay Host
-
- R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
- S: HELO MIT-AI.ARPA
- R: 250 USC-ISIE.ARPA
-
- S: MAIL FROM:<address@hidden>
- R: 250 OK
-
- S: RCPT TO:<@USC-ISIE.ARPA:address@hidden>
- R: 250 OK
-
- S: DATA
- R: 354 Start mail input; end with <CRLF>.<CRLF>
- S: Date: 2 Nov 81 22:33:44
- S: From: John Q. Public <address@hidden>
- S: Subject: The Next Meeting of the Board
- S: To: address@hidden
- S:
- S: Bill:
- S: The next meeting of the board of directors will be
- S: on Tuesday.
- S: John.
- S: .
- R: 250 OK
-
- S: QUIT
- R: 221 USC-ISIE.ARPA Service closing transmission channel
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Postel [Page 53]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- Step 2 -- Relay Host to Destination Host
-
- R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready
- S: HELO USC-ISIE.ARPA
- R: 250 BBN-VAX.ARPA
-
- S: MAIL FROM:<@USC-ISIE.ARPA:address@hidden>
- R: 250 OK
-
- S: RCPT TO:<address@hidden>
- R: 250 OK
-
- S: DATA
- R: 354 Start mail input; end with <CRLF>.<CRLF>
- S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ;
- 2 Nov 81 22:40:10 UT
- S: Date: 2 Nov 81 22:33:44
- S: From: John Q. Public <address@hidden>
- S: Subject: The Next Meeting of the Board
- S: To: address@hidden
- S:
- S: Bill:
- S: The next meeting of the board of directors will be
- S: on Tuesday.
- S: John.
- S: .
- R: 250 OK
-
- S: QUIT
- R: 221 USC-ISIE.ARPA Service closing transmission channel
-
- Scenario 3
-
- -------------------------------------------------------------
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 54] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- Verifying and Sending Scenario
-
- -------------------------------------------------------------
-
- R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
- S: HELO MIT-MC.ARPA
- R: 250 SU-SCORE.ARPA
-
- S: VRFY Crispin
- R: 250 Mark Crispin <address@hidden>
-
- S: SEND FROM:<address@hidden>
- R: 250 OK
-
- S: RCPT TO:<address@hidden>
- R: 250 OK
-
- S: DATA
- R: 354 Start mail input; end with <CRLF>.<CRLF>
- S: Blah blah blah...
- S: ...etc. etc. etc.
- S: .
- R: 250 OK
-
- S: QUIT
- R: 221 SU-SCORE.ARPA Service closing transmission channel
-
- Scenario 4
-
- -------------------------------------------------------------
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Postel [Page 55]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- Sending and Mailing Scenarios
-
- First the user's name is verified, then an attempt is made to
- send to the user's terminal. When that fails, the messages is
- mailed to the user's mailbox.
-
- -------------------------------------------------------------
-
- R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
- S: HELO MIT-MC.ARPA
- R: 250 SU-SCORE.ARPA
-
- S: VRFY Crispin
- R: 250 Mark Crispin <address@hidden>
-
- S: SEND FROM:<address@hidden>
- R: 250 OK
-
- S: RCPT TO:<address@hidden>
- R: 450 User not active now
-
- S: RSET
- R: 250 OK
-
- S: MAIL FROM:<address@hidden>
- R: 250 OK
-
- S: RCPT TO:<address@hidden>
- R: 250 OK
-
- S: DATA
- R: 354 Start mail input; end with <CRLF>.<CRLF>
- S: Blah blah blah...
- S: ...etc. etc. etc.
- S: .
- R: 250 OK
-
- S: QUIT
- R: 221 SU-SCORE.ARPA Service closing transmission channel
-
- Scenario 5
-
- -------------------------------------------------------------
-
-
-
-
-
-
-[Page 56] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- Doing the preceding scenario more efficiently.
-
- -------------------------------------------------------------
-
- R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
- S: HELO MIT-MC.ARPA
- R: 250 SU-SCORE.ARPA
-
- S: VRFY Crispin
- R: 250 Mark Crispin <address@hidden>
-
- S: SOML FROM:<address@hidden>
- R: 250 OK
-
- S: RCPT TO:<address@hidden>
- R: 250 User not active now, so will do mail.
-
- S: DATA
- R: 354 Start mail input; end with <CRLF>.<CRLF>
- S: Blah blah blah...
- S: ...etc. etc. etc.
- S: .
- R: 250 OK
-
- S: QUIT
- R: 221 SU-SCORE.ARPA Service closing transmission channel
-
- Scenario 6
-
- -------------------------------------------------------------
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Postel [Page 57]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- Mailing List Scenario
-
- First each of two mailing lists are expanded in separate sessions
- with different hosts. Then the message is sent to everyone that
- appeared on either list (but no duplicates) via a relay host.
-
- -------------------------------------------------------------
-
- Step 1 -- Expanding the First List
-
- R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready
- S: HELO SU-SCORE.ARPA
- R: 250 MIT-AI.ARPA
-
- S: EXPN Example-People
- R: 250-<address@hidden>
- R: 250-Fred Fonebone <address@hidden>
- R: 250-Xenon Y. Zither <address@hidden>
- R: 250-Quincy Smith <@USC-ISIF.ARPA:address@hidden>
- R: 250-<address@hidden>
- R: 250 <address@hidden>
-
- S: QUIT
- R: 221 MIT-AI.ARPA Service closing transmission channel
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 58] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- Step 2 -- Expanding the Second List
-
- R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready
- S: HELO SU-SCORE.ARPA
- R: 250 MIT-MC.ARPA
-
- S: EXPN Interested-Parties
- R: 250-Al Calico <address@hidden>
- R: 250-<address@hidden>
- R: 250-Quincy Smith <@USC-ISIF.ARPA:address@hidden>
- R: 250-<address@hidden>
- R: 250 <address@hidden>
-
- S: QUIT
- R: 221 MIT-MC.ARPA Service closing transmission channel
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Postel [Page 59]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- Step 3 -- Mailing to All via a Relay Host
-
- R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
- S: HELO SU-SCORE.ARPA
- R: 250 USC-ISIE.ARPA
-
- S: MAIL FROM:<address@hidden>
- R: 250 OK
- S: RCPT TO:<@USC-ISIE.ARPA:address@hidden>
- R: 250 OK
- S: RCPT TO:<@USC-ISIE.ARPA:address@hidden>
- R: 250 OK
- S: RCPT TO:<@USC-ISIE.ARPA:address@hidden>
- R: 250 OK
- S: RCPT
- TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:address@hidden>
- R: 250 OK
- S: RCPT TO:<@USC-ISIE.ARPA:address@hidden>
- R: 250 OK
- S: RCPT TO:<@USC-ISIE.ARPA:address@hidden>
- R: 250 OK
- S: RCPT TO:<@USC-ISIE.ARPA:address@hidden>
- R: 250 OK
-
- S: DATA
- R: 354 Start mail input; end with <CRLF>.<CRLF>
- S: Blah blah blah...
- S: ...etc. etc. etc.
- S: .
- R: 250 OK
-
- S: QUIT
- R: 221 USC-ISIE.ARPA Service closing transmission channel
-
- Scenario 7
-
- -------------------------------------------------------------
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 60] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- Forwarding Scenarios
-
- -------------------------------------------------------------
-
- R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
- S: HELO LBL-UNIX.ARPA
- R: 250 USC-ISIF.ARPA
-
- S: MAIL FROM:<address@hidden>
- R: 250 OK
-
- S: RCPT TO:<address@hidden>
- R: 251 User not local; will forward to <address@hidden>
-
- S: DATA
- R: 354 Start mail input; end with <CRLF>.<CRLF>
- S: Blah blah blah...
- S: ...etc. etc. etc.
- S: .
- R: 250 OK
-
- S: QUIT
- R: 221 USC-ISIF.ARPA Service closing transmission channel
-
- Scenario 8
-
- -------------------------------------------------------------
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Postel [Page 61]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- -------------------------------------------------------------
-
- Step 1 -- Trying the Mailbox at the First Host
-
- R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
- S: HELO LBL-UNIX.ARPA
- R: 250 USC-ISIF.ARPA
-
- S: MAIL FROM:<address@hidden>
- R: 250 OK
-
- S: RCPT TO:<address@hidden>
- R: 251 User not local; will forward to <address@hidden>
-
- S: RSET
- R: 250 OK
-
- S: QUIT
- R: 221 USC-ISIF.ARPA Service closing transmission channel
-
- Step 2 -- Delivering the Mail at the Second Host
-
- R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready
- S: HELO LBL-UNIX.ARPA
- R: 250 USC-ISI.ARPA
-
- S: MAIL FROM:<address@hidden>
- R: 250 OK
-
- S: RCPT TO:<address@hidden>
- R: OK
-
- S: DATA
- R: 354 Start mail input; end with <CRLF>.<CRLF>
- S: Blah blah blah...
- S: ...etc. etc. etc.
- S: .
- R: 250 OK
-
- S: QUIT
- R: 221 USC-ISI.ARPA Service closing transmission channel
-
- Scenario 9
-
- -------------------------------------------------------------
-
-
-
-
-[Page 62] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- Too Many Recipients Scenario
-
- -------------------------------------------------------------
-
- R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready
- S: HELO USC-ISIF.ARPA
- R: 250 BERKELEY.ARPA
-
- S: MAIL FROM:<address@hidden>
- R: 250 OK
-
- S: RCPT TO:<address@hidden>
- R: 250 OK
-
- S: RCPT TO:<address@hidden>
- R: 552 Recipient storage full, try again in another transaction
-
- S: DATA
- R: 354 Start mail input; end with <CRLF>.<CRLF>
- S: Blah blah blah...
- S: ...etc. etc. etc.
- S: .
- R: 250 OK
-
- S: MAIL FROM:<address@hidden>
- R: 250 OK
-
- S: RCPT TO:<address@hidden>
- R: 250 OK
-
- S: DATA
- R: 354 Start mail input; end with <CRLF>.<CRLF>
- S: Blah blah blah...
- S: ...etc. etc. etc.
- S: .
- R: 250 OK
-
- S: QUIT
- R: 221 BERKELEY.ARPA Service closing transmission channel
-
- Scenario 10
-
- -------------------------------------------------------------
-
- Note that a real implementation must handle many recipients as
- specified in Section 4.5.3.
-
-
-
-Postel [Page 63]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
-GLOSSARY
-
- ASCII
-
- American Standard Code for Information Interchange [1].
-
- command
-
- A request for a mail service action sent by the sender-SMTP to the
- receiver-SMTP.
-
- domain
-
- The hierarchially structured global character string address of a
- host computer in the mail system.
-
- end of mail data indication
-
- A special sequence of characters that indicates the end of the
- mail data. In particular, the five characters carriage return,
- line feed, period, carriage return, line feed, in that order.
-
- host
-
- A computer in the internetwork environment on which mailboxes or
- SMTP processes reside.
-
- line
-
- A a sequence of ASCII characters ending with a <CRLF>.
-
- mail data
-
- A sequence of ASCII characters of arbitrary length, which conforms
- to the standard set in the Standard for the Format of ARPA
- Internet Text Messages (RFC 822 [2]).
-
- mailbox
-
- A character string (address) which identifies a user to whom mail
- is to be sent. Mailbox normally consists of the host and user
- specifications. The standard mailbox naming convention is defined
- to be "address@hidden". Additionally, the "container" in which mail
- is stored.
-
-
-
-
-
-[Page 64] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
- receiver-SMTP process
-
- A process which transfers mail in cooperation with a sender-SMTP
- process. It waits for a connection to be established via the
- transport service. It receives SMTP commands from the
- sender-SMTP, sends replies, and performs the specified operations.
-
- reply
-
- A reply is an acknowledgment (positive or negative) sent from
- receiver to sender via the transmission channel in response to a
- command. The general form of a reply is a completion code
- (including error codes) followed by a text string. The codes are
- for use by programs and the text is usually intended for human
- users.
-
- sender-SMTP process
-
- A process which transfers mail in cooperation with a receiver-SMTP
- process. A local language may be used in the user interface
- command/reply dialogue. The sender-SMTP initiates the transport
- service connection. It initiates SMTP commands, receives replies,
- and governs the transfer of mail.
-
- session
-
- The set of exchanges that occur while the transmission channel is
- open.
-
- transaction
-
- The set of exchanges required for one message to be transmitted
- for one or more recipients.
-
- transmission channel
-
- A full-duplex communication path between a sender-SMTP and a
- receiver-SMTP for the exchange of commands, replies, and mail
- text.
-
- transport service
-
- Any reliable stream-oriented data communication services. For
- example, NCP, TCP, NITS.
-
-
-
-
-
-Postel [Page 65]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- user
-
- A human being (or a process on behalf of a human being) wishing to
- obtain mail transfer service. In addition, a recipient of
- computer mail.
-
- word
-
- A sequence of printing characters.
-
- <CRLF>
-
- The characters carriage return and line feed (in that order).
-
- <SP>
-
- The space character.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 66] Postel
-
-
-
-RFC 821 August 1982
- Simple Mail Transfer Protocol
-
-
-
-REFERENCES
-
- [1] ASCII
-
- ASCII, "USA Code for Information Interchange", United States of
- America Standards Institute, X3.4, 1968. Also in: Feinler, E.
- and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for
- the Defense Communications Agency by SRI International, Menlo
- Park, California, Revised January 1978.
-
- [2] RFC 822
-
- Crocker, D., "Standard for the Format of ARPA Internet Text
- Messages," RFC 822, Department of Electrical Engineering,
- University of Delaware, August 1982.
-
- [3] TCP
-
- Postel, J., ed., "Transmission Control Protocol - DARPA Internet
- Program Protocol Specification", RFC 793, USC/Information Sciences
- Institute, NTIS AD Number A111091, September 1981. Also in:
- Feinler, E. and J. Postel, eds., "Internet Protocol Transition
- Workbook", SRI International, Menlo Park, California, March 1982.
-
- [4] NCP
-
- McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246,
- January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET
- Protocol Handbook", NIC 7104, for the Defense Communications
- Agency by SRI International, Menlo Park, California, Revised
- January 1978.
-
- [5] Initial Connection Protocol
-
- Postel, J., "Official Initial Connection Protocol", NIC 7101,
- 11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET
- Protocol Handbook", NIC 7104, for the Defense Communications
- Agency by SRI International, Menlo Park, California, Revised
- January 1978.
-
- [6] NITS
-
- PSS/SG3, "A Network Independent Transport Service", Study Group 3,
- The Post Office PSS Users Group, February 1980. Available from
- the DCPU, National Physical Laboratory, Teddington, UK.
-
-
-
-
-Postel [Page 67]
-
-
-
-August 1982 RFC 821
-Simple Mail Transfer Protocol
-
-
-
- [7] X.25
-
- CCITT, "Recommendation X.25 - Interface Between Data Terminal
- Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for
- Terminals Operating in the Packet Mode on Public Data Networks,"
- CCITT Orange Book, Vol. VIII.2, International Telephone and
- Telegraph Consultative Committee, Geneva, 1976.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-[Page 68] Postel
-
diff --git a/doc/rfc/rfc822.txt b/doc/rfc/rfc822.txt
deleted file mode 100644
index 35b09a3..0000000
--- a/doc/rfc/rfc822.txt
+++ /dev/null
@@ -1,2901 +0,0 @@
-
-
-
-
-
-
- RFC # 822
-
- Obsoletes: RFC #733 (NIC #41952)
-
-
-
-
-
-
-
-
-
-
-
-
- STANDARD FOR THE FORMAT OF
-
- ARPA INTERNET TEXT MESSAGES
-
-
-
-
-
-
- August 13, 1982
-
-
-
-
-
-
- Revised by
-
- David H. Crocker
-
-
- Dept. of Electrical Engineering
- University of Delaware, Newark, DE 19711
- Network: DCrocker @ UDel-Relay
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- TABLE OF CONTENTS
-
-
- PREFACE .................................................... ii
-
- 1. INTRODUCTION ........................................... 1
-
- 1.1. Scope ............................................ 1
- 1.2. Communication Framework .......................... 2
-
- 2. NOTATIONAL CONVENTIONS ................................. 3
-
- 3. LEXICAL ANALYSIS OF MESSAGES ........................... 5
-
- 3.1. General Description .............................. 5
- 3.2. Header Field Definitions ......................... 9
- 3.3. Lexical Tokens ................................... 10
- 3.4. Clarifications ................................... 11
-
- 4. MESSAGE SPECIFICATION .................................. 17
-
- 4.1. Syntax ........................................... 17
- 4.2. Forwarding ....................................... 19
- 4.3. Trace Fields ..................................... 20
- 4.4. Originator Fields ................................ 21
- 4.5. Receiver Fields .................................. 23
- 4.6. Reference Fields ................................. 23
- 4.7. Other Fields ..................................... 24
-
- 5. DATE AND TIME SPECIFICATION ............................ 26
-
- 5.1. Syntax ........................................... 26
- 5.2. Semantics ........................................ 26
-
- 6. ADDRESS SPECIFICATION .................................. 27
-
- 6.1. Syntax ........................................... 27
- 6.2. Semantics ........................................ 27
- 6.3. Reserved Address ................................. 33
-
- 7. BIBLIOGRAPHY ........................................... 34
-
-
- APPENDIX
-
- A. EXAMPLES ............................................... 36
- B. SIMPLE FIELD PARSING ................................... 40
- C. DIFFERENCES FROM RFC #733 .............................. 41
- D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44
-
-
- August 13, 1982 - i - RFC #822
-
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- PREFACE
-
-
- By 1977, the Arpanet employed several informal standards for
- the text messages (mail) sent among its host computers. It was
- felt necessary to codify these practices and provide for those
- features that seemed imminent. The result of that effort was
- Request for Comments (RFC) #733, "Standard for the Format of ARPA
- Network Text Message", by Crocker, Vittal, Pogran, and Henderson.
- The specification attempted to avoid major changes in existing
- software, while permitting several new features.
-
- This document revises the specifications in RFC #733, in
- order to serve the needs of the larger and more complex ARPA
- Internet. Some of RFC #733's features failed to gain adequate
- acceptance. In order to simplify the standard and the software
- that follows it, these features have been removed. A different
- addressing scheme is used, to handle the case of inter-network
- mail; and the concept of re-transmission has been introduced.
-
- This specification is intended for use in the ARPA Internet.
- However, an attempt has been made to free it of any dependence on
- that environment, so that it can be applied to other network text
- message systems.
-
- The specification of RFC #733 took place over the course of
- one year, using the ARPANET mail environment, itself, to provide
- an on-going forum for discussing the capabilities to be included.
- More than twenty individuals, from across the country, partici-
- pated in the original discussion. The development of this
- revised specification has, similarly, utilized network mail-based
- group discussion. Both specification efforts greatly benefited
- from the comments and ideas of the participants.
-
- The syntax of the standard, in RFC #733, was originally
- specified in the Backus-Naur Form (BNF) meta-language. Ken L.
- Harrenstien, of SRI International, was responsible for re-coding
- the BNF into an augmented BNF that makes the representation
- smaller and easier to understand.
-
-
-
-
-
-
-
-
-
-
-
-
- August 13, 1982 - ii - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- 1. INTRODUCTION
-
- 1.1. SCOPE
-
- This standard specifies a syntax for text messages that are
- sent among computer users, within the framework of "electronic
- mail". The standard supersedes the one specified in ARPANET
- Request for Comments #733, "Standard for the Format of ARPA Net-
- work Text Messages".
-
- In this context, messages are viewed as having an envelope
- and contents. The envelope contains whatever information is
- needed to accomplish transmission and delivery. The contents
- compose the object to be delivered to the recipient. This stan-
- dard applies only to the format and some of the semantics of mes-
- sage contents. It contains no specification of the information
- in the envelope.
-
- However, some message systems may use information from the
- contents to create the envelope. It is intended that this stan-
- dard facilitate the acquisition of such information by programs.
-
- Some message systems may store messages in formats that
- differ from the one specified in this standard. This specifica-
- tion is intended strictly as a definition of what message content
- format is to be passed BETWEEN hosts.
-
- Note: This standard is NOT intended to dictate the internal for-
- mats used by sites, the specific message system features
- that they are expected to support, or any of the charac-
- teristics of user interface programs that create or read
- messages.
-
- A distinction should be made between what the specification
- REQUIRES and what it ALLOWS. Messages can be made complex and
- rich with formally-structured components of information or can be
- kept small and simple, with a minimum of such information. Also,
- the standard simplifies the interpretation of differing visual
- formats in messages; only the visual aspect of a message is
- affected and not the interpretation of information within it.
- Implementors may choose to retain such visual distinctions.
-
- The formal definition is divided into four levels. The bot-
- tom level describes the meta-notation used in this document. The
- second level describes basic lexical analyzers that feed tokens
- to higher-level parsers. Next is an overall specification for
- messages; it permits distinguishing individual fields. Finally,
- there is definition of the contents of several structured fields.
-
-
-
- August 13, 1982 - 1 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- 1.2. COMMUNICATION FRAMEWORK
-
- Messages consist of lines of text. No special provisions
- are made for encoding drawings, facsimile, speech, or structured
- text. No significant consideration has been given to questions
- of data compression or to transmission and storage efficiency,
- and the standard tends to be free with the number of bits con-
- sumed. For example, field names are specified as free text,
- rather than special terse codes.
-
- A general "memo" framework is used. That is, a message con-
- sists of some information in a rigid format, followed by the main
- part of the message, with a format that is not specified in this
- document. The syntax of several fields of the rigidly-formated
- ("headers") section is defined in this specification; some of
- these fields must be included in all messages.
-
- The syntax that distinguishes between header fields is
- specified separately from the internal syntax for particular
- fields. This separation is intended to allow simple parsers to
- operate on the general structure of messages, without concern for
- the detailed structure of individual header fields. Appendix B
- is provided to facilitate construction of these parsers.
-
- In addition to the fields specified in this document, it is
- expected that other fields will gain common use. As necessary,
- the specifications for these "extension-fields" will be published
- through the same mechanism used to publish this document. Users
- may also wish to extend the set of fields that they use
- privately. Such "user-defined fields" are permitted.
-
- The framework severely constrains document tone and appear-
- ance and is primarily useful for most intra-organization communi-
- cations and well-structured inter-organization communication.
- It also can be used for some types of inter-process communica-
- tion, such as simple file transfer and remote job entry. A more
- robust framework might allow for multi-font, multi-color, multi-
- dimension encoding of information. A less robust one, as is
- present in most single-machine message systems, would more
- severely constrain the ability to add fields and the decision to
- include specific fields. In contrast with paper-based communica-
- tion, it is interesting to note that the RECEIVER of a message
- can exercise an extraordinary amount of control over the
- message's appearance. The amount of actual control available to
- message receivers is contingent upon the capabilities of their
- individual message systems.
-
-
-
-
-
- August 13, 1982 - 2 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- 2. NOTATIONAL CONVENTIONS
-
- This specification uses an augmented Backus-Naur Form (BNF)
- notation. The differences from standard BNF involve naming rules
- and indicating repetition and "local" alternatives.
-
- 2.1. RULE NAMING
-
- Angle brackets ("<", ">") are not used, in general. The
- name of a rule is simply the name itself, rather than "<name>".
- Quotation-marks enclose literal text (which may be upper and/or
- lower case). Certain basic rules are in uppercase, such as
- SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used in
- rule definitions, and in the rest of this document, whenever
- their presence will facilitate discerning the use of rule names.
-
- 2.2. RULE1 / RULE2: ALTERNATIVES
-
- Elements separated by slash ("/") are alternatives. There-
- fore "foo / bar" will accept foo or bar.
-
- 2.3. (RULE1 RULE2): LOCAL ALTERNATIVES
-
- Elements enclosed in parentheses are treated as a single
- element. Thus, "(elem (foo / bar) elem)" allows the token
- sequences "elem foo elem" and "elem bar elem".
-
- 2.4. *RULE: REPETITION
-
- The character "*" preceding an element indicates repetition.
- The full form is:
-
- <l>*<m>element
-
- indicating at least <l> and at most <m> occurrences of element.
- Default values are 0 and infinity so that "*(element)" allows any
- number, including zero; "1*element" requires at least one; and
- "1*2element" allows one or two.
-
- 2.5. [RULE]: OPTIONAL
-
- Square brackets enclose optional elements; "[foo bar]" is
- equivalent to "*1(foo bar)".
-
- 2.6. NRULE: SPECIFIC REPETITION
-
- "<n>(element)" is equivalent to "<n>*<n>(element)"; that is,
- exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit
- number, and 3ALPHA is a string of three alphabetic characters.
-
-
- August 13, 1982 - 3 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- 2.7. #RULE: LISTS
-
- A construct "#" is defined, similar to "*", as follows:
-
- <l>#<m>element
-
- indicating at least <l> and at most <m> elements, each separated
- by one or more commas (","). This makes the usual form of lists
- very easy; a rule such as '(element *("," element))' can be shown
- as "1#element". Wherever this construct is used, null elements
- are allowed, but do not contribute to the count of elements
- present. That is, "(element),,(element)" is permitted, but
- counts as only two elements. Therefore, where at least one ele-
- ment is required, at least one non-null element must be present.
- Default values are 0 and infinity so that "#(element)" allows any
- number, including zero; "1#element" requires at least one; and
- "1#2element" allows one or two.
-
- 2.8. ; COMMENTS
-
- A semi-colon, set off some distance to the right of rule
- text, starts a comment that continues to the end of line. This
- is a simple way of including useful notes in parallel with the
- specifications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- August 13, 1982 - 4 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- 3. LEXICAL ANALYSIS OF MESSAGES
-
- 3.1. GENERAL DESCRIPTION
-
- A message consists of header fields and, optionally, a body.
- The body is simply a sequence of lines containing ASCII charac-
- ters. It is separated from the headers by a null line (i.e., a
- line with nothing preceding the CRLF).
-
- 3.1.1. LONG HEADER FIELDS
-
- Each header field can be viewed as a single, logical line of
- ASCII characters, comprising a field-name and a field-body.
- For convenience, the field-body portion of this conceptual
- entity can be split into a multiple-line representation; this
- is called "folding". The general rule is that wherever there
- may be linear-white-space (NOT simply LWSP-chars), a CRLF
- immediately followed by AT LEAST one LWSP-char may instead be
- inserted. Thus, the single line
-
- To: "Joe & J. Harvey" <ddd @Org>, JJV @ BBN
-
- can be represented as:
-
- To: "Joe & J. Harvey" <ddd @ Org>,
- address@hidden
-
- and
-
- To: "Joe & J. Harvey"
- <ddd@ Org>, JJV
- @BBN
-
- and
-
- To: "Joe &
- J. Harvey" <ddd @ Org>, JJV @ BBN
-
- The process of moving from this folded multiple-line
- representation of a header field to its single line represen-
- tation is called "unfolding". Unfolding is accomplished by
- regarding CRLF immediately followed by a LWSP-char as
- equivalent to the LWSP-char.
-
- Note: While the standard permits folding wherever linear-
- white-space is permitted, it is recommended that struc-
- tured fields, such as those containing addresses, limit
- folding to higher-level syntactic breaks. For address
- fields, it is recommended that such folding occur
-
-
- August 13, 1982 - 5 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- between addresses, after the separating comma.
-
- 3.1.2. STRUCTURE OF HEADER FIELDS
-
- Once a field has been unfolded, it may be viewed as being com-
- posed of a field-name followed by a colon (":"), followed by a
- field-body, and terminated by a carriage-return/line-feed.
- The field-name must be composed of printable ASCII characters
- (i.e., characters that have values between 33. and 126.,
- decimal, except colon). The field-body may be composed of any
- ASCII characters, except CR or LF. (While CR and/or LF may be
- present in the actual text, they are removed by the action of
- unfolding the field.)
-
- Certain field-bodies of headers may be interpreted according
- to an internal syntax that some systems may wish to parse.
- These fields are called "structured fields". Examples
- include fields containing dates and addresses. Other fields,
- such as "Subject" and "Comments", are regarded simply as
- strings of text.
-
- Note: Any field which has a field-body that is defined as
- other than simply <text> is to be treated as a struc-
- tured field.
-
- Field-names, unstructured field bodies and structured
- field bodies each are scanned by their own, independent
- "lexical" analyzers.
-
- 3.1.3. UNSTRUCTURED FIELD BODIES
-
- For some fields, such as "Subject" and "Comments", no struc-
- turing is assumed, and they are treated simply as <text>s, as
- in the message body. Rules of folding apply to these fields,
- so that such field bodies which occupy several lines must
- therefore have the second and successive lines indented by at
- least one LWSP-char.
-
- 3.1.4. STRUCTURED FIELD BODIES
-
- To aid in the creation and reading of structured fields, the
- free insertion of linear-white-space (which permits folding
- by inclusion of CRLFs) is allowed between lexical tokens.
- Rather than obscuring the syntax specifications for these
- structured fields with explicit syntax for this linear-white-
- space, the existence of another "lexical" analyzer is assumed.
- This analyzer does not apply for unstructured field bodies
- that are simply strings of text, as described above. The
- analyzer provides an interpretation of the unfolded text
-
-
- August 13, 1982 - 6 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- composing the body of the field as a sequence of lexical sym-
- bols.
-
- These symbols are:
-
- - individual special characters
- - quoted-strings
- - domain-literals
- - comments
- - atoms
-
- The first four of these symbols are self-delimiting. Atoms
- are not; they are delimited by the self-delimiting symbols and
- by linear-white-space. For the purposes of regenerating
- sequences of atoms and quoted-strings, exactly one SPACE is
- assumed to exist, and should be used, between them. (Also, in
- the "Clarifications" section on "White Space", below, note the
- rules about treatment of multiple contiguous LWSP-chars.)
-
- So, for example, the folded body of an address field
-
- ":sysmail"@ Some-Group. Some-Org,
- Muhammed.(I am the greatest) Ali @(the)Vegas.WBA
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- August 13, 1982 - 7 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- is analyzed into the following lexical symbols and types:
-
- :sysmail quoted string
- @ special
- Some-Group atom
- . special
- Some-Org atom
- , special
- Muhammed atom
- . special
- (I am the greatest) comment
- Ali atom
- @ atom
- (the) comment
- Vegas atom
- . special
- WBA atom
-
- The canonical representations for the data in these addresses
- are the following strings:
-
- ":sysmail"@Some-Group.Some-Org
-
- and
-
- address@hidden
-
- Note: For purposes of display, and when passing such struc-
- tured information to other systems, such as mail proto-
- col services, there must be NO linear-white-space
- between <word>s that are separated by period (".") or
- at-sign ("@") and exactly one SPACE between all other
- <word>s. Also, headers should be in a folded form.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- August 13, 1982 - 8 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- 3.2. HEADER FIELD DEFINITIONS
-
- These rules show a field meta-syntax, without regard for the
- particular type or internal syntax. Their purpose is to permit
- detection of fields; also, they present to higher-level parsers
- an image of each field as fitting on one line.
-
- field = field-name ":" [ field-body ] CRLF
-
- field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
-
- field-body = field-body-contents
- [CRLF LWSP-char field-body]
-
- field-body-contents =
- <the ASCII characters making up the field-body, as
- defined in the following sections, and consisting
- of combinations of atom, quoted-string, and
- specials tokens, or else consisting of texts>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- August 13, 1982 - 9 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- 3.3. LEXICAL TOKENS
-
- The following rules are used to define an underlying lexical
- analyzer, which feeds tokens to higher level parsers. See the
- ANSI references, in the Bibliography.
-
- ; ( Octal, Decimal.)
- CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
- ALPHA = <any ASCII alphabetic character>
- ; (101-132, 65.- 90.)
- ; (141-172, 97.-122.)
- DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.)
- CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
- character and DEL> ; ( 177, 127.)
- CR = <ASCII CR, carriage return> ; ( 15, 13.)
- LF = <ASCII LF, linefeed> ; ( 12, 10.)
- SPACE = <ASCII SP, space> ; ( 40, 32.)
- HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
- <"> = <ASCII quote mark> ; ( 42, 34.)
- CRLF = CR LF
-
- LWSP-char = SPACE / HTAB ; semantics = SPACE
-
- linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE
- ; CRLF => folding
-
- specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
- / "," / ";" / ":" / "\" / <"> ; string, to use
- / "." / "[" / "]" ; within a word.
-
- delimiters = specials / linear-white-space / comment
-
- text = <any CHAR, including bare ; => atoms, specials,
- CR & bare LF, but NOT ; comments and
- including CRLF> ; quoted-strings are
- ; NOT recognized.
-
- atom = 1*<any CHAR except specials, SPACE and CTLs>
-
- quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
- ; quoted chars.
-
- qtext = <any CHAR excepting <">, ; => may be folded
- "\" & CR, and including
- linear-white-space>
-
- domain-literal = "[" *(dtext / quoted-pair) "]"
-
-
-
-
- August 13, 1982 - 10 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- dtext = <any CHAR excluding "[", ; => may be folded
- "]", "\" & CR, & including
- linear-white-space>
-
- comment = "(" *(ctext / quoted-pair / comment) ")"
-
- ctext = <any CHAR excluding "(", ; => may be folded
- ")", "\" & CR, & including
- linear-white-space>
-
- quoted-pair = "\" CHAR ; may quote any char
-
- phrase = 1*word ; Sequence of words
-
- word = atom / quoted-string
-
-
- 3.4. CLARIFICATIONS
-
- 3.4.1. QUOTING
-
- Some characters are reserved for special interpretation, such
- as delimiting lexical tokens. To permit use of these charac-
- ters as uninterpreted data, a quoting mechanism is provided.
- To quote a character, precede it with a backslash ("\").
-
- This mechanism is not fully general. Characters may be quoted
- only within a subset of the lexical constructs. In particu-
- lar, quoting is limited to use within:
-
- - quoted-string
- - domain-literal
- - comment
-
- Within these constructs, quoting is REQUIRED for CR and "\"
- and for the character(s) that delimit the token (e.g., "(" and
- ")" for a comment). However, quoting is PERMITTED for any
- character.
-
- Note: In particular, quoting is NOT permitted within atoms.
- For example when the local-part of an addr-spec must
- contain a special character, a quoted string must be
- used. Therefore, a specification such as:
-
- Full\ address@hidden
-
- is not legal and must be specified as:
-
- "Full Name"@Domain
-
-
- August 13, 1982 - 11 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- 3.4.2. WHITE SPACE
-
- Note: In structured field bodies, multiple linear space ASCII
- characters (namely HTABs and SPACEs) are treated as
- single spaces and may freely surround any symbol. In
- all header fields, the only place in which at least one
- LWSP-char is REQUIRED is at the beginning of continua-
- tion lines in a folded field.
-
- When passing text to processes that do not interpret text
- according to this standard (e.g., mail protocol servers), then
- NO linear-white-space characters should occur between a period
- (".") or at-sign ("@") and a <word>. Exactly ONE SPACE should
- be used in place of arbitrary linear-white-space and comment
- sequences.
-
- Note: Within systems conforming to this standard, wherever a
- member of the list of delimiters is allowed, LWSP-chars
- may also occur before and/or after it.
-
- Writers of mail-sending (i.e., header-generating) programs
- should realize that there is no network-wide definition of the
- effect of ASCII HT (horizontal-tab) characters on the appear-
- ance of text at another network host; therefore, the use of
- tabs in message headers, though permitted, is discouraged.
-
- 3.4.3. COMMENTS
-
- A comment is a set of ASCII characters, which is enclosed in
- matching parentheses and which is not within a quoted-string
- The comment construct permits message originators to add text
- which will be useful for human readers, but which will be
- ignored by the formal semantics. Comments should be retained
- while the message is subject to interpretation according to
- this standard. However, comments must NOT be included in
- other cases, such as during protocol exchanges with mail
- servers.
-
- Comments nest, so that if an unquoted left parenthesis occurs
- in a comment string, there must also be a matching right
- parenthesis. When a comment acts as the delimiter between a
- sequence of two lexical symbols, such as two atoms, it is lex-
- ically equivalent with a single SPACE, for the purposes of
- regenerating the sequence, such as when passing the sequence
- onto a mail protocol server. Comments are detected as such
- only within field-bodies of structured fields.
-
- If a comment is to be "folded" onto multiple lines, then the
- syntax for folding must be adhered to. (See the "Lexical
-
-
- August 13, 1982 - 12 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- Analysis of Messages" section on "Folding Long Header Fields"
- above, and the section on "Case Independence" below.) Note
- that the official semantics therefore do not "see" any
- unquoted CRLFs that are in comments, although particular pars-
- ing programs may wish to note their presence. For these pro-
- grams, it would be reasonable to interpret a "CRLF LWSP-char"
- as being a CRLF that is part of the comment; i.e., the CRLF is
- kept and the LWSP-char is discarded. Quoted CRLFs (i.e., a
- backslash followed by a CR followed by a LF) still must be
- followed by at least one LWSP-char.
-
- 3.4.4. DELIMITING AND QUOTING CHARACTERS
-
- The quote character (backslash) and characters that delimit
- syntactic units are not, generally, to be taken as data that
- are part of the delimited or quoted unit(s). In particular,
- the quotation-marks that define a quoted-string, the
- parentheses that define a comment and the backslash that
- quotes a following character are NOT part of the quoted-
- string, comment or quoted character. A quotation-mark that is
- to be part of a quoted-string, a parenthesis that is to be
- part of a comment and a backslash that is to be part of either
- must each be preceded by the quote-character backslash ("\").
- Note that the syntax allows any character to be quoted within
- a quoted-string or comment; however only certain characters
- MUST be quoted to be included as data. These characters are
- the ones that are not part of the alternate text group (i.e.,
- ctext or qtext).
-
- The one exception to this rule is that a single SPACE is
- assumed to exist between contiguous words in a phrase, and
- this interpretation is independent of the actual number of
- LWSP-chars that the creator places between the words. To
- include more than one SPACE, the creator must make the LWSP-
- chars be part of a quoted-string.
-
- Quotation marks that delimit a quoted string and backslashes
- that quote the following character should NOT accompany the
- quoted-string when the string is passed to processes that do
- not interpret data according to this specification (e.g., mail
- protocol servers).
-
- 3.4.5. QUOTED-STRINGS
-
- Where permitted (i.e., in words in structured fields) quoted-
- strings are treated as a single symbol. That is, a quoted-
- string is equivalent to an atom, syntactically. If a quoted-
- string is to be "folded" onto multiple lines, then the syntax
- for folding must be adhered to. (See the "Lexical Analysis of
-
-
- August 13, 1982 - 13 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- Messages" section on "Folding Long Header Fields" above, and
- the section on "Case Independence" below.) Therefore, the
- official semantics do not "see" any bare CRLFs that are in
- quoted-strings; however particular parsing programs may wish
- to note their presence. For such programs, it would be rea-
- sonable to interpret a "CRLF LWSP-char" as being a CRLF which
- is part of the quoted-string; i.e., the CRLF is kept and the
- LWSP-char is discarded. Quoted CRLFs (i.e., a backslash fol-
- lowed by a CR followed by a LF) are also subject to rules of
- folding, but the presence of the quoting character (backslash)
- explicitly indicates that the CRLF is data to the quoted
- string. Stripping off the first following LWSP-char is also
- appropriate when parsing quoted CRLFs.
-
- 3.4.6. BRACKETING CHARACTERS
-
- There is one type of bracket which must occur in matched pairs
- and may have pairs nested within each other:
-
- o Parentheses ("(" and ")") are used to indicate com-
- ments.
-
- There are three types of brackets which must occur in matched
- pairs, and which may NOT be nested:
-
- o Colon/semi-colon (":" and ";") are used in address
- specifications to indicate that the included list of
- addresses are to be treated as a group.
-
- o Angle brackets ("<" and ">") are generally used to
- indicate the presence of a one machine-usable refer-
- ence (e.g., delimiting mailboxes), possibly including
- source-routing to the machine.
-
- o Square brackets ("[" and "]") are used to indicate the
- presence of a domain-literal, which the appropriate
- name-domain is to use directly, bypassing normal
- name-resolution mechanisms.
-
- 3.4.7. CASE INDEPENDENCE
-
- Except as noted, alphabetic strings may be represented in any
- combination of upper and lower case. The only syntactic units
-
-
-
-
-
-
-
-
- August 13, 1982 - 14 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- which requires preservation of case information are:
-
- - text
- - qtext
- - dtext
- - ctext
- - quoted-pair
- - local-part, except "Postmaster"
-
- When matching any other syntactic unit, case is to be ignored.
- For example, the field-names "From", "FROM", "from", and even
- "FroM" are semantically equal and should all be treated ident-
- ically.
-
- When generating these units, any mix of upper and lower case
- alphabetic characters may be used. The case shown in this
- specification is suggested for message-creating processes.
-
- Note: The reserved local-part address unit, "Postmaster", is
- an exception. When the value "Postmaster" is being
- interpreted, it must be accepted in any mixture of
- case, including "POSTMASTER", and "postmaster".
-
- 3.4.8. FOLDING LONG HEADER FIELDS
-
- Each header field may be represented on exactly one line con-
- sisting of the name of the field and its body, and terminated
- by a CRLF; this is what the parser sees. For readability, the
- field-body portion of long header fields may be "folded" onto
- multiple lines of the actual field. "Long" is commonly inter-
- preted to mean greater than 65 or 72 characters. The former
- length serves as a limit, when the message is to be viewed on
- most simple terminals which use simple display software; how-
- ever, the limit is not imposed by this standard.
-
- Note: Some display software often can selectively fold lines,
- to suit the display terminal. In such cases, sender-
- provided folding can interfere with the display
- software.
-
- 3.4.9. BACKSPACE CHARACTERS
-
- ASCII BS characters (Backspace, decimal 8) may be included in
- texts and quoted-strings to effect overstriking. However, any
- use of backspaces which effects an overstrike to the left of
- the beginning of the text or quoted-string is prohibited.
-
-
-
-
-
- August 13, 1982 - 15 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- 3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS
-
- During transmission through heterogeneous networks, it may be
- necessary to force data to conform to a network's local con-
- ventions. For example, it may be required that a CR be fol-
- lowed either by LF, making a CRLF, or by <null>, if the CR is
- to stand alone). Such transformations are reversed, when the
- message exits that network.
-
- When crossing network boundaries, the message should be
- treated as passing through two modules. It will enter the
- first module containing whatever network-specific transforma-
- tions that were necessary to permit migration through the
- "current" network. It then passes through the modules:
-
- o Transformation Reversal
-
- The "current" network's idiosyncracies are removed and
- the message is returned to the canonical form speci-
- fied in this standard.
-
- o Transformation
-
- The "next" network's local idiosyncracies are imposed
- on the message.
-
- ------------------
- From ==> | Remove Net-A |
- Net-A | idiosyncracies |
- ------------------
- ||
- \/
- Conformance
- with standard
- ||
- \/
- ------------------
- | Impose Net-B | ==> To
- | idiosyncracies | Net-B
- ------------------
-
-
-
-
-
-
-
-
-
-
-
- August 13, 1982 - 16 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- 4. MESSAGE SPECIFICATION
-
- 4.1. SYNTAX
-
- Note: Due to an artifact of the notational conventions, the syn-
- tax indicates that, when present, some fields, must be in
- a particular order. Header fields are NOT required to
- occur in any particular order, except that the message
- body must occur AFTER the headers. It is recommended
- that, if present, headers be sent in the order "Return-
- Path", "Received", "Date", "From", "Subject", "Sender",
- "To", "cc", etc.
-
- This specification permits multiple occurrences of most
- fields. Except as noted, their interpretation is not
- specified here, and their use is discouraged.
-
- The following syntax for the bodies of various fields should
- be thought of as describing each field body as a single long
- string (or line). The "Lexical Analysis of Message" section on
- "Long Header Fields", above, indicates how such long strings can
- be represented on more than one line in the actual transmitted
- message.
-
- message = fields *( CRLF *text ) ; Everything after
- ; first null line
- ; is message body
-
- fields = dates ; Creation time,
- source ; author id & one
- 1*destination ; address required
- *optional-field ; others optional
-
- source = [ trace ] ; net traversals
- originator ; original mail
- [ resent ] ; forwarded
-
- trace = return ; path to sender
- 1*received ; receipt tags
-
- return = "Return-path" ":" route-addr ; return address
-
- received = "Received" ":" ; one per relay
- ["from" domain] ; sending host
- ["by" domain] ; receiving host
- ["via" atom] ; physical path
- *("with" atom) ; link/mail protocol
- ["id" msg-id] ; receiver msg id
- ["for" addr-spec] ; initial form
-
-
- August 13, 1982 - 17 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- ";" date-time ; time received
-
- originator = authentic ; authenticated addr
- [ "Reply-To" ":" 1#address] )
-
- authentic = "From" ":" mailbox ; Single author
- / ( "Sender" ":" mailbox ; Actual submittor
- "From" ":" 1#mailbox) ; Multiple authors
- ; or not sender
-
- resent = resent-authentic
- [ "Resent-Reply-To" ":" 1#address] )
-
- resent-authentic =
- = "Resent-From" ":" mailbox
- / ( "Resent-Sender" ":" mailbox
- "Resent-From" ":" 1#mailbox )
-
- dates = orig-date ; Original
- [ resent-date ] ; Forwarded
-
- orig-date = "Date" ":" date-time
-
- resent-date = "Resent-Date" ":" date-time
-
- destination = "To" ":" 1#address ; Primary
- / "Resent-To" ":" 1#address
- / "cc" ":" 1#address ; Secondary
- / "Resent-cc" ":" 1#address
- / "bcc" ":" #address ; Blind carbon
- / "Resent-bcc" ":" #address
-
- optional-field =
- / "Message-ID" ":" msg-id
- / "Resent-Message-ID" ":" msg-id
- / "In-Reply-To" ":" *(phrase / msg-id)
- / "References" ":" *(phrase / msg-id)
- / "Keywords" ":" #phrase
- / "Subject" ":" *text
- / "Comments" ":" *text
- / "Encrypted" ":" 1#2word
- / extension-field ; To be defined
- / user-defined-field ; May be pre-empted
-
- msg-id = "<" addr-spec ">" ; Unique message id
-
-
-
-
-
-
- August 13, 1982 - 18 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- extension-field =
- <Any field which is defined in a document
- published as a formal extension to this
- specification; none will have names beginning
- with the string "X-">
-
- user-defined-field =
- <Any field which has not been defined
- in this specification or published as an
- extension to this specification; names for
- such fields must be unique and may be
- pre-empted by published extensions>
-
- 4.2. FORWARDING
-
- Some systems permit mail recipients to forward a message,
- retaining the original headers, by adding some new fields. This
- standard supports such a service, through the "Resent-" prefix to
- field names.
-
- Whenever the string "Resent-" begins a field name, the field
- has the same semantics as a field whose name does not have the
- prefix. However, the message is assumed to have been forwarded
- by an original recipient who attached the "Resent-" field. This
- new field is treated as being more recent than the equivalent,
- original field. For example, the "Resent-From", indicates the
- person that forwarded the message, whereas the "From" field indi-
- cates the original author.
-
- Use of such precedence information depends upon partici-
- pants' communication needs. For example, this standard does not
- dictate when a "Resent-From:" address should receive replies, in
- lieu of sending them to the "From:" address.
-
- Note: In general, the "Resent-" fields should be treated as con-
- taining a set of information that is independent of the
- set of original fields. Information for one set should
- not automatically be taken from the other. The interpre-
- tation of multiple "Resent-" fields, of the same type, is
- undefined.
-
- In the remainder of this specification, occurrence of legal
- "Resent-" fields are treated identically with the occurrence of
-
-
-
-
-
-
-
-
- August 13, 1982 - 19 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- fields whose names do not contain this prefix.
-
- 4.3. TRACE FIELDS
-
- Trace information is used to provide an audit trail of mes-
- sage handling. In addition, it indicates a route back to the
- sender of the message.
-
- The list of known "via" and "with" values are registered
- with the Network Information Center, SRI International, Menlo
- Park, California.
-
- 4.3.1. RETURN-PATH
-
- This field is added by the final transport system that
- delivers the message to its recipient. The field is intended
- to contain definitive information about the address and route
- back to the message's originator.
-
- Note: The "Reply-To" field is added by the originator and
- serves to direct replies, whereas the "Return-Path"
- field is used to identify a path back to the origina-
- tor.
-
- While the syntax indicates that a route specification is
- optional, every attempt should be made to provide that infor-
- mation in this field.
-
- 4.3.2. RECEIVED
-
- A copy of this field is added by each transport service that
- relays the message. The information in the field can be quite
- useful for tracing transport problems.
-
- The names of the sending and receiving hosts and time-of-
- receipt may be specified. The "via" parameter may be used, to
- indicate what physical mechanism the message was sent over,
- such as Arpanet or Phonenet, and the "with" parameter may be
- used to indicate the mail-, or connection-, level protocol
- that was used, such as the SMTP mail protocol, or X.25 tran-
- sport protocol.
-
- Note: Several "with" parameters may be included, to fully
- specify the set of protocols that were used.
-
- Some transport services queue mail; the internal message iden-
- tifier that is assigned to the message may be noted, using the
- "id" parameter. When the sending host uses a destination
- address specification that the receiving host reinterprets, by
-
-
- August 13, 1982 - 20 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- expansion or transformation, the receiving host may wish to
- record the original specification, using the "for" parameter.
- For example, when a copy of mail is sent to the member of a
- distribution list, this parameter may be used to record the
- original address that was used to specify the list.
-
- 4.4. ORIGINATOR FIELDS
-
- The standard allows only a subset of the combinations possi-
- ble with the From, Sender, Reply-To, Resent-From, Resent-Sender,
- and Resent-Reply-To fields. The limitation is intentional.
-
- 4.4.1. FROM / RESENT-FROM
-
- This field contains the identity of the person(s) who wished
- this message to be sent. The message-creation process should
- default this field to be a single, authenticated machine
- address, indicating the AGENT (person, system or process)
- entering the message. If this is not done, the "Sender" field
- MUST be present. If the "From" field IS defaulted this way,
- the "Sender" field is optional and is redundant with the
- "From" field. In all cases, addresses in the "From" field
- must be machine-usable (addr-specs) and may not contain named
- lists (groups).
-
- 4.4.2. SENDER / RESENT-SENDER
-
- This field contains the authenticated identity of the AGENT
- (person, system or process) that sends the message. It is
- intended for use when the sender is not the author of the mes-
- sage, or to indicate who among a group of authors actually
- sent the message. If the contents of the "Sender" field would
- be completely redundant with the "From" field, then the
- "Sender" field need not be present and its use is discouraged
- (though still legal). In particular, the "Sender" field MUST
- be present if it is NOT the same as the "From" Field.
-
- The Sender mailbox specification includes a word sequence
- which must correspond to a specific agent (i.e., a human user
- or a computer program) rather than a standard address. This
- indicates the expectation that the field will identify the
- single AGENT (person, system, or process) responsible for
- sending the mail and not simply include the name of a mailbox
- from which the mail was sent. For example in the case of a
- shared login name, the name, by itself, would not be adequate.
- The local-part address unit, which refers to this agent, is
- expected to be a computer system term, and not (for example) a
- generalized person reference which can be used outside the
- network text message context.
-
-
- August 13, 1982 - 21 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- Since the critical function served by the "Sender" field is
- identification of the agent responsible for sending mail and
- since computer programs cannot be held accountable for their
- behavior, it is strongly recommended that when a computer pro-
- gram generates a message, the HUMAN who is responsible for
- that program be referenced as part of the "Sender" field mail-
- box specification.
-
- 4.4.3. REPLY-TO / RESENT-REPLY-TO
-
- This field provides a general mechanism for indicating any
- mailbox(es) to which responses are to be sent. Three typical
- uses for this feature can be distinguished. In the first
- case, the author(s) may not have regular machine-based mail-
- boxes and therefore wish(es) to indicate an alternate machine
- address. In the second case, an author may wish additional
- persons to be made aware of, or responsible for, replies. A
- somewhat different use may be of some help to "text message
- teleconferencing" groups equipped with automatic distribution
- services: include the address of that service in the "Reply-
- To" field of all messages submitted to the teleconference;
- then participants can "reply" to conference submissions to
- guarantee the correct distribution of any submission of their
- own.
-
- Note: The "Return-Path" field is added by the mail transport
- service, at the time of final deliver. It is intended
- to identify a path back to the orginator of the mes-
- sage. The "Reply-To" field is added by the message
- originator and is intended to direct replies.
-
- 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO
-
- For systems which automatically generate address lists for
- replies to messages, the following recommendations are made:
-
- o The "Sender" field mailbox should be sent notices of
- any problems in transport or delivery of the original
- messages. If there is no "Sender" field, then the
- "From" field mailbox should be used.
-
- o The "Sender" field mailbox should NEVER be used
- automatically, in a recipient's reply message.
-
- o If the "Reply-To" field exists, then the reply should
- go to the addresses indicated in that field and not to
- the address(es) indicated in the "From" field.
-
-
-
-
- August 13, 1982 - 22 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- o If there is a "From" field, but no "Reply-To" field,
- the reply should be sent to the address(es) indicated
- in the "From" field.
-
- Sometimes, a recipient may actually wish to communicate with
- the person that initiated the message transfer. In such
- cases, it is reasonable to use the "Sender" address.
-
- This recommendation is intended only for automated use of
- originator-fields and is not intended to suggest that replies
- may not also be sent to other recipients of messages. It is
- up to the respective mail-handling programs to decide what
- additional facilities will be provided.
-
- Examples are provided in Appendix A.
-
- 4.5. RECEIVER FIELDS
-
- 4.5.1. TO / RESENT-TO
-
- This field contains the identity of the primary recipients of
- the message.
-
- 4.5.2. CC / RESENT-CC
-
- This field contains the identity of the secondary (informa-
- tional) recipients of the message.
-
- 4.5.3. BCC / RESENT-BCC
-
- This field contains the identity of additional recipients of
- the message. The contents of this field are not included in
- copies of the message sent to the primary and secondary reci-
- pients. Some systems may choose to include the text of the
- "Bcc" field only in the author(s)'s copy, while others may
- also include it in the text sent to all those indicated in the
- "Bcc" list.
-
- 4.6. REFERENCE FIELDS
-
- 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID
-
- This field contains a unique identifier (the local-part
- address unit) which refers to THIS version of THIS message.
- The uniqueness of the message identifier is guaranteed by the
- host which generates it. This identifier is intended to be
- machine readable and not necessarily meaningful to humans. A
- message identifier pertains to exactly one instantiation of a
- particular message; subsequent revisions to the message should
-
-
- August 13, 1982 - 23 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- each receive new message identifiers.
-
- 4.6.2. IN-REPLY-TO
-
- The contents of this field identify previous correspon-
- dence which this message answers. Note that if message iden-
- tifiers are used in this field, they must use the msg-id
- specification format.
-
- 4.6.3. REFERENCES
-
- The contents of this field identify other correspondence
- which this message references. Note that if message identif-
- iers are used, they must use the msg-id specification format.
-
- 4.6.4. KEYWORDS
-
- This field contains keywords or phrases, separated by
- commas.
-
- 4.7. OTHER FIELDS
-
- 4.7.1. SUBJECT
-
- This is intended to provide a summary, or indicate the
- nature, of the message.
-
- 4.7.2. COMMENTS
-
- Permits adding text comments onto the message without
- disturbing the contents of the message's body.
-
- 4.7.3. ENCRYPTED
-
- Sometimes, data encryption is used to increase the
- privacy of message contents. If the body of a message has
- been encrypted, to keep its contents private, the "Encrypted"
- field can be used to note the fact and to indicate the nature
- of the encryption. The first <word> parameter indicates the
- software used to encrypt the body, and the second, optional
- <word> is intended to aid the recipient in selecting the
- proper decryption key. This code word may be viewed as an
- index to a table of keys held by the recipient.
-
- Note: Unfortunately, headers must contain envelope, as well
- as contents, information. Consequently, it is neces-
- sary that they remain unencrypted, so that mail tran-
- sport services may access them. Since names,
- addresses, and "Subject" field contents may contain
-
-
- August 13, 1982 - 24 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- sensitive information, this requirement limits total
- message privacy.
-
- Names of encryption software are registered with the Net-
- work Information Center, SRI International, Menlo Park, Cali-
- fornia.
-
- 4.7.4. EXTENSION-FIELD
-
- A limited number of common fields have been defined in
- this document. As network mail requirements dictate, addi-
- tional fields may be standardized. To provide user-defined
- fields with a measure of safety, in name selection, such
- extension-fields will never have names that begin with the
- string "X-".
-
- Names of Extension-fields are registered with the Network
- Information Center, SRI International, Menlo Park, California.
-
- 4.7.5. USER-DEFINED-FIELD
-
- Individual users of network mail are free to define and
- use additional header fields. Such fields must have names
- which are not already used in the current specification or in
- any definitions of extension-fields, and the overall syntax of
- these user-defined-fields must conform to this specification's
- rules for delimiting and folding fields. Due to the
- extension-field publishing process, the name of a user-
- defined-field may be pre-empted
-
- Note: The prefatory string "X-" will never be used in the
- names of Extension-fields. This provides user-defined
- fields with a protected set of names.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- August 13, 1982 - 25 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- 5. DATE AND TIME SPECIFICATION
-
- 5.1. SYNTAX
-
- date-time = [ day "," ] date time ; dd mm yy
- ; hh:mm:ss zzz
-
- day = "Mon" / "Tue" / "Wed" / "Thu"
- / "Fri" / "Sat" / "Sun"
-
- date = 1*2DIGIT month 2DIGIT ; day month year
- ; e.g. 20 Jun 82
-
- month = "Jan" / "Feb" / "Mar" / "Apr"
- / "May" / "Jun" / "Jul" / "Aug"
- / "Sep" / "Oct" / "Nov" / "Dec"
-
- time = hour zone ; ANSI and Military
-
- hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
- ; 00:00:00 - 23:59:59
-
- zone = "UT" / "GMT" ; Universal Time
- ; North American : UT
- / "EST" / "EDT" ; Eastern: - 5/ - 4
- / "CST" / "CDT" ; Central: - 6/ - 5
- / "MST" / "MDT" ; Mountain: - 7/ - 6
- / "PST" / "PDT" ; Pacific: - 8/ - 7
- / 1ALPHA ; Military: Z = UT;
- ; A:-1; (J not used)
- ; M:-12; N:+1; Y:+12
- / ( ("+" / "-") 4DIGIT ) ; Local differential
- ; hours+min. (HHMM)
-
- 5.2. SEMANTICS
-
- If included, day-of-week must be the day implied by the date
- specification.
-
- Time zone may be indicated in several ways. "UT" is Univer-
- sal Time (formerly called "Greenwich Mean Time"); "GMT" is per-
- mitted as a reference to Universal Time. The military standard
- uses a single character for each zone. "Z" is Universal Time.
- "A" indicates one hour earlier, and "M" indicates 12 hours ear-
- lier; "N" is one hour later, and "Y" is 12 hours later. The
- letter "J" is not used. The other remaining two forms are taken
- from ANSI standard X3.51-1975. One allows explicit indication of
- the amount of offset from UT; the other uses common 3-character
- strings for indicating time zones in North America.
-
-
- August 13, 1982 - 26 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- 6. ADDRESS SPECIFICATION
-
- 6.1. SYNTAX
-
- address = mailbox ; one addressee
- / group ; named list
-
- group = phrase ":" [#mailbox] ";"
-
- mailbox = addr-spec ; simple address
- / phrase route-addr ; name & addr-spec
-
- route-addr = "<" [route] addr-spec ">"
-
- route = 1#("@" domain) ":" ; path-relative
-
- addr-spec = local-part "@" domain ; global address
-
- local-part = word *("." word) ; uninterpreted
- ; case-preserved
-
- domain = sub-domain *("." sub-domain)
-
- sub-domain = domain-ref / domain-literal
-
- domain-ref = atom ; symbolic reference
-
- 6.2. SEMANTICS
-
- A mailbox receives mail. It is a conceptual entity which
- does not necessarily pertain to file storage. For example, some
- sites may choose to print mail on their line printer and deliver
- the output to the addressee's desk.
-
- A mailbox specification comprises a person, system or pro-
- cess name reference, a domain-dependent string, and a name-domain
- reference. The name reference is optional and is usually used to
- indicate the human name of a recipient. The name-domain refer-
- ence specifies a sequence of sub-domains. The domain-dependent
- string is uninterpreted, except by the final sub-domain; the rest
- of the mail service merely transmits it as a literal string.
-
- 6.2.1. DOMAINS
-
- A name-domain is a set of registered (mail) names. A name-
- domain specification resolves to a subordinate name-domain
- specification or to a terminal domain-dependent string.
- Hence, domain specification is extensible, permitting any
- number of registration levels.
-
-
- August 13, 1982 - 27 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- Name-domains model a global, logical, hierarchical addressing
- scheme. The model is logical, in that an address specifica-
- tion is related to name registration and is not necessarily
- tied to transmission path. The model's hierarchy is a
- directed graph, called an in-tree, such that there is a single
- path from the root of the tree to any node in the hierarchy.
- If more than one path actually exists, they are considered to
- be different addresses.
-
- The root node is common to all addresses; consequently, it is
- not referenced. Its children constitute "top-level" name-
- domains. Usually, a service has access to its own full domain
- specification and to the names of all top-level name-domains.
-
- The "top" of the domain addressing hierarchy -- a child of the
- root -- is indicated by the right-most field, in a domain
- specification. Its child is specified to the left, its child
- to the left, and so on.
-
- Some groups provide formal registration services; these con-
- stitute name-domains that are independent logically of
- specific machines. In addition, networks and machines impli-
- citly compose name-domains, since their membership usually is
- registered in name tables.
-
- In the case of formal registration, an organization implements
- a (distributed) data base which provides an address-to-route
- mapping service for addresses of the form:
-
- address@hidden
-
- Note that "organization" is a logical entity, separate from
- any particular communication network.
-
- A mechanism for accessing "organization" is universally avail-
- able. That mechanism, in turn, seeks an instantiation of the
- registry; its location is not indicated in the address specif-
- ication. It is assumed that the system which operates under
- the name "organization" knows how to find a subordinate regis-
- try. The registry will then use the "person" string to deter-
- mine where to send the mail specification.
-
- The latter, network-oriented case permits simple, direct,
- attachment-related address specification, such as:
-
- address@hidden
-
- Once the network is accessed, it is expected that a message
- will go directly to the host and that the host will resolve
-
-
- August 13, 1982 - 28 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- the user name, placing the message in the user's mailbox.
-
- 6.2.2. ABBREVIATED DOMAIN SPECIFICATION
-
- Since any number of levels is possible within the domain
- hierarchy, specification of a fully qualified address can
- become inconvenient. This standard permits abbreviated domain
- specification, in a special case:
-
- For the address of the sender, call the left-most
- sub-domain Level N. In a header address, if all of
- the sub-domains above (i.e., to the right of) Level N
- are the same as those of the sender, then they do not
- have to appear in the specification. Otherwise, the
- address must be fully qualified.
-
- This feature is subject to approval by local sub-
- domains. Individual sub-domains may require their
- member systems, which originate mail, to provide full
- domain specification only. When permitted, abbrevia-
- tions may be present only while the message stays
- within the sub-domain of the sender.
-
- Use of this mechanism requires the sender's sub-domain
- to reserve the names of all top-level domains, so that
- full specifications can be distinguished from abbrevi-
- ated specifications.
-
- For example, if a sender's address is:
-
- address@hidden
-
- and one recipient's address is:
-
- address@hidden
-
- and another's is:
-
- address@hidden
-
- then ".registry-1.organization-X" need not be specified in the
- the message, but "registry-C.registry-2" DOES have to be
- specified. That is, the first two addresses may be abbrevi-
- ated, but the third address must be fully specified.
-
- When a message crosses a domain boundary, all addresses must
- be specified in the full format, ending with the top-level
- name-domain in the right-most field. It is the responsibility
- of mail forwarding services to ensure that addresses conform
-
-
- August 13, 1982 - 29 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- with this requirement. In the case of abbreviated addresses,
- the relaying service must make the necessary expansions. It
- should be noted that it often is difficult for such a service
- to locate all occurrences of address abbreviations. For exam-
- ple, it will not be possible to find such abbreviations within
- the body of the message. The "Return-Path" field can aid
- recipients in recovering from these errors.
-
- Note: When passing any portion of an addr-spec onto a process
- which does not interpret data according to this stan-
- dard (e.g., mail protocol servers). There must be NO
- LWSP-chars preceding or following the at-sign or any
- delimiting period ("."), such as shown in the above
- examples, and only ONE SPACE between contiguous
- <word>s.
-
- 6.2.3. DOMAIN TERMS
-
- A domain-ref must be THE official name of a registry, network,
- or host. It is a symbolic reference, within a name sub-
- domain. At times, it is necessary to bypass standard mechan-
- isms for resolving such references, using more primitive
- information, such as a network host address rather than its
- associated host name.
-
- To permit such references, this standard provides the domain-
- literal construct. Its contents must conform with the needs
- of the sub-domain in which it is interpreted.
-
- Domain-literals which refer to domains within the ARPA Inter-
- net specify 32-bit Internet addresses, in four 8-bit fields
- noted in decimal, as described in Request for Comments #820,
- "Assigned Numbers." For example:
-
- [10.0.3.19]
-
- Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It
- is permitted only as a means of bypassing temporary
- system limitations, such as name tables which are not
- complete.
-
- The names of "top-level" domains, and the names of domains
- under in the ARPA Internet, are registered with the Network
- Information Center, SRI International, Menlo Park, California.
-
- 6.2.4. DOMAIN-DEPENDENT LOCAL STRING
-
- The local-part of an addr-spec in a mailbox specification
- (i.e., the host's name for the mailbox) is understood to be
-
-
- August 13, 1982 - 30 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- whatever the receiving mail protocol server allows. For exam-
- ple, some systems do not understand mailbox references of the
- form "P. D. Q. Bach", but others do.
-
- This specification treats periods (".") as lexical separators.
- Hence, their presence in local-parts which are not quoted-
- strings, is detected. However, such occurrences carry NO
- semantics. That is, if a local-part has periods within it, an
- address parser will divide the local-part into several tokens,
- but the sequence of tokens will be treated as one uninter-
- preted unit. The sequence will be re-assembled, when the
- address is passed outside of the system such as to a mail pro-
- tocol service.
-
- For example, the address:
-
- address@hidden
-
- is legal and does not require the local-part to be surrounded
- with quotation-marks. (However, "First Last" DOES require
- quoting.) The local-part of the address, when passed outside
- of the mail system, within the Registry.Org domain, is
- "First.Last", again without quotation marks.
-
- 6.2.5. BALANCING LOCAL-PART AND DOMAIN
-
- In some cases, the boundary between local-part and domain can
- be flexible. The local-part may be a simple string, which is
- used for the final determination of the recipient's mailbox.
- All other levels of reference are, therefore, part of the
- domain.
-
- For some systems, in the case of abbreviated reference to the
- local and subordinate sub-domains, it may be possible to
- specify only one reference within the domain part and place
- the other, subordinate name-domain references within the
- local-part. This would appear as:
-
- address@hidden
-
- Such a specification would be acceptable to address parsers
- which conform to RFC #733, but do not support this newer
- Internet standard. While contrary to the intent of this stan-
- dard, the form is legal.
-
- Also, some sub-domains have a specification syntax which does
- not conform to this standard. For example:
-
- address@hidden
-
-
- August 13, 1982 - 31 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- uses a different parsing sequence for local-part than for
- domain.
-
- Note: As a rule, the domain specification should contain
- fields which are encoded according to the syntax of
- this standard and which contain generally-standardized
- information. The local-part specification should con-
- tain only that portion of the address which deviates
- from the form or intention of the domain field.
-
- 6.2.6. MULTIPLE MAILBOXES
-
- An individual may have several mailboxes and wish to receive
- mail at whatever mailbox is convenient for the sender to
- access. This standard does not provide a means of specifying
- "any member of" a list of mailboxes.
-
- A set of individuals may wish to receive mail as a single unit
- (i.e., a distribution list). The <group> construct permits
- specification of such a list. Recipient mailboxes are speci-
- fied within the bracketed part (":" - ";"). A copy of the
- transmitted message is to be sent to each mailbox listed.
- This standard does not permit recursive specification of
- groups within groups.
-
- While a list must be named, it is not required that the con-
- tents of the list be included. In this case, the <address>
- serves only as an indication of group distribution and would
- appear in the form:
-
- name:;
-
- Some mail services may provide a group-list distribution
- facility, accepting a single mailbox reference, expanding it
- to the full distribution list, and relaying the mail to the
- list's members. This standard provides no additional syntax
- for indicating such a service. Using the <group> address
- alternative, while listing one mailbox in it, can mean either
- that the mailbox reference will be expanded to a list or that
- there is a group with one member.
-
- 6.2.7. EXPLICIT PATH SPECIFICATION
-
- At times, a message originator may wish to indicate the
- transmission path that a message should follow. This is
- called source routing. The normal addressing scheme, used in
- an addr-spec, is carefully separated from such information;
- the <route> portion of a route-addr is provided for such occa-
- sions. It specifies the sequence of hosts and/or transmission
-
-
- August 13, 1982 - 32 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- services that are to be traversed. Both domain-refs and
- domain-literals may be used.
-
- Note: The use of source routing is discouraged. Unless the
- sender has special need of path restriction, the choice
- of transmission route should be left to the mail tran-
- sport service.
-
- 6.3. RESERVED ADDRESS
-
- It often is necessary to send mail to a site, without know-
- ing any of its valid addresses. For example, there may be mail
- system dysfunctions, or a user may wish to find out a person's
- correct address, at that site.
-
- This standard specifies a single, reserved mailbox address
- (local-part) which is to be valid at each site. Mail sent to
- that address is to be routed to a person responsible for the
- site's mail system or to a person with responsibility for general
- site operation. The name of the reserved local-part address is:
-
- Postmaster
-
- so that "address@hidden" is required to be valid.
-
- Note: This reserved local-part must be matched without sensi-
- tivity to alphabetic case, so that "POSTMASTER", "postmas-
- ter", and even "poStmASteR" is to be accepted.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- August 13, 1982 - 33 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- 7. BIBLIOGRAPHY
-
-
- ANSI. "USA Standard Code for Information Interchange," X3.4.
- American National Standards Institute: New York (1968). Also
- in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand-
- book", NIC 7104.
-
- ANSI. "Representations of Universal Time, Local Time Differen-
- tials, and United States Time Zone References for Information
- Interchange," X3.51-1975. American National Standards Insti-
- tute: New York (1975).
-
- Bemer, R.W., "Time and the Computer." In: Interface Age (Feb.
- 1979).
-
- Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Ruther-
- ford and Appleton Laboratory: Didcot, England.
-
- Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E.
- "Standardizing Network Mail Headers," ARPANET Request for
- Comments No. 561, Network Information Center No. 18516; SRI
- International: Menlo Park (September 1973).
-
- Birrell, A.D., Levin, R., Needham, R.M., and Schroeder, M.D.
- "Grapevine: An Exercise in Distributed Computing," Communica-
- tions of the ACM 25, 4 (April 1982), 260-274.
-
- Crocker, D.H., Vittal, J.J., Pogran, K.T., Henderson, D.A.
- "Standard for the Format of ARPA Network Text Message,"
- ARPANET Request for Comments No. 733, Network Information
- Center No. 41952. SRI International: Menlo Park (November
- 1977).
-
- Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook, Net-
- work Information Center No. 7104 (NTIS AD A003890). SRI
- International: Menlo Park (April 1976).
-
- Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass.
- (1969).
-
- Levin, R. and Schroeder, M. "Transport of Electronic Messages
- through a Network," TeleInformatics 79, pp. 29-33. North
- Holland (1979). Also as Xerox Palo Alto Research Center
- Technical Report CSL-79-4.
-
- Myer, T.H. and Henderson, D.A. "Message Transmission Protocol,"
- ARPANET Request for Comments, No. 680, Network Information
- Center No. 32116. SRI International: Menlo Park (1975).
-
-
- August 13, 1982 - 34 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- NBS. "Specification of Message Format for Computer Based Message
- Systems, Recommended Federal Information Processing Standard."
- National Bureau of Standards: Gaithersburg, Maryland
- (October 1981).
-
- NIC. Internet Protocol Transition Workbook. Network Information
- Center, SRI-International, Menlo Park, California (March
- 1982).
-
- Oppen, D.C. and Dalal, Y.K. "The Clearinghouse: A Decentralized
- Agent for Locating Named Objects in a Distributed Environ-
- ment," OPD-T8103. Xerox Office Products Division: Palo Alto,
- CA. (October 1981).
-
- Postel, J.B. "Assigned Numbers," ARPANET Request for Comments,
- No. 820. SRI International: Menlo Park (August 1982).
-
- Postel, J.B. "Simple Mail Transfer Protocol," ARPANET Request
- for Comments, No. 821. SRI International: Menlo Park (August
- 1982).
-
- Shoch, J.F. "Internetwork naming, addressing and routing," in
- Proc. 17th IEEE Computer Society International Conference, pp.
- 72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C.
-
- Su, Z. and Postel, J. "The Domain Naming Convention for Internet
- User Applications," ARPANET Request for Comments, No. 819.
- SRI International: Menlo Park (August 1982).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- August 13, 1982 - 35 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- APPENDIX
-
-
- A. EXAMPLES
-
- A.1. ADDRESSES
-
- A.1.1. Alfred Neuman <address@hidden>
-
- A.1.2. address@hidden
-
- These two "Alfred Neuman" examples have identical seman-
- tics, as far as the operation of the local host's mail sending
- (distribution) program (also sometimes called its "mailer")
- and the remote host's mail protocol server are concerned. In
- the first example, the "Alfred Neuman" is ignored by the
- mailer, as "address@hidden" completely specifies the reci-
- pient. The second example contains no superfluous informa-
- tion, and, again, "address@hidden" is the intended reci-
- pient.
-
- Note: When the message crosses name-domain boundaries, then
- these specifications must be changed, so as to indicate
- the remainder of the hierarchy, starting with the top
- level.
-
- A.1.3. "George, Ted" <address@hidden>
-
- This form might be used to indicate that a single mailbox
- is shared by several users. The quoted string is ignored by
- the originating host's mailer, because "address@hidden"
- completely specifies the destination mailbox.
-
- A.1.4. Wilt . (the Stilt) address@hidden
-
- The "(the Stilt)" is a comment, which is NOT included in
- the destination mailbox address handed to the originating
- system's mailer. The local-part of the address is the string
- "Wilt.Chamberlain", with NO space between the first and second
- words.
-
- A.1.5. Address Lists
-
- Gourmets: Pompous Person <address@hidden>,
- address@hidden, Galloping Gourmet@
- ANT.Down-Under (Australian National Television),
- address@hidden;,
- Cruisers: address@hidden, address@hidden;,
- address@hidden
-
-
- August 13, 1982 - 36 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- This group list example points out the use of comments and the
- mixing of addresses and groups.
-
- A.2. ORIGINATOR ITEMS
-
- A.2.1. Author-sent
-
- George Jones logs into his host as "Jones". He sends
- mail himself.
-
- From: address@hidden
-
- or
-
- From: George Jones <address@hidden>
-
- A.2.2. Secretary-sent
-
- George Jones logs in as Jones on his host. His secre-
- tary, who logs in as Secy sends mail for him. Replies to the
- mail should go to George.
-
- From: George Jones <address@hidden>
- Sender: address@hidden
-
- A.2.3. Secretary-sent, for user of shared directory
-
- George Jones' secretary sends mail for George. Replies
- should go to George.
-
- From: George Jones<address@hidden>
- Sender: address@hidden
-
- Note that there need not be a space between "Jones" and the
- "<", but adding a space enhances readability (as is the case
- in other examples.
-
- A.2.4. Committee activity, with one author
-
- George is a member of a committee. He wishes to have any
- replies to his message go to all committee members.
-
- From: George Jones <address@hidden>
- Sender: address@hidden
- Reply-To: The Committee: address@hidden,
- address@hidden,
- address@hidden;
-
- Note that if George had not included himself in the
-
-
- August 13, 1982 - 37 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- enumeration of The Committee, he would not have gotten an
- implicit reply; the presence of the "Reply-to" field SUPER-
- SEDES the sending of a reply to the person named in the "From"
- field.
-
- A.2.5. Secretary acting as full agent of author
-
- George Jones asks his secretary (address@hidden) to send a
- message for him in his capacity as Group. He wants his secre-
- tary to handle all replies.
-
- From: George Jones <address@hidden>
- Sender: address@hidden
- Reply-To: address@hidden
-
- A.2.6. Agent for user without online mailbox
-
- A friend of George's, Sarah, is visiting. George's
- secretary sends some mail to a friend of Sarah in computer-
- land. Replies should go to George, whose mailbox is Jones at
- Registry.
-
- From: Sarah Friendly <address@hidden>
- Sender: Secy-Name <address@hidden>
- Reply-To: address@hidden
-
- A.2.7. Agent for member of a committee
-
- George's secretary sends out a message which was authored
- jointly by all the members of a committee. Note that the name
- of the committee cannot be specified, since <group> names are
- not permitted in the From field.
-
- From: address@hidden,
- address@hidden,
- address@hidden
- Sender: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- August 13, 1982 - 38 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- A.3. COMPLETE HEADERS
-
- A.3.1. Minimum required
-
- Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT
- From: address@hidden or From: address@hidden
- Bcc: To: address@hidden
-
- Note that the "Bcc" field may be empty, while the "To" field
- is required to have at least one address.
-
- A.3.2. Using some of the additional fields
-
- Date: 26 Aug 76 1430 EDT
- From: George Jones<address@hidden>
- Sender: address@hidden
- To: "Al Neuman"@Mad-Host,
- address@hidden
- Message-ID: <address@hidden>
-
- A.3.3. About as complex as you're going to get
-
- Date : 27 Aug 76 0932 PDT
- From : Ken Davis <address@hidden>
- Subject : Re: The Syntax in the RFC
- Sender : address@hidden
- Reply-To : address@hidden
- To : George Jones <address@hidden>,
- address@hidden
- cc : Important folk:
- Tom Softwood <address@hidden>,
- "Sam Irving"@Other-Host;,
- Standard Distribution:
- /main/davis/people/address@hidden,
- "<Jones>standard.dist.3"@Tops-20-Host>;
- Comment : Sam is away on business. He asked me to handle
- his mail for him. He'll be able to provide a
- more accurate explanation when he returns
- next week.
- In-Reply-To: <address@hidden>, George's message
- X-Special-action: This is a sample of user-defined field-
- names. There could also be a field-name
- "Special-action", but its name might later be
- preempted
- Message-ID: <address@hidden>
-
-
-
-
-
-
- August 13, 1982 - 39 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- B. SIMPLE FIELD PARSING
-
- Some mail-reading software systems may wish to perform only
- minimal processing, ignoring the internal syntax of structured
- field-bodies and treating them the same as unstructured-field-
- bodies. Such software will need only to distinguish:
-
- o Header fields from the message body,
-
- o Beginnings of fields from lines which continue fields,
-
- o Field-names from field-contents.
-
- The abbreviated set of syntactic rules which follows will
- suffice for this purpose. It describes a limited view of mes-
- sages and is a subset of the syntactic rules provided in the main
- part of this specification. One small exception is that the con-
- tents of field-bodies consist only of text:
-
- B.1. SYNTAX
-
-
- message = *field *(CRLF *text)
-
- field = field-name ":" [field-body] CRLF
-
- field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
-
- field-body = *text [CRLF LWSP-char field-body]
-
-
- B.2. SEMANTICS
-
- Headers occur before the message body and are terminated by
- a null line (i.e., two contiguous CRLFs).
-
- A line which continues a header field begins with a SPACE or
- HTAB character, while a line beginning a field starts with a
- printable character which is not a colon.
-
- A field-name consists of one or more printable characters
- (excluding colon, space, and control-characters). A field-name
- MUST be contained on one line. Upper and lower case are not dis-
- tinguished when comparing field-names.
-
-
-
-
-
-
-
- August 13, 1982 - 40 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- C. DIFFERENCES FROM RFC #733
-
- The following summarizes the differences between this stan-
- dard and the one specified in Arpanet Request for Comments #733,
- "Standard for the Format of ARPA Network Text Messages". The
- differences are listed in the order of their occurrence in the
- current specification.
-
- C.1. FIELD DEFINITIONS
-
- C.1.1. FIELD NAMES
-
- These now must be a sequence of printable characters. They
- may not contain any LWSP-chars.
-
- C.2. LEXICAL TOKENS
-
- C.2.1. SPECIALS
-
- The characters period ("."), left-square bracket ("["), and
- right-square bracket ("]") have been added. For presentation
- purposes, and when passing a specification to a system that
- does not conform to this standard, periods are to be contigu-
- ous with their surrounding lexical tokens. No linear-white-
- space is permitted between them. The presence of one LWSP-
- char between other tokens is still directed.
-
- C.2.2. ATOM
-
- Atoms may not contain SPACE.
-
- C.2.3. SPECIAL TEXT
-
- ctext and qtext have had backslash ("\") added to the list of
- prohibited characters.
-
- C.2.4. DOMAINS
-
- The lexical tokens <domain-literal> and <dtext> have been
- added.
-
- C.3. MESSAGE SPECIFICATION
-
- C.3.1. TRACE
-
- The "Return-path:" and "Received:" fields have been specified.
-
-
-
-
-
- August 13, 1982 - 41 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- C.3.2. FROM
-
- The "From" field must contain machine-usable addresses (addr-
- spec). Multiple addresses may be specified, but named-lists
- (groups) may not.
-
- C.3.3. RESENT
-
- The meta-construct of prefacing field names with the string
- "Resent-" has been added, to indicate that a message has been
- forwarded by an intermediate recipient.
-
- C.3.4. DESTINATION
-
- A message must contain at least one destination address field.
- "To" and "CC" are required to contain at least one address.
-
- C.3.5. IN-REPLY-TO
-
- The field-body is no longer a comma-separated list, although a
- sequence is still permitted.
-
- C.3.6. REFERENCE
-
- The field-body is no longer a comma-separated list, although a
- sequence is still permitted.
-
- C.3.7. ENCRYPTED
-
- A field has been specified that permits senders to indicate
- that the body of a message has been encrypted.
-
- C.3.8. EXTENSION-FIELD
-
- Extension fields are prohibited from beginning with the char-
- acters "X-".
-
- C.4. DATE AND TIME SPECIFICATION
-
- C.4.1. SIMPLIFICATION
-
- Fewer optional forms are permitted and the list of three-
- letter time zones has been shortened.
-
- C.5. ADDRESS SPECIFICATION
-
-
-
-
-
-
- August 13, 1982 - 42 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- C.5.1. ADDRESS
-
- The use of quoted-string, and the ":"-atom-":" construct, have
- been removed. An address now is either a single mailbox
- reference or is a named list of addresses. The latter indi-
- cates a group distribution.
-
- C.5.2. GROUPS
-
- Group lists are now required to to have a name. Group lists
- may not be nested.
-
- C.5.3. MAILBOX
-
- A mailbox specification may indicate a person's name, as
- before. Such a named list no longer may specify multiple
- mailboxes and may not be nested.
-
- C.5.4. ROUTE ADDRESSING
-
- Addresses now are taken to be absolute, global specifications,
- independent of transmission paths. The <route> construct has
- been provided, to permit explicit specification of transmis-
- sion path. RFC #733's use of multiple at-signs ("@") was
- intended as a general syntax for indicating routing and/or
- hierarchical addressing. The current standard separates these
- specifications and only one at-sign is permitted.
-
- C.5.5. AT-SIGN
-
- The string " at " no longer is used as an address delimiter.
- Only at-sign ("@") serves the function.
-
- C.5.6. DOMAINS
-
- Hierarchical, logical name-domains have been added.
-
- C.6. RESERVED ADDRESS
-
- The local-part "Postmaster" has been reserved, so that users can
- be guaranteed at least one valid address at a site.
-
-
-
-
-
-
-
-
-
-
- August 13, 1982 - 43 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- D. ALPHABETICAL LISTING OF SYNTAX RULES
-
- address = mailbox ; one addressee
- / group ; named list
- addr-spec = local-part "@" domain ; global address
- ALPHA = <any ASCII alphabetic character>
- ; (101-132, 65.- 90.)
- ; (141-172, 97.-122.)
- atom = 1*<any CHAR except specials, SPACE and CTLs>
- authentic = "From" ":" mailbox ; Single author
- / ( "Sender" ":" mailbox ; Actual submittor
- "From" ":" 1#mailbox) ; Multiple authors
- ; or not sender
- CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
- comment = "(" *(ctext / quoted-pair / comment) ")"
- CR = <ASCII CR, carriage return> ; ( 15, 13.)
- CRLF = CR LF
- ctext = <any CHAR excluding "(", ; => may be folded
- ")", "\" & CR, & including
- linear-white-space>
- CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
- character and DEL> ; ( 177, 127.)
- date = 1*2DIGIT month 2DIGIT ; day month year
- ; e.g. 20 Jun 82
- dates = orig-date ; Original
- [ resent-date ] ; Forwarded
- date-time = [ day "," ] date time ; dd mm yy
- ; hh:mm:ss zzz
- day = "Mon" / "Tue" / "Wed" / "Thu"
- / "Fri" / "Sat" / "Sun"
- delimiters = specials / linear-white-space / comment
- destination = "To" ":" 1#address ; Primary
- / "Resent-To" ":" 1#address
- / "cc" ":" 1#address ; Secondary
- / "Resent-cc" ":" 1#address
- / "bcc" ":" #address ; Blind carbon
- / "Resent-bcc" ":" #address
- DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.)
- domain = sub-domain *("." sub-domain)
- domain-literal = "[" *(dtext / quoted-pair) "]"
- domain-ref = atom ; symbolic reference
- dtext = <any CHAR excluding "[", ; => may be folded
- "]", "\" & CR, & including
- linear-white-space>
- extension-field =
- <Any field which is defined in a document
- published as a formal extension to this
- specification; none will have names beginning
- with the string "X-">
-
-
- August 13, 1982 - 44 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- field = field-name ":" [ field-body ] CRLF
- fields = dates ; Creation time,
- source ; author id & one
- 1*destination ; address required
- *optional-field ; others optional
- field-body = field-body-contents
- [CRLF LWSP-char field-body]
- field-body-contents =
- <the ASCII characters making up the field-body, as
- defined in the following sections, and consisting
- of combinations of atom, quoted-string, and
- specials tokens, or else consisting of texts>
- field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
- group = phrase ":" [#mailbox] ";"
- hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
- ; 00:00:00 - 23:59:59
- HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
- LF = <ASCII LF, linefeed> ; ( 12, 10.)
- linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE
- ; CRLF => folding
- local-part = word *("." word) ; uninterpreted
- ; case-preserved
- LWSP-char = SPACE / HTAB ; semantics = SPACE
- mailbox = addr-spec ; simple address
- / phrase route-addr ; name & addr-spec
- message = fields *( CRLF *text ) ; Everything after
- ; first null line
- ; is message body
- month = "Jan" / "Feb" / "Mar" / "Apr"
- / "May" / "Jun" / "Jul" / "Aug"
- / "Sep" / "Oct" / "Nov" / "Dec"
- msg-id = "<" addr-spec ">" ; Unique message id
- optional-field =
- / "Message-ID" ":" msg-id
- / "Resent-Message-ID" ":" msg-id
- / "In-Reply-To" ":" *(phrase / msg-id)
- / "References" ":" *(phrase / msg-id)
- / "Keywords" ":" #phrase
- / "Subject" ":" *text
- / "Comments" ":" *text
- / "Encrypted" ":" 1#2word
- / extension-field ; To be defined
- / user-defined-field ; May be pre-empted
- orig-date = "Date" ":" date-time
- originator = authentic ; authenticated addr
- [ "Reply-To" ":" 1#address] )
- phrase = 1*word ; Sequence of words
-
-
-
-
- August 13, 1982 - 45 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- qtext = <any CHAR excepting <">, ; => may be folded
- "\" & CR, and including
- linear-white-space>
- quoted-pair = "\" CHAR ; may quote any char
- quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
- ; quoted chars.
- received = "Received" ":" ; one per relay
- ["from" domain] ; sending host
- ["by" domain] ; receiving host
- ["via" atom] ; physical path
- *("with" atom) ; link/mail protocol
- ["id" msg-id] ; receiver msg id
- ["for" addr-spec] ; initial form
- ";" date-time ; time received
-
- resent = resent-authentic
- [ "Resent-Reply-To" ":" 1#address] )
- resent-authentic =
- = "Resent-From" ":" mailbox
- / ( "Resent-Sender" ":" mailbox
- "Resent-From" ":" 1#mailbox )
- resent-date = "Resent-Date" ":" date-time
- return = "Return-path" ":" route-addr ; return address
- route = 1#("@" domain) ":" ; path-relative
- route-addr = "<" [route] addr-spec ">"
- source = [ trace ] ; net traversals
- originator ; original mail
- [ resent ] ; forwarded
- SPACE = <ASCII SP, space> ; ( 40, 32.)
- specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
- / "," / ";" / ":" / "\" / <"> ; string, to use
- / "." / "[" / "]" ; within a word.
- sub-domain = domain-ref / domain-literal
- text = <any CHAR, including bare ; => atoms, specials,
- CR & bare LF, but NOT ; comments and
- including CRLF> ; quoted-strings are
- ; NOT recognized.
- time = hour zone ; ANSI and Military
- trace = return ; path to sender
- 1*received ; receipt tags
- user-defined-field =
- <Any field which has not been defined
- in this specification or published as an
- extension to this specification; names for
- such fields must be unique and may be
- pre-empted by published extensions>
- word = atom / quoted-string
-
-
-
-
- August 13, 1982 - 46 - RFC #822
-
-
-
- Standard for ARPA Internet Text Messages
-
-
- zone = "UT" / "GMT" ; Universal Time
- ; North American : UT
- / "EST" / "EDT" ; Eastern: - 5/ - 4
- / "CST" / "CDT" ; Central: - 6/ - 5
- / "MST" / "MDT" ; Mountain: - 7/ - 6
- / "PST" / "PDT" ; Pacific: - 8/ - 7
- / 1ALPHA ; Military: Z = UT;
- <"> = <ASCII quote mark> ; ( 42, 34.)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- August 13, 1982 - 47 - RFC #822
-
diff --git a/doc/rfc/rfc934.txt b/doc/rfc/rfc934.txt
deleted file mode 100644
index 0f9a9e8..0000000
--- a/doc/rfc/rfc934.txt
+++ /dev/null
@@ -1,571 +0,0 @@
-
-
-Network Working Group Marshall T. Rose (Delaware)
-Request for Comments: 934 Einar A. Stefferud (NMA)
- January 1985
-
- Proposed Standard for Message Encapsulation
-
-
-STATUS OF THIS MEMO
-
- This RFC suggests a proposed protocol for the ARPA-Internet
- community, and requests discussion and suggestions for improvements.
- Distribution of this memo is unlimited.
-
-Introduction, Scope, and Motivation
-
- The services that a user agent (UA) can offer are varied. Although
- all outgoing mail may be thought of as going through a single posting
- slot to connect to the message transport system (MTS), it is possible
- to consider a message draft being posted as described by one of the
- following four types of postings:
-
- Originate - a new message is composed from scratch, which, to the
- knowledge of the UA, is unrelated to any message previously
- handled by the user.
-
- Reply - a message is composed as a reply to a message previously
- received by the user. In most circumstances, the UA aids the user
- in composing the reply by constructing the header portion of the
- message draft, using components extracted from the received
- message headers.
-
- Forward - one more more messages previously received by the user
- are formatted by the UA as a part of the body portion of the
- draft. In this sense, a "digest" for an interest group may be
- considered as forwarding. Similarly, an argument may be made that
- "blind-carbon-copies" should also be handled in this fashion.
-
- Distribute - a message previously received by the user is
- re-posted to the MTS. The draft being re-posted is identical to
- the original message with the exception that certain "ReSent-XXX"
- headers are appended to the headers portion of the draft, and the
- "Return-Path" header is reset to reference the re-sender's
- address. (See [RFC-821] for a discussion of the Return-Path
- header.)
-
- Most user agents support the first two of these activities, many
- support the first three, and a few support all four.
-
- This memo concerns itself only with the third type, which is message
- forwarding. (For a brief treatment of the semantics of message
- components with respect to replies, see [RFC-822].) In many ways,
-
-
-Rose & Stefferud [Page 1]
-
-
-
-RFC 934 January 1985
-Message Encapsulation
-
-
- forwarding can be thought of as encapsulating one or more messages
- inside another. Although this is useful for transfer of past
- correspondence to new recipients, without a decapsulation process
- (which this memo terms "bursting"), the forwarded messages are of
- little use to the recipients because they can not be distributed,
- forwarded, replied-to, or otherwise processed as separate individual
- messages.
-
- NOTE: RFC-822 mistakenly refers to distribution as forwarding
- (section 4.2). This memo suggests below, that these two
- activities can and should be the same.
-
- In the case of an interest group digest, a bursting capability is
- especially useful. Not only does the ability to burst a digest
- permit a recipient of the digest to reply to an individual digested
- message, but it also allows the recipient to selectively process the
- other messages encapsulated in the digest. For example, a single
- digest issue usually contains more than one topic. A subscriber may
- only be interested in a subset of the topics discussed in a
- particular issue. With a bursting capability, the subscriber can
- burst the digest, scan the headers, and process those messages which
- are of interest. The others can be ignored, if the user so desires.
-
- This memo is motivated by three concerns:
-
- In order to burst a message it is necessary to know how the
- component messages were encapsulated in the draft. At present
- there is no unambiguous standard for interest group digests. This
- memo proposes such a standard for the ARPA-Internet. Although
- interest group digests may appear to conform to a pseudo-standard,
- there is a serious ambiguity in the implementations which produce
- digests. By proposing this standard, the authors hope to solve
- this problem by specifically addressing the implementation
- ambiguity.
-
- Next, there is much confusion as to how "blind-carbon-copies"
- should be handled by UAs. It appears that each agent in the
- ARPA-Internet which supports a "bcc:" facility does so
- differently. Although this memo does not propose a standard for
- the generation of blind-carbon-copies, it introduces a formalism
- which views the "bcc:" facility as a special case of the
- forwarding activity.
-
- Finally, both forwarding and distribution can be accomplished with
- the same forwarding procedure, if a distributed message can be
- extracted as a separate individually processable message. With a
- proper bursting agent, it will be difficult to distinguish between
-
-
-Rose & Stefferud [Page 2]
-
-
-
-RFC 934 January 1985
-Message Encapsulation
-
-
- a message which has been distributed and a message which has been
- extracted from a forwarded message. This memo argues that there is
- no valuable distinction to be made, between forwarding and
- distribution, and that in the interests of simplicity,
- distribution facilities should not be generally available to the
- ordinary users of a message system. However, this memo also
- argues that such facilities should be available to certain trusted
- entities within the MTS.
-
- NOTE: this memo does not propose that the distribution facility
- be abolished. Rather it argues the case forcefully in the hope
- that other interested parties in the ARPA-Internet will join
- this discussion.
-
-Message Encapsulation
-
- This memo proposes the following encapsulation protocol: two agents
- act on behalf of the user, a forwarding agent, which composes the
- message draft prior to posting, and a bursting agent which decomposes
- the message after delivery.
-
- Definitions: a draft forwarding message consists of a header portion
- and a text portion. If the text portion is present, it is separated
- from the header portion by a blank line. Inside the text portion a
- certain character string sequence, known as an "encapsulation
- boundary", has special meaning. Currently (in existing
- digestification agents), an encapsulation boundary (EB) is defined as
- a line in the message which starts with a dash (decimal code 45,
- "-"). Initially, no restriction is placed on the length of the
- encapsulation boundary, or on the characters that follow the dash.
-
- 1. The Header Portion
-
- This memo makes no restriction on the header portion of the draft,
- although it should conform to the RFC-822 standard.
-
- 2. The Text Portion
-
- The text of the draft forwarding message consists of three parts: an
- initial text section, the encapsulated messages, and the final text
- section.
-
- 2.1. The Initial Text Section
-
- All text (if any) up to the first EB comprises the initial text
- section of the draft. This memo makes no restrictions on the
-
-
-
-Rose & Stefferud [Page 3]
-
-
-
-RFC 934 January 1985
-Message Encapsulation
-
-
- format of the initial text section of the draft. In the case of a
- digest, this initial text is usually the "table of contents" of
- the digest.
-
- 2.2. The Final Text Section
-
- All text (if any) after the last EB composes the final text
- section of the draft. This memo makes no restrictions on the
- format of the final text section of the draft. In the case of a
- digest, this final text usually contains the sign-off banner for
- the digest (e.g., "End of FOO Digest").
-
- 2.3. Encapsulated Messages
-
- Each encapsulated message is bounded by two EBs: a pre-EB, which
- occurs before the message; and, a post-EB, which occurs after the
- message. For two adjacent encapsulated messages, the post-EB of
- the first message is also the pre-EB of the second message.
- Consistent with this, two adjacent EBs with nothing between them
- should be treated as enclosing a null message, and thus two or
- more adjacent EBs are equivalent to one EB.
-
- Each encapsulated message consists of two parts: a headers portion
- and a text portion. If the text portion is present, it is
- separated from the header portion by a blank line.
-
- 2.3.1. The Header Portion
-
- Minimally, there must be two header items in each message being
- forwarded, a "Date:" field and a "From:" field. This differs
- from RFC-822, which requires at least one destination address
- (in a "To:" or "cc:" field) or a possibly empty "Bcc:" field.
- Any addresses occuring in the header items for a message being
- forwarded must be fully qualified.
-
- 2.3.2. The Text Portion
-
- This memo makes no restrictions on the format of the text
- portion of each encapsulated message. (Actually, this memo
- does restrict the format of the text portion of each
- encapsulated message, but these restrictions are discussed
- later.)
-
- Before summarizing the generation/parsing rules for message
- encapsulation, two issues are addressed.
-
-
-
-
-Rose & Stefferud [Page 4]
-
-
-
-RFC 934 January 1985
-Message Encapsulation
-
-
-Compatibility with Existing User Agents
-
- The above encapsulation protocol is presently used by many user
- agents in the ARPA-Internet, and was specifically designed to
- minimize the amount of changes to existing implementations of
- forwarding agents in the ARPA-Internet.
-
- However, the protocol is not exactly like the pseudo-standard used by
- those forwarding agents that compose digests. In particular, the
- post-EB of all messages encapsulated in a digest is preceeded and
- followed by by a blank line. In addition, the first message
- encapsulated in a digest has a pre-EB that is followed by a blank
- line, but usually isn't preceeded by a blank line (wonderful).
-
- This memo recommends that implementors of forwarding agents wishing
- to remain compatible with existing bursting agents consider
- surrounding each EB with a blank line. It should be noted that blank
- lines following a pre-EB for an encapsulated message must be ignored
- by bursting agents. Further, this memo suggests that blank lines
- preceeding a post-EB also be ignored by bursting agents.
-
- NOTE: This recommendation is made in the interest of
- backwards-compatibility. A forwarding agent wishing to strictly
- adhere to this memo, should not generate blank lines surrounding
- EBs.
-
-Character-Stuffing the Encapsulation Boundary
-
- It should be noted that the protocol is general enough to support
- both general forwarding of messages and the specific case of digests.
- Unfortunately, there is one issue of message encapsulation which
- apparently is not addressed by any forwarding agent (to the authors'
- knowledge) in the ARPA-Internet: what action does the forwarding
- agent take when the encapsulation boundary occurs within a the text
- portion of a message being forwarded? Without exception, this
- circumstance is ignored by existing forwarding agents.
-
- To address this issue, this memo proposes the following
- character-stuffing scheme: the encapsulation boundary is defined as a
- line which starts with a dash. A special case is made for those
- boundaries which start with a dash and are followed by a space
- (decimal code 32, " ").
-
- During forwarding, if the forwarding agent detects a line in the
- text portion of a message being forwarded which starts with the
- encapsulation boundary, the forwarding agent outputs a dash
- followed by a space prior to outputting the line.
-
-
-Rose & Stefferud [Page 5]
-
-
-
-RFC 934 January 1985
-Message Encapsulation
-
-
- During bursting, if the bursting agent detects an encapsulation
- boundary which starts with a dash followed by a space, then the
- bursting agent does not treat the line as an encapsulation
- boundary, and outputs the remainder of the line instead.
-
- This simple character-stuffing scheme permits recursive forwardings.
-
-Generation/Parsing Rules for Message Encapsulation
-
- The rules for forwarding/bursting are described in terms of regular
- expressions. The first author originally derived simple finite-state
- automata for the rules, but was unable to legibly represent them in
- this memo. It is suggested that the implementors sketch the automata
- to understand the grammar.
-
- The conventions used for the grammar are simple. Each state is
- followed by one or more alternatives, which are separated by the "|"
- character. Each alternative starts with a character that is received
- as input. (CRLF, although two characters is treated as one character
- herein.) The last alternative for a state is the character "c",
- which represents any character not specified in the preceeding
- alternatives. Optionally following the input character is an output
- string enclosed by curly-braces. Following this is the state that
- the automata enters. The reader should note that these grammars are
- extremely simple to implement (and, in most cases, can be implemented
- quite efficiently).
-
- When the forwarding agent encapsulates a message, it should apply the
- following finite-state automaton. The initial state is S1.
-
- S1 :: CRLF {CRLF} S1
- | "-" {"- -"} S2
- | c {c} S2
-
- S2 :: CRLF {CRLF} S1
- | c {c} S2
-
- This simply says that anytime a "-" is found at the beginning of a
- line, a "- " is output prior to outputting the line.
-
-
-
-
-
-
-
-
-
-
-Rose & Stefferud [Page 6]
-
-
-
-RFC 934 January 1985
-Message Encapsulation
-
-
- When the bursting agent decapsulates the text portion of a draft, it
- should apply the following finite-state automaton. The initial state
- is S1.
-
- S1 :: "-" S3
- | CRLF {CRLF} S1
- | c {c} S2
-
- S2 :: CRLF {CRLF} S1
- | c {c} S2
-
- S3 :: " " S2
- | c S4
-
- S4 :: CRLF S5
- | c S4
-
- S5 :: CRLF S5
- | c {c} S2
-
- Although more complicated than the grammar used by the forwarding
- agent to encapsulate a single message, this grammer is still quite
- simple. Let us make the simplifying assumption that both the initial
- and final text sections of the draft are messages in addition to the
- encapsulated messages.
-
- To begin, the current message being burst is scanned at state S1. All
- characters are output until the EB is found (state S3). If "- " is
- found, the automaton enters state S2 and characters from the current
- message are continued to be output. Finally, a true EB is found
- (state S4). As the automaton traverses from state S3 to S4, the
- bursting agent should consider the current message ended. The
- remainder of the EB is discarded (states S4 and S5). As the
- automaton traverses from state S5 to S2, the bursting agent should
- consider a new message started and output the first character. In
- state S2, all characters are output until the EB is found.
-
-Blind Carbon Copies
-
- Many user agents support a blind-carbon-copy facility. With this
- facility a draft has two types of addressees: visible and blind
- recipients. The visible recipients are listed as addresses in the
- "To:" and "cc:" fields of the draft, and the blind recipients are
- listed as addresses in the "Bcc:" fields of the draft. The basis of
- this facility is that copies of the draft which are delivered to the
- recipients list the visible recipients only.
-
-
-
-Rose & Stefferud [Page 7]
-
-
-
-RFC 934 January 1985
-Message Encapsulation
-
-
- One method of achieving this is to post a single draft, which lacks
- any "Bcc:" fields, and, during posting, to interact with the MTS in
- such a way that copies are sent to both the visible and blind
- recipients.
-
- Unfortunately, a key problem with this arrangement is that the blind
- recipients can accidently reply to the draft in such a way that the
- visible recipients are included as addressees in the reply. This is
- socially unacceptable! To avoid this problem, the message which the
- visible recipients receive must be different than the message which
- the blind recipients receive.
-
- A second method is to post two drafts. The first, which goes to the
- visible recipients, is simply the draft without any "Bcc:" fields.
- The second, which goes to the blind recipients, is simply the draft
- with some string prepended to any "To:" and "cc:" field. For example,
- the user agent might prepend "BCC-" to these fields, so that the
- blind recipients get a draft with "BCC-To:" and "Bcc-cc:" fields and
- no "To:" or "cc:" fields. Unfortunately, this is often very confusing
- to the blind recipients. Although accidental replies are not
- possible, it is often difficult to tell that the draft received is
- the result of a blind-carbon-copy.
-
- The method which this memo suggests is to post two drafts, a visible
- draft for the visible recipients, and a blind draft for the blind
- recipients. The visible draft consists of the original draft without
- any "Bcc:" fields. The blind draft contains the visible message as a
- forwarded message. The headers for the blind draft contain the
- minimal RFC-822 headers and, if the original draft had a "Subject:"
- field, then this header field is also included. In addition, the
- user agent might explicitly show that the blind draft is the result
- of a blind-carbon-copy, with a "Bcc" header or prior to the first
- encapsulating boundary in the body.
-
-Message Distribution
-
- The main purpose of message distribution (often called redistribution
- or resending) is to provide to a secondary recipient, perhaps not
- included among the original addressees, with a "true original" copy
- that can be treated like an original in every respect.
-
- Such distribution is most often done by discussion group moderators
- who use automated agents to simply repost received messages to a
- distribution list. The better automatic distribution agents insert a
- new "Return-Path" header field to direct address failure notices to
- the discussion group address list maintainer, rather than to the
- original author. This form of distribution is encouraged because it
-
-
-Rose & Stefferud [Page 8]
-
-
-
-RFC 934 January 1985
-Message Encapsulation
-
-
- most simply serves to deliver messages to discussion group recipients
- as processable originals. It is performed by trusted pseudo-MTS
- agents.
-
- A second kind of distribution is that done by individuals who wish to
- transfer a processable copy of a received message to another
- recipient. This second form is discouraged in various new standards
- for message transfer. These include the NBS Standard for Mail
- Interchange [FIPS-98], and the recent CCITT draft MHS (Mail Handling
- Systems) X.400 standards [X.400]. In place of direct reposting of
- received messages as though they are new drafts, the recommendation
- is to forward the received message in the body of a new draft from
- which is can be extracted by its secondary recipient for further
- processing.
-
- It is in support of this recommendation that this standard for
- encapsulation/decapsulation is proposed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose & Stefferud [Page 9]
-
-
-
-RFC 934 January 1985
-Message Encapsulation
-
-
-References
-
- [RFC-822] D.H. Crocker. "Standard for the Format of ARPA-Internet
- Text Messages", University of Delaware. (August, 1982)
-
- [RFC-821] J.B. Postel. "Simple Mail Transfer Protocol",
- USC/Information Sciences Institute. (August, 1982).
-
- [FIPS-98] National Bureau of Standards. "Specification for
- Message Format for Computer Based Message Systems."
- (January, 1983).
-
- [X.400] Consultative Committee on International Telephone and
- Telegraph. "DRAFT Recommendation X.400. Message
- Handling Systems: System Model-Service Elements."
-
-Authors' Addresses
-
- Marshall T. Rose
-
- Department of Computer and Information Sciences
- University of Delaware
- Newark, DE 19716
-
- address@hidden
-
- Einar A. Stefferud
-
- Network Management Associates, Inc.
- 17301 Drey Lane
- Huntington Beach, CA 92647
-
- address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose & Stefferud [Page 10]
-
-
diff --git a/doc/rfc/sasl-mechanisms b/doc/rfc/sasl-mechanisms
deleted file mode 100644
index 2784385..0000000
--- a/doc/rfc/sasl-mechanisms
+++ /dev/null
@@ -1,114 +0,0 @@
-
-SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS
-----------------------------------------------------------
-
-(last updated 2001 Jul 24)
-
-The Simple Authentication and Security Layer (SASL) [RFC2222] is a
-method for adding authentication support to connection-based
-protocols. To use this specification, a protocol includes a command
-for identifying and authenticating a user to a server and for
-optionally negotiating a security layer for subsequent protocol
-interactions. The command has a required argument identifying a SASL
-mechanism.
-
-SASL mechanisms are named by strings, from 1 to 20 characters in
-length, consisting of upper-case letters, digits, hyphens, and/or
-underscores. SASL mechanism names must be registered with the IANA.
-Procedures for registering new SASL mechanisms are given in the
-section "Registration procedures" of RFC2222.
-
-
-MECHANISMS OWNER REFERENCE
----------- ----- ---------
-
-KERBEROS_V4 IESG <address@hidden> [RFC2222]
-
-GSSAPI IESG <address@hidden> [RFC2222]
-
-SKEY (OBSOLETE) IESG <address@hidden>
[RFC2444]
-
-EXTERNAL IESG <address@hidden> [RFC2222]
-
-CRAM-MD5 IESG <address@hidden> [RFC2195]
-
-ANONYMOUS IESG <address@hidden> [RFC2245]
-
-OTP IESG <address@hidden> [RFC2444]
-
-GSS-SPNEGO Paul Leach <address@hidden> [Leach]
-
-PLAIN IESG <address@hidden> [RFC2595]
-
-SECURID Magnus Nystrom <address@hidden>[RFC2808]
-
-NTLM Paul Leach <address@hidden> [Leach]
-
-NMAS_LOGIN Mark G. Gayman <address@hidden> [Gayman]
-
-NMAS_AUTHEN Mark G. Gayman <address@hidden> [Gayman]
-
-DIGEST-MD5 IESG <address@hidden> [RFC2831]
-
-9798-U-RSA-SHA1-ENC address@hidden [RFCZUCC]
-
-9798-M-RSA-SHA1-ENC address@hidden [RFCZUCC]
-
-9798-U-DSA-SHA1 address@hidden [RFCZUCC]
-
-9798-M-DSA-SHA1 address@hidden [RFCZUCC]
-
-9798-U-ECDSA-SHA1 address@hidden [RFCZUCC]
-
-9798-M-ECDSA-SHA1 address@hidden [RFCZUCC]
-
-
-
-References
-----------
-
-[RFC2222] Myers, J., "Simple Authentication and Security Layer
- (SASL)", RFC 2222, Netscape Communications, October 1997.
-
-[RFC2195] Klensin, J., Catoe, R., Krumviede, P. "IMAP/POP AUTHorize
- Extension for Simple Challenge/Response", RFC 2195, MCI,
- September 1997.
-
-[RFC2245] Newman, C., "Anonymous SASL Mechanism", RFC 2245, Innosoft,
- November 1997.
-
-[RFC2444] Newman, C., "The One-Time-Password SASL Mechanism", RFC
- 2444, October 1998.
-
-[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
- Innosoft, June 1999.
-
-[RFC2808] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 2808,
- April 2000.
-
-[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a
- SASL Mechanism", RFC 2831, May 2000.
-
-
-[RFCZUCC] R. Zuccherato and M. Nystrom, "ISO/IEC 9798-3 Authentication
- SASL Mechanism", RFC XXXX, Month 2001.
-
-
-
-People
-------
-
-[Gayman] Mark G. Gayman, <address@hidden>, September 2000.
-
-[Leach] Paul Leach, <address@hidden>, December 1998, June 2000.
-
-[]
-
-
-
-
-
-
-
-
-
diff --git a/doc/texinfo/COPYING.DOC b/doc/texinfo/COPYING.DOC
index 5d8b248..22d7ef1 100644
--- a/doc/texinfo/COPYING.DOC
+++ b/doc/texinfo/COPYING.DOC
@@ -2,7 +2,7 @@
Version 1.2, November 2002
- Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
+ Copyright (C) 2000, 2001, 2002, 2010 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
diff --git a/doc/texinfo/Makefile.am b/doc/texinfo/Makefile.am
index 2695b98..6a13b0a 100644
--- a/doc/texinfo/Makefile.am
+++ b/doc/texinfo/Makefile.am
@@ -1,7 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2001, 2002, 2003, 2004, 2006,
-## 2007, 2009 Free Software Foundation, Inc.
+## Copyright (C) 2001, 2002, 2003, 2004, 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/doc/texinfo/address.texi b/doc/texinfo/address.texi
index 972a8fa..d7553f4 100644
--- a/doc/texinfo/address.texi
+++ b/doc/texinfo/address.texi
@@ -1,5 +1,5 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,2007
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
@c Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/attribute.texi b/doc/texinfo/attribute.texi
index 30a4e44..db790ac 100644
--- a/doc/texinfo/attribute.texi
+++ b/doc/texinfo/attribute.texi
@@ -1,5 +1,5 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,2007
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
@c Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/auth.texi b/doc/texinfo/auth.texi
index bd9262d..506582a 100644
--- a/doc/texinfo/auth.texi
+++ b/doc/texinfo/auth.texi
@@ -1,5 +1,5 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,2007
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
@c Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/body.texi b/doc/texinfo/body.texi
index 878596f..d594a01 100644
--- a/doc/texinfo/body.texi
+++ b/doc/texinfo/body.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,
address@hidden 2006,2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
address@hidden Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/c-api.texi b/doc/texinfo/c-api.texi
index 546738d..da36a4c 100644
--- a/doc/texinfo/c-api.texi
+++ b/doc/texinfo/c-api.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,
address@hidden 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2007, 2010 Free
address@hidden Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/encoding.texi b/doc/texinfo/encoding.texi
index 287b0d7..446a07f 100644
--- a/doc/texinfo/encoding.texi
+++ b/doc/texinfo/encoding.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,
address@hidden 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2007, 2010 Free
address@hidden Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/envelope.texi b/doc/texinfo/envelope.texi
index cfd4f2f..e416143 100644
--- a/doc/texinfo/envelope.texi
+++ b/doc/texinfo/envelope.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,
address@hidden 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
address@hidden Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/fdl.texi b/doc/texinfo/fdl.texi
index 0d42e8b..94c2db2 100644
--- a/doc/texinfo/fdl.texi
+++ b/doc/texinfo/fdl.texi
@@ -5,7 +5,8 @@
@center Version 1.2, November 2002
@display
-Copyright @copyright{} 2000,2001,2002 Free Software Foundation, Inc.
+Copyright @copyright{} 2000, 2001, 2002, 2010 Free Software Foundation,
+Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
Everyone is permitted to copy and distribute verbatim copies
diff --git a/doc/texinfo/folder.texi b/doc/texinfo/folder.texi
index 4ede739..0c2d537 100644
--- a/doc/texinfo/folder.texi
+++ b/doc/texinfo/folder.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,
address@hidden 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
address@hidden Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/framework.texi b/doc/texinfo/framework.texi
index 27a46d5..64bc9ae 100644
--- a/doc/texinfo/framework.texi
+++ b/doc/texinfo/framework.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,
address@hidden 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
address@hidden Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/gendocs_template b/doc/texinfo/gendocs_template
index d52a99e..c2e83c9 100755
--- a/doc/texinfo/gendocs_template
+++ b/doc/texinfo/gendocs_template
@@ -91,7 +91,7 @@ Please send broken links and other corrections (or
suggestions) to
</p>
<p>
-Copyright (C) 2005 Free Software Foundation, Inc.,
+Copyright (C) 2005, 2010 Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02111, USA
<br />
Verbatim copying and distribution of this entire article is
diff --git a/doc/texinfo/getdate.texi b/doc/texinfo/getdate.texi
index 8b46080..7fb7328 100644
--- a/doc/texinfo/getdate.texi
+++ b/doc/texinfo/getdate.texi
@@ -1,7 +1,7 @@
@c GNU date syntax documentation
@c Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
address@hidden 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
address@hidden 2003, 2004, 2005, 2006, 2010 Free Software Foundation, Inc.
@c Permission is granted to copy, distribute and/or modify this document
@c under the terms of the GNU Free Documentation License, Version 1.2 or
diff --git a/doc/texinfo/headers.texi b/doc/texinfo/headers.texi
index 953adbf..c51c551 100644
--- a/doc/texinfo/headers.texi
+++ b/doc/texinfo/headers.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,
address@hidden 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
address@hidden Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/imap4.texi b/doc/texinfo/imap4.texi
index 9929168..34722b0 100644
--- a/doc/texinfo/imap4.texi
+++ b/doc/texinfo/imap4.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,
address@hidden 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
address@hidden Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/iterator.texi b/doc/texinfo/iterator.texi
index 7e60e18..f1cd728 100644
--- a/doc/texinfo/iterator.texi
+++ b/doc/texinfo/iterator.texi
@@ -1,5 +1,5 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,2007
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
@c Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/libmu_auth.texi b/doc/texinfo/libmu_auth.texi
index 5d80ab3..802825b 100644
--- a/doc/texinfo/libmu_auth.texi
+++ b/doc/texinfo/libmu_auth.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,
address@hidden 2007,2009 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2007, 2009,
2010
address@hidden Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/libmu_scm.texi b/doc/texinfo/libmu_scm.texi
index 15d0014..f20408a 100644
--- a/doc/texinfo/libmu_scm.texi
+++ b/doc/texinfo/libmu_scm.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,
address@hidden 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
address@hidden Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/libmu_sieve.texi b/doc/texinfo/libmu_sieve.texi
index 4c5136d..094f7c9 100644
--- a/doc/texinfo/libmu_sieve.texi
+++ b/doc/texinfo/libmu_sieve.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,
address@hidden 2007,2009 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2009,
address@hidden 2010 Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/locker.texi b/doc/texinfo/locker.texi
index 38d1072..71cc981 100644
--- a/doc/texinfo/locker.texi
+++ b/doc/texinfo/locker.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,
address@hidden 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
address@hidden Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/mailbox.texi b/doc/texinfo/mailbox.texi
index 9573648..f0faf0a 100644
--- a/doc/texinfo/mailbox.texi
+++ b/doc/texinfo/mailbox.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,
address@hidden 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
address@hidden Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/mailcap.texi b/doc/texinfo/mailcap.texi
index d77a820..65660a4 100644
--- a/doc/texinfo/mailcap.texi
+++ b/doc/texinfo/mailcap.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,
address@hidden 2007,2008 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2008,
address@hidden 2010 Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/maildir.texi b/doc/texinfo/maildir.texi
index 9864d1e..28b0cf3 100644
--- a/doc/texinfo/maildir.texi
+++ b/doc/texinfo/maildir.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,
address@hidden 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2007, 2010 Free
address@hidden Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/mailer.texi b/doc/texinfo/mailer.texi
index 4746bf3..f3c35ab 100644
--- a/doc/texinfo/mailer.texi
+++ b/doc/texinfo/mailer.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,
address@hidden 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
address@hidden Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/mailutils.texi b/doc/texinfo/mailutils.texi
index 0ce8986..eb989f0 100644
--- a/doc/texinfo/mailutils.texi
+++ b/doc/texinfo/mailutils.texi
@@ -50,8 +50,8 @@ Published by the Free Software Foundation,
51 Franklin Street, Fifth Floor
Boston, MA 02110-1301, USA
-Copyright @copyright{} 1999, 2000, 2001, 2002, 2003, 2004, 2008, 2009
-Free Software Foundation, Inc.
+Copyright @copyright{} 1999, 2000, 2001, 2002, 2003, 2004, 2008, 2009,
+2010 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2 or
diff --git a/doc/texinfo/mastermenu.el b/doc/texinfo/mastermenu.el
index 3ab3341..e821e28 100644
--- a/doc/texinfo/mastermenu.el
+++ b/doc/texinfo/mastermenu.el
@@ -1,6 +1,6 @@
;;; mastermenu.el --- Redefinition of texinfo-master-menu-list
-;; Copyright (C) 2006, 2007 Free Software Foundation, Inc.
+;; Copyright (C) 2006, 2007, 2010 Free Software Foundation, Inc.
;; Author: Sergey Poznyakoff
;; Maintainer: address@hidden
diff --git a/doc/texinfo/mbox.texi b/doc/texinfo/mbox.texi
index 0a63164..b502e42 100644
--- a/doc/texinfo/mbox.texi
+++ b/doc/texinfo/mbox.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,
address@hidden 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
address@hidden Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/message.texi b/doc/texinfo/message.texi
index 26ce4ed..9e2f9b3 100644
--- a/doc/texinfo/message.texi
+++ b/doc/texinfo/message.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,
address@hidden 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
address@hidden Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/mh.texi b/doc/texinfo/mh.texi
index bc86ef1..10a93b5 100644
--- a/doc/texinfo/mh.texi
+++ b/doc/texinfo/mh.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,
address@hidden 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2007, 2010 Free
address@hidden Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/mime.texi b/doc/texinfo/mime.texi
index 5186e38..2d43aa1 100644
--- a/doc/texinfo/mime.texi
+++ b/doc/texinfo/mime.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,
address@hidden 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
address@hidden Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/mom.texi b/doc/texinfo/mom.texi
index c6cf0dd..a337af1 100644
--- a/doc/texinfo/mom.texi
+++ b/doc/texinfo/mom.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,
address@hidden 2007,2008 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2007, 2008,
2010
address@hidden Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/mu-mh.texi b/doc/texinfo/mu-mh.texi
index 2fd2bcf..4f8d336 100644
--- a/doc/texinfo/mu-mh.texi
+++ b/doc/texinfo/mu-mh.texi
@@ -1,5 +1,5 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 2006, 2007, 2008 Free Software Foundation, Inc.
address@hidden Copyright (C) 2006, 2007, 2008, 2010 Free Software Foundation,
Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/muint.texi b/doc/texinfo/muint.texi
index f956664..9695654 100644
--- a/doc/texinfo/muint.texi
+++ b/doc/texinfo/muint.texi
@@ -20,7 +20,7 @@ Published by the Free Software Foundation,
51 Franklin Street, Fifth Floor
Boston, MA 02110-1301, USA
-Copyright @copyright{} 2003, 2004 Free Software Foundation, Inc.
+Copyright @copyright{} 2003, 2004, 2010 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2 or
diff --git a/doc/texinfo/nntp.texi b/doc/texinfo/nntp.texi
index 6849174..34eaaf8 100644
--- a/doc/texinfo/nntp.texi
+++ b/doc/texinfo/nntp.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,
address@hidden 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
address@hidden Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/parse822.texi b/doc/texinfo/parse822.texi
index 091e68e..6304e3f 100644
--- a/doc/texinfo/parse822.texi
+++ b/doc/texinfo/parse822.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,
address@hidden 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
address@hidden Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/programs.texi b/doc/texinfo/programs.texi
index 91a7d5e..118f44b 100644
--- a/doc/texinfo/programs.texi
+++ b/doc/texinfo/programs.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C)
1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
address@hidden Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006,
2007,
address@hidden 2008, 2009, 2010 Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/sendmail.texi b/doc/texinfo/sendmail.texi
index 21db9a1..c32ff32 100644
--- a/doc/texinfo/sendmail.texi
+++ b/doc/texinfo/sendmail.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,
address@hidden 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2007, 2010 Free
address@hidden Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/sieve.texi b/doc/texinfo/sieve.texi
index 91d894d..5a771ba 100644
--- a/doc/texinfo/sieve.texi
+++ b/doc/texinfo/sieve.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,
address@hidden 2007, 2008 Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2007, 2008,
2010
address@hidden Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/smtp.texi b/doc/texinfo/smtp.texi
index 2db028b..e320bf5 100644
--- a/doc/texinfo/smtp.texi
+++ b/doc/texinfo/smtp.texi
@@ -1,5 +1,5 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,2007
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
@c Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/stream.texi b/doc/texinfo/stream.texi
index eadb1ba..d4f7f35 100644
--- a/doc/texinfo/stream.texi
+++ b/doc/texinfo/stream.texi
@@ -1,5 +1,5 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,2007
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
@c Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/url.texi b/doc/texinfo/url.texi
index c140464..267a89f 100644
--- a/doc/texinfo/url.texi
+++ b/doc/texinfo/url.texi
@@ -1,5 +1,5 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2006,2007
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006, 2007,
2010
@c Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
diff --git a/doc/texinfo/usage.texi b/doc/texinfo/usage.texi
index e3a77e8..fbddba3 100644
--- a/doc/texinfo/usage.texi
+++ b/doc/texinfo/usage.texi
@@ -1,6 +1,6 @@
@c This is part of the GNU Mailutils manual.
address@hidden Copyright (C) 1999,2000,2001,2002,2003,2004,2005,2006,2007,2008
address@hidden Free Software Foundation, Inc.
address@hidden Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006,
2007,
address@hidden 2008, 2010 Free Software Foundation, Inc.
@c See file mailutils.texi for copying conditions.
@comment *******************************************************************
@node Usage Vars
diff --git a/dotlock/Makefile.am b/dotlock/Makefile.am
index 10f1855..820066a 100644
--- a/dotlock/Makefile.am
+++ b/dotlock/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2002, 2007, 2009 Free Software Foundation, Inc.
+## Copyright (C) 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/dotlock/dotlock.c b/dotlock/dotlock.c
index 09b70fa..553557d 100644
--- a/dotlock/dotlock.c
+++ b/dotlock/dotlock.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/examples/Makefile.am b/examples/Makefile.am
index bf378b5..1e189a1 100644
--- a/examples/Makefile.am
+++ b/examples/Makefile.am
@@ -1,7 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2002, 2003, 2004, 2007, 2008,
-## 2009 Free Software Foundation, Inc.
+## Copyright (C) 2002, 2003, 2004, 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/examples/aclck.c b/examples/aclck.c
index baee9fa..713a955 100644
--- a/examples/aclck.c
+++ b/examples/aclck.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2005,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2005, 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 published by
diff --git a/examples/addr.c b/examples/addr.c
index 74beaf2..aae456a 100644
--- a/examples/addr.c
+++ b/examples/addr.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 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 published by
diff --git a/examples/argcv.c b/examples/argcv.c
index f25c81d..3253feb 100644
--- a/examples/argcv.c
+++ b/examples/argcv.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2005, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/examples/base64.c b/examples/base64.c
index 0cc1bc3..dc4fde5 100644
--- a/examples/base64.c
+++ b/examples/base64.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2005,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2005, 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 published by
diff --git a/examples/config/Makefile.am b/examples/config/Makefile.am
index a5948fe..83983a8 100644
--- a/examples/config/Makefile.am
+++ b/examples/config/Makefile.am
@@ -1,6 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
+## Copyright (C) 2004, 2005, 2007, 2008, 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/examples/config/mailutils.dict b/examples/config/mailutils.dict
index 4d9ccf1..ab5039d 100644
--- a/examples/config/mailutils.dict
+++ b/examples/config/mailutils.dict
@@ -1,4 +1,4 @@
-# Copyright (C) 2005, 2007 Free Software Foundation, Inc.
+# Copyright (C) 2005, 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/examples/config/mailutils.schema b/examples/config/mailutils.schema
index a94ba85..d0f2b9c 100644
--- a/examples/config/mailutils.schema
+++ b/examples/config/mailutils.schema
@@ -1,6 +1,6 @@
# This file is part of GNU Mailutils -- a suite of utilities for electronic
# mail
-# Copyright (C) 2007, 2008 Free Software Foundation, Inc.
+# Copyright (C) 2007, 2008, 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/examples/cpp/Makefile.am b/examples/cpp/Makefile.am
index 3bee7f6..32da62f 100644
--- a/examples/cpp/Makefile.am
+++ b/examples/cpp/Makefile.am
@@ -1,6 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
##
-## Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+## Copyright (C) 2004, 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/examples/cpp/addr.cc b/examples/cpp/addr.cc
index a14318a..c861c0c 100644
--- a/examples/cpp/addr.cc
+++ b/examples/cpp/addr.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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 published by
diff --git a/examples/cpp/http.cc b/examples/cpp/http.cc
index 8e9031a..f523951 100644
--- a/examples/cpp/http.cc
+++ b/examples/cpp/http.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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 published by
diff --git a/examples/cpp/iconv.cc b/examples/cpp/iconv.cc
index 9e4dd8b..2901784 100644
--- a/examples/cpp/iconv.cc
+++ b/examples/cpp/iconv.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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 published by
diff --git a/examples/cpp/listop.cc b/examples/cpp/listop.cc
index 2034312..994b79c 100644
--- a/examples/cpp/listop.cc
+++ b/examples/cpp/listop.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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 published by
diff --git a/examples/cpp/lsf.cc b/examples/cpp/lsf.cc
index 6e1111c..306ee97 100644
--- a/examples/cpp/lsf.cc
+++ b/examples/cpp/lsf.cc
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/examples/cpp/mailcap.cc b/examples/cpp/mailcap.cc
index 0a00b6f..d1a0f45 100644
--- a/examples/cpp/mailcap.cc
+++ b/examples/cpp/mailcap.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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 published by
diff --git a/examples/cpp/mimetest.cc b/examples/cpp/mimetest.cc
index fe00331..40249ed 100644
--- a/examples/cpp/mimetest.cc
+++ b/examples/cpp/mimetest.cc
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/examples/cpp/msg-send.cc b/examples/cpp/msg-send.cc
index 993ce65..59179d2 100644
--- a/examples/cpp/msg-send.cc
+++ b/examples/cpp/msg-send.cc
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/examples/cpp/murun.cc b/examples/cpp/murun.cc
index f061b9e..13d3020 100644
--- a/examples/cpp/murun.cc
+++ b/examples/cpp/murun.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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 published by
diff --git a/examples/cpp/sfrom.cc b/examples/cpp/sfrom.cc
index 2349f2e..590b07e 100644
--- a/examples/cpp/sfrom.cc
+++ b/examples/cpp/sfrom.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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 published by
diff --git a/examples/cpp/url-parse.cc b/examples/cpp/url-parse.cc
index b10efe0..3c01181 100644
--- a/examples/cpp/url-parse.cc
+++ b/examples/cpp/url-parse.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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 published by
diff --git a/examples/decode2047.c b/examples/decode2047.c
index 59717c2..bdb1ca2 100644
--- a/examples/decode2047.c
+++ b/examples/decode2047.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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 published by
diff --git a/examples/echosrv.c b/examples/echosrv.c
index 8dc0aac..847a1a3 100644
--- a/examples/echosrv.c
+++ b/examples/echosrv.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2008, 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/examples/encode2047.c b/examples/encode2047.c
index 2b8d82d..b5b0dde 100644
--- a/examples/encode2047.c
+++ b/examples/encode2047.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2005, 2006, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2005, 2006, 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 published by
diff --git a/examples/header.c b/examples/header.c
index d9b015a..f53368a 100644
--- a/examples/header.c
+++ b/examples/header.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/examples/http.c b/examples/http.c
index 5e6e2a6..b62208b 100644
--- a/examples/http.c
+++ b/examples/http.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 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 published by
diff --git a/examples/iconv.c b/examples/iconv.c
index 74aaa3c..9aacfef 100644
--- a/examples/iconv.c
+++ b/examples/iconv.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 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 published by
diff --git a/examples/listop.c b/examples/listop.c
index c131c98..a92f911 100644
--- a/examples/listop.c
+++ b/examples/listop.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2004, 2005, 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 published by
diff --git a/examples/lsf.c b/examples/lsf.c
index 52c9cf6..3998c58 100644
--- a/examples/lsf.c
+++ b/examples/lsf.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2005, 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 published by
diff --git a/examples/mailcap.c b/examples/mailcap.c
index 4f5c57c..cacb752 100644
--- a/examples/mailcap.c
+++ b/examples/mailcap.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 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/examples/mimetest.c b/examples/mimetest.c
index 488bb31..90a00a0 100644
--- a/examples/mimetest.c
+++ b/examples/mimetest.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 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/examples/msg-send.c b/examples/msg-send.c
index 28aeada..4fdcf2c 100644
--- a/examples/msg-send.c
+++ b/examples/msg-send.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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 published by
diff --git a/examples/mta.c b/examples/mta.c
index f919b30..57b5daa 100644
--- a/examples/mta.c
+++ b/examples/mta.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 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/examples/muauth.c b/examples/muauth.c
index 2fc5b15..23ba521 100644
--- a/examples/muauth.c
+++ b/examples/muauth.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2006, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2006, 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 published by
diff --git a/examples/muemail.c b/examples/muemail.c
index 9037091..6bceb25 100644
--- a/examples/muemail.c
+++ b/examples/muemail.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.
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/examples/murun.c b/examples/murun.c
index b8e513a..f9fbc4f 100644
--- a/examples/murun.c
+++ b/examples/murun.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2005, 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 published by
diff --git a/examples/nntpclient.c b/examples/nntpclient.c
index b8bd401..0e7e806 100644
--- a/examples/nntpclient.c
+++ b/examples/nntpclient.c
@@ -2,7 +2,8 @@
GNU Mailutils nntp functions. This application interactively allows users
to contact a nntp server.
- Copyright (C) 2003, 2004, 2005, 2007, 2009 Free Software Foundation
+ Copyright (C) 2003, 2004, 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/examples/numaddr.c b/examples/numaddr.c
index 4409dd0..9a5bea0 100644
--- a/examples/numaddr.c
+++ b/examples/numaddr.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2005,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2005, 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 Lesser General Public License as published by
diff --git a/examples/pop3client.c b/examples/pop3client.c
index 2c2199e..6912920 100644
--- a/examples/pop3client.c
+++ b/examples/pop3client.c
@@ -2,7 +2,8 @@
GNU Mailutils pop3 functions. This application interactively allows users
to contact a pop3 server.
- Copyright (C) 2003, 2004, 2005, 2007, 2008, 2009 Free Software Foundation
+ Copyright (C) 2003, 2004, 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/examples/python/Makefile.am b/examples/python/Makefile.am
index 54e8a14..4f816ee 100644
--- a/examples/python/Makefile.am
+++ b/examples/python/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2009 Free Software Foundation, Inc.
+## Copyright (C) 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/examples/python/addr.py b/examples/python/addr.py
index de20867..2b844ed 100644
--- a/examples/python/addr.py
+++ b/examples/python/addr.py
@@ -1,5 +1,5 @@
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 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/examples/python/auth.py b/examples/python/auth.py
index 0703a28..e1e1c07 100644
--- a/examples/python/auth.py
+++ b/examples/python/auth.py
@@ -1,5 +1,5 @@
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 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/examples/python/iconv.py b/examples/python/iconv.py
index 751dcde..3e36381 100644
--- a/examples/python/iconv.py
+++ b/examples/python/iconv.py
@@ -1,5 +1,5 @@
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 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/examples/python/lsf.py b/examples/python/lsf.py
index c40a100..6bd9b03 100644
--- a/examples/python/lsf.py
+++ b/examples/python/lsf.py
@@ -1,5 +1,5 @@
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 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/examples/python/mailcap.py b/examples/python/mailcap.py
index 13ede6d..ca70dce 100644
--- a/examples/python/mailcap.py
+++ b/examples/python/mailcap.py
@@ -1,5 +1,5 @@
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 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/examples/python/mimetest.py b/examples/python/mimetest.py
index c4203c1..c14d727 100644
--- a/examples/python/mimetest.py
+++ b/examples/python/mimetest.py
@@ -1,5 +1,5 @@
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 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/examples/python/msg-send.py b/examples/python/msg-send.py
index 1d96bac..ce339b0 100644
--- a/examples/python/msg-send.py
+++ b/examples/python/msg-send.py
@@ -1,5 +1,5 @@
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 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/examples/python/sfrom.py b/examples/python/sfrom.py
index 7b7c70a..d942870 100644
--- a/examples/python/sfrom.py
+++ b/examples/python/sfrom.py
@@ -1,5 +1,5 @@
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 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/examples/python/url-parse.py b/examples/python/url-parse.py
index 9c13bf8..d331f0e 100644
--- a/examples/python/url-parse.py
+++ b/examples/python/url-parse.py
@@ -1,5 +1,5 @@
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 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/examples/scheme/Makefile.am b/examples/scheme/Makefile.am
index 0cbe575..5e4baeb 100644
--- a/examples/scheme/Makefile.am
+++ b/examples/scheme/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2004, 2007 Free Software Foundation, Inc.
+## Copyright (C) 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/examples/scheme/reply.scm b/examples/scheme/reply.scm
index 10b23ee..d246249 100644
--- a/examples/scheme/reply.scm
+++ b/examples/scheme/reply.scm
@@ -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.
;;;;
;;;; 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/examples/sfrom.c b/examples/sfrom.c
index 550647d..3a79cef 100644
--- a/examples/sfrom.c
+++ b/examples/sfrom.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 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 published by
diff --git a/examples/url-parse.c b/examples/url-parse.c
index efddda6..82541b5 100644
--- a/examples/url-parse.c
+++ b/examples/url-parse.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 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/frm/Makefile.am b/frm/Makefile.am
index ebfa557..8965eb7 100644
--- a/frm/Makefile.am
+++ b/frm/Makefile.am
@@ -1,7 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2001, 2002, 2003, 2004, 2005,
-## 2007 Free Software Foundation, Inc.
+## Copyright (C) 2001, 2002, 2003, 2004, 2005, 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/frm/common.c b/frm/common.c
index e1d2372..901c774 100644
--- a/frm/common.c
+++ b/frm/common.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2004, 2005, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 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 published by
diff --git a/frm/frm.c b/frm/frm.c
index 79ecb7e..b56bff2 100644
--- a/frm/frm.c
+++ b/frm/frm.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2004, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 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/frm/frm.h b/frm/frm.h
index 596a6bd..38ce39e 100644
--- a/frm/frm.h
+++ b/frm/frm.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2005, 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 published by
diff --git a/frm/from.c b/frm/from.c
index 3369fe7..080b548 100644
--- a/frm/from.c
+++ b/frm/from.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/frm/testsuite/Makefile.am b/frm/testsuite/Makefile.am
index b198b33..49704f9 100644
--- a/frm/testsuite/Makefile.am
+++ b/frm/testsuite/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2002, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2002, 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/frm/testsuite/frm/test.exp b/frm/testsuite/frm/test.exp
index a12e4aa..900aae8 100644
--- a/frm/testsuite/frm/test.exp
+++ b/frm/testsuite/frm/test.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007, 2009 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/guimb/Makefile.am b/guimb/Makefile.am
index 3197b9e..273371f 100644
--- a/guimb/Makefile.am
+++ b/guimb/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/guimb/collect.c b/guimb/collect.c
index 4b94c62..532fc47 100644
--- a/guimb/collect.c
+++ b/guimb/collect.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/guimb/guimb.h b/guimb/guimb.h
index 166f86c..1cae077 100644
--- a/guimb/guimb.h
+++ b/guimb/guimb.h
@@ -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/guimb/main.c b/guimb/main.c
index 23d472f..460c6bd 100644
--- a/guimb/main.c
+++ b/guimb/main.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2004, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 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/guimb/scm/Makefile.am b/guimb/scm/Makefile.am
index 70fa7c7..bb014ff 100644
--- a/guimb/scm/Makefile.am
+++ b/guimb/scm/Makefile.am
@@ -1,6 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2001, 2002, 2006, 2007, 2009 Free Software Foundation, Inc.
+## Copyright (C) 2001, 2002, 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/guimb/scm/mimeheader.scm b/guimb/scm/mimeheader.scm
index 4009ce7..a354694 100644
--- a/guimb/scm/mimeheader.scm
+++ b/guimb/scm/mimeheader.scm
@@ -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.
;;;;
;;;; 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/guimb/scm/numaddr.scm b/guimb/scm/numaddr.scm
index a712b9a..40032fd 100644
--- a/guimb/scm/numaddr.scm
+++ b/guimb/scm/numaddr.scm
@@ -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.
;;;;
;;;; 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/guimb/scm/redirect.scm b/guimb/scm/redirect.scm
index 1c8041d..ade16d6 100644
--- a/guimb/scm/redirect.scm
+++ b/guimb/scm/redirect.scm
@@ -1,5 +1,6 @@
;;;; GNU Mailutils -- a suite of utilities for electronic mail
-;;;; Copyright (C) 1999, 2000, 2001, 2006, 2007 Free Software Foundation, Inc.
+;;;; Copyright (C) 1999, 2000, 2001, 2006, 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 published by
diff --git a/guimb/scm/reject.scm b/guimb/scm/reject.scm
index b3de6cd..b399193 100644
--- a/guimb/scm/reject.scm
+++ b/guimb/scm/reject.scm
@@ -1,5 +1,6 @@
;;;; GNU Mailutils -- a suite of utilities for electronic mail
-;;;; Copyright (C) 1999, 2000, 2001, 2006, 2007 Free Software Foundation, Inc.
+;;;; Copyright (C) 1999, 2000, 2001, 2006, 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 published by
diff --git a/guimb/scm/sieve-core.scm b/guimb/scm/sieve-core.scm
index c75cf34..5a11c65 100644
--- a/guimb/scm/sieve-core.scm
+++ b/guimb/scm/sieve-core.scm
@@ -1,5 +1,6 @@
;;;; GNU Mailutils -- a suite of utilities for electronic mail
-;;;; Copyright (C) 1999, 2000, 2001, 2006, 2007 Free Software Foundation, Inc.
+;;;; Copyright (C) 1999, 2000, 2001, 2006, 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 published by
diff --git a/guimb/scm/sieve.scm.in b/guimb/scm/sieve.scm.in
index 293dcf7..68f0e49 100644
--- a/guimb/scm/sieve.scm.in
+++ b/guimb/scm/sieve.scm.in
@@ -2,8 +2,8 @@
# Emacs, it's -*- scheme -*-
!#
;;;; GNU Mailutils -- a suite of utilities for electronic mail
-;;;; Copyright (C) 1999, 2000, 2001, 2006, 2007,
-;;;; 2009 Free Software Foundation, Inc.
+;;;; Copyright (C) 1999, 2000, 2001, 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 published by
diff --git a/guimb/scm/vacation.scm b/guimb/scm/vacation.scm
index b6458a7..3e28729 100644
--- a/guimb/scm/vacation.scm
+++ b/guimb/scm/vacation.scm
@@ -1,5 +1,6 @@
;;;; GNU Mailutils -- a suite of utilities for electronic mail
-;;;; Copyright (C) 1999, 2000, 2001, 2006, 2007 Free Software Foundation, Inc.
+;;;; Copyright (C) 1999, 2000, 2001, 2006, 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 published by
diff --git a/guimb/util.c b/guimb/util.c
index 06c90d1..71a6769 100644
--- a/guimb/util.c
+++ b/guimb/util.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/imap4d/Makefile.am b/imap4d/Makefile.am
index 63da56d..65a5b8c 100644
--- a/imap4d/Makefile.am
+++ b/imap4d/Makefile.am
@@ -1,7 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 1999, 2000, 2001, 2002, 2003, 2005,
-## 2007, 2008, 2009 Free Software Foundation, Inc.
+## Copyright (C) 1999, 2000, 2001, 2002, 2003, 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
diff --git a/imap4d/append.c b/imap4d/append.c
index 3e54090..f6662aa 100644
--- a/imap4d/append.c
+++ b/imap4d/append.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2006, 2007,
- 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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 published by
diff --git a/imap4d/auth_gsasl.c b/imap4d/auth_gsasl.c
index d04ba28..3f137b0 100644
--- a/imap4d/auth_gsasl.c
+++ b/imap4d/auth_gsasl.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2004, 2005, 2007, 2008,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2004, 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/imap4d/auth_gss.c b/imap4d/auth_gss.c
index 40c6f16..a231137 100644
--- a/imap4d/auth_gss.c
+++ b/imap4d/auth_gss.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2004,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2003, 2004, 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/imap4d/authenticate.c b/imap4d/authenticate.c
index e9ae084..12978b5 100644
--- a/imap4d/authenticate.c
+++ b/imap4d/authenticate.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2006, 2007,
- 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2005, 2006, 2007, 2008, 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/imap4d/bye.c b/imap4d/bye.c
index 0a59aa5..832fc7c 100644
--- a/imap4d/bye.c
+++ b/imap4d/bye.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/imap4d/capability.c b/imap4d/capability.c
index 8f1a427..c88bc60 100644
--- a/imap4d/capability.c
+++ b/imap4d/capability.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2003, 2005, 2007,
- 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2003, 2005, 2007, 2008, 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/imap4d/check.c b/imap4d/check.c
index 58248c1..ee1897d 100644
--- a/imap4d/check.c
+++ b/imap4d/check.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2007, 2008, 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/imap4d/close.c b/imap4d/close.c
index fd45d06..732e849 100644
--- a/imap4d/close.c
+++ b/imap4d/close.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2004, 2005, 2007,
- 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2004, 2005, 2007, 2008, 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/imap4d/commands.c b/imap4d/commands.c
index c4df139..a40c623 100644
--- a/imap4d/commands.c
+++ b/imap4d/commands.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2003, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2003, 2007, 2008, 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/imap4d/copy.c b/imap4d/copy.c
index 98d1388..b25e1ee 100644
--- a/imap4d/copy.c
+++ b/imap4d/copy.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2007, 2008,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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/imap4d/create.c b/imap4d/create.c
index 9de4c89..0768d9f 100644
--- a/imap4d/create.c
+++ b/imap4d/create.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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/imap4d/delete.c b/imap4d/delete.c
index ae15030..b6f4f90 100644
--- a/imap4d/delete.c
+++ b/imap4d/delete.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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/imap4d/examine.c b/imap4d/examine.c
index 0a08318..6f5ed6a 100644
--- a/imap4d/examine.c
+++ b/imap4d/examine.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2007, 2008, 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/imap4d/expunge.c b/imap4d/expunge.c
index bb2128f..efea04f 100644
--- a/imap4d/expunge.c
+++ b/imap4d/expunge.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2005, 2007, 2008, 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/imap4d/fetch.c b/imap4d/fetch.c
index faca25e..c84fc6d 100644
--- a/imap4d/fetch.c
+++ b/imap4d/fetch.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2006, 2007,
- 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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 published by
diff --git a/imap4d/id.c b/imap4d/id.c
index 4715baa..39105d0 100644
--- a/imap4d/id.c
+++ b/imap4d/id.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/imap4d/idle.c b/imap4d/idle.c
index 1fc7519..e3ddd6c 100644
--- a/imap4d/idle.c
+++ b/imap4d/idle.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/imap4d/imap4d.c b/imap4d/imap4d.c
index 6f9e84d..4fd7556 100644
--- a/imap4d/imap4d.c
+++ b/imap4d/imap4d.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2004,
- 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 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 published by
diff --git a/imap4d/imap4d.h b/imap4d/imap4d.h
index 4abc281..1d9378d 100644
--- a/imap4d/imap4d.h
+++ b/imap4d/imap4d.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2004,
- 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 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 published by
diff --git a/imap4d/list.c b/imap4d/list.c
index ecb54f2..7ee42be 100644
--- a/imap4d/list.c
+++ b/imap4d/list.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2005, 2006,
- 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 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 published by
diff --git a/imap4d/login.c b/imap4d/login.c
index 4528fe7..5a313d7 100644
--- a/imap4d/login.c
+++ b/imap4d/login.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2006,
- 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 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 published by
diff --git a/imap4d/logout.c b/imap4d/logout.c
index 31e805c..d6ca0e0 100644
--- a/imap4d/logout.c
+++ b/imap4d/logout.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2007, 2008, 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/imap4d/lsub.c b/imap4d/lsub.c
index 3ab3416..5b748ae 100644
--- a/imap4d/lsub.c
+++ b/imap4d/lsub.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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/imap4d/namespace.c b/imap4d/namespace.c
index f2abf66..45feeca 100644
--- a/imap4d/namespace.c
+++ b/imap4d/namespace.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2007, 2008,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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/imap4d/noop.c b/imap4d/noop.c
index cf9c15a..d09d50a 100644
--- a/imap4d/noop.c
+++ b/imap4d/noop.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2007, 2008, 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/imap4d/parsebuf.c b/imap4d/parsebuf.c
index f43d68a..028b57a 100644
--- a/imap4d/parsebuf.c
+++ b/imap4d/parsebuf.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/imap4d/preauth.c b/imap4d/preauth.c
index 808a0c1..a9a2a5c 100644
--- a/imap4d/preauth.c
+++ b/imap4d/preauth.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2004,
- 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 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 published by
diff --git a/imap4d/rename.c b/imap4d/rename.c
index d9aaf0e..97cfa41 100644
--- a/imap4d/rename.c
+++ b/imap4d/rename.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2007, 2008,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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/imap4d/search.c b/imap4d/search.c
index 816c1ab..a753cb7 100644
--- a/imap4d/search.c
+++ b/imap4d/search.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2005, 2007,
- 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 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/imap4d/select.c b/imap4d/select.c
index 6b4949d..dcf3fe0 100644
--- a/imap4d/select.c
+++ b/imap4d/select.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2003, 2005, 2006,
- 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2003, 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 published by
diff --git a/imap4d/signal.c b/imap4d/signal.c
index d883e08..c9dcfc5 100644
--- a/imap4d/signal.c
+++ b/imap4d/signal.c
@@ -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/imap4d/starttls.c b/imap4d/starttls.c
index e2dfbd6..fbb1e4d 100644
--- a/imap4d/starttls.c
+++ b/imap4d/starttls.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/imap4d/status.c b/imap4d/status.c
index 6568c65..3933a79 100644
--- a/imap4d/status.c
+++ b/imap4d/status.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2007, 2008,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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/imap4d/store.c b/imap4d/store.c
index 147e800..ac06bdc 100644
--- a/imap4d/store.c
+++ b/imap4d/store.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2007, 2008,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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/imap4d/subscribe.c b/imap4d/subscribe.c
index 7cc1b3d..b604d04 100644
--- a/imap4d/subscribe.c
+++ b/imap4d/subscribe.c
@@ -1,5 +1,6 @@
/* GNU mailutils - a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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/imap4d/sync.c b/imap4d/sync.c
index 7c70732..3877a93 100644
--- a/imap4d/sync.c
+++ b/imap4d/sync.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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/imap4d/testsuite/Makefile.am b/imap4d/testsuite/Makefile.am
index 7b213ce..5f3a9ee 100644
--- a/imap4d/testsuite/Makefile.am
+++ b/imap4d/testsuite/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2002, 2007, 2008 Free Software Foundation, Inc.
+## Copyright (C) 2002, 2007, 2008, 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/imap4d/testsuite/imap4d.rcin b/imap4d/testsuite/imap4d.rcin
index f72d114..57d9a50 100644
--- a/imap4d/testsuite/imap4d.rcin
+++ b/imap4d/testsuite/imap4d.rcin
@@ -1,5 +1,5 @@
# Configuration file for Mailutils Imap4d testsuite.
-# Copyright (C) 2008 Free Software Foundation, Inc.
+# Copyright (C) 2008, 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/imap4d/testsuite/imap4d/IDEF0955.exp
b/imap4d/testsuite/imap4d/IDEF0955.exp
index be0717f..10e97f5 100644
--- a/imap4d/testsuite/imap4d/IDEF0955.exp
+++ b/imap4d/testsuite/imap4d/IDEF0955.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2005, 2007, 2008 Free Software Foundation
+# Copyright (C) 2005, 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/imap4d/testsuite/imap4d/IDEF0956.exp
b/imap4d/testsuite/imap4d/IDEF0956.exp
index e611ff2..09dabe7 100644
--- a/imap4d/testsuite/imap4d/IDEF0956.exp
+++ b/imap4d/testsuite/imap4d/IDEF0956.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2005, 2007 Free Software Foundation
+# Copyright (C) 2005, 2007, 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/imap4d/testsuite/imap4d/anystate.exp
b/imap4d/testsuite/imap4d/anystate.exp
index 92b2b5a..7e9ef7f 100644
--- a/imap4d/testsuite/imap4d/anystate.exp
+++ b/imap4d/testsuite/imap4d/anystate.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007, 2008 Free Software Foundation
+# Copyright (C) 2002, 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/imap4d/testsuite/imap4d/append.exp
b/imap4d/testsuite/imap4d/append.exp
index 899be28..c635be3 100644
--- a/imap4d/testsuite/imap4d/append.exp
+++ b/imap4d/testsuite/imap4d/append.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/imap4d/testsuite/imap4d/create.exp
b/imap4d/testsuite/imap4d/create.exp
index b53584e..4c38351 100644
--- a/imap4d/testsuite/imap4d/create.exp
+++ b/imap4d/testsuite/imap4d/create.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/imap4d/testsuite/imap4d/examine.exp
b/imap4d/testsuite/imap4d/examine.exp
index 50b628e..a77a1b7 100644
--- a/imap4d/testsuite/imap4d/examine.exp
+++ b/imap4d/testsuite/imap4d/examine.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007, 2008 Free Software Foundation
+# Copyright (C) 2002, 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/imap4d/testsuite/imap4d/expunge.exp
b/imap4d/testsuite/imap4d/expunge.exp
index b0b8b7f..d8b84eb 100644
--- a/imap4d/testsuite/imap4d/expunge.exp
+++ b/imap4d/testsuite/imap4d/expunge.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/imap4d/testsuite/imap4d/fetch.exp
b/imap4d/testsuite/imap4d/fetch.exp
index deb5bf4..bc3aabf 100644
--- a/imap4d/testsuite/imap4d/fetch.exp
+++ b/imap4d/testsuite/imap4d/fetch.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/imap4d/testsuite/imap4d/list.exp b/imap4d/testsuite/imap4d/list.exp
index 38e8d3e..6cf551c 100644
--- a/imap4d/testsuite/imap4d/list.exp
+++ b/imap4d/testsuite/imap4d/list.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2005, 2007, 2008 Free Software Foundation
+# Copyright (C) 2002, 2005, 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/imap4d/testsuite/imap4d/search.exp
b/imap4d/testsuite/imap4d/search.exp
index 0a56538..4ae413a 100644
--- a/imap4d/testsuite/imap4d/search.exp
+++ b/imap4d/testsuite/imap4d/search.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/imap4d/testsuite/imap4d/x.exp b/imap4d/testsuite/imap4d/x.exp
index 86fcf9c..f0e6754 100644
--- a/imap4d/testsuite/imap4d/x.exp
+++ b/imap4d/testsuite/imap4d/x.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007, 2008 Free Software Foundation
+# Copyright (C) 2002, 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/imap4d/testsuite/lib/imap4d.exp b/imap4d/testsuite/lib/imap4d.exp
index 2627aea..213c5ef 100644
--- a/imap4d/testsuite/lib/imap4d.exp
+++ b/imap4d/testsuite/lib/imap4d.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2005, 2007, 2008 Free Software Foundation
+# Copyright (C) 2002, 2005, 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/imap4d/uid.c b/imap4d/uid.c
index 40b9edb..6c9e132 100644
--- a/imap4d/uid.c
+++ b/imap4d/uid.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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/imap4d/unsubscribe.c b/imap4d/unsubscribe.c
index 5b8a46a..3ef2ac2 100644
--- a/imap4d/unsubscribe.c
+++ b/imap4d/unsubscribe.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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/imap4d/util.c b/imap4d/util.c
index b5f0fa0..51b19c1 100644
--- a/imap4d/util.c
+++ b/imap4d/util.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2004,
- 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 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 published by
diff --git a/include/Makefile.am b/include/Makefile.am
index 1aab514..4fabc9d 100644
--- a/include/Makefile.am
+++ b/include/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2000, 2002, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2000, 2002, 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/include/mailutils/Makefile.am b/include/mailutils/Makefile.am
index 3ffda26..d1261d2 100644
--- a/include/mailutils/Makefile.am
+++ b/include/mailutils/Makefile.am
@@ -1,7 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2000, 2001, 2002, 2003,
-## 2004, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+## Copyright (C) 2000, 2001, 2002, 2003, 2004, 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
diff --git a/include/mailutils/acl.h b/include/mailutils/acl.h
index d6f1b2b..0ec6a97 100644
--- a/include/mailutils/acl.h
+++ b/include/mailutils/acl.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007 Free Software Foundation, Inc.
+ Copyright (C) 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/include/mailutils/address.h b/include/mailutils/address.h
index dfc3575..1ae0a48 100644
--- a/include/mailutils/address.h
+++ b/include/mailutils/address.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2005, 2006, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2005, 2006, 2007, 2009, 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/include/mailutils/alloc.h b/include/mailutils/alloc.h
index 4ec017b..27ab193 100644
--- a/include/mailutils/alloc.h
+++ b/include/mailutils/alloc.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2008 Free Software Foundation, Inc.
+ Copyright (C) 2008, 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/include/mailutils/argcv.h b/include/mailutils/argcv.h
index 158d4cc..3dff1e5 100644
--- a/include/mailutils/argcv.h
+++ b/include/mailutils/argcv.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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/include/mailutils/assoc.h b/include/mailutils/assoc.h
index 734d962..a3faea8 100644
--- a/include/mailutils/assoc.h
+++ b/include/mailutils/assoc.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007 Free Software Foundation, Inc.
+ Copyright (C) 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/include/mailutils/attribute.h b/include/mailutils/attribute.h
index dacf04e..c8c066f 100644
--- a/include/mailutils/attribute.h
+++ b/include/mailutils/attribute.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2007, 2009, 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/include/mailutils/auth.h b/include/mailutils/auth.h
index 7876b95..84c6cc1 100644
--- a/include/mailutils/auth.h
+++ b/include/mailutils/auth.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2007, 2009, 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/include/mailutils/body.h b/include/mailutils/body.h
index e1bcc03..d6552db 100644
--- a/include/mailutils/body.h
+++ b/include/mailutils/body.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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/include/mailutils/cctype.h b/include/mailutils/cctype.h
index 8a23eef..a39b8c6 100644
--- a/include/mailutils/cctype.h
+++ b/include/mailutils/cctype.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/include/mailutils/cfg.h b/include/mailutils/cfg.h
index 8141d12..3123f33 100644
--- a/include/mailutils/cfg.h
+++ b/include/mailutils/cfg.h
@@ -1,5 +1,5 @@
/* cfg.h -- general-purpose configuration file parser
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/include/mailutils/cpp/Makefile.am
b/include/mailutils/cpp/Makefile.am
index 4438972..d9be44b 100644
--- a/include/mailutils/cpp/Makefile.am
+++ b/include/mailutils/cpp/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
##
-## Copyright (C) 2004, 2007, 2009 Free Software Foundation, Inc.
+## Copyright (C) 2004, 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/include/mailutils/cpp/address.h b/include/mailutils/cpp/address.h
index 0663434..71e7913 100644
--- a/include/mailutils/cpp/address.h
+++ b/include/mailutils/cpp/address.h
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/include/mailutils/cpp/attribute.h
b/include/mailutils/cpp/attribute.h
index 5efd650..64135d2 100644
--- a/include/mailutils/cpp/attribute.h
+++ b/include/mailutils/cpp/attribute.h
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/include/mailutils/cpp/body.h b/include/mailutils/cpp/body.h
index c6dca9e..06e99ef 100644
--- a/include/mailutils/cpp/body.h
+++ b/include/mailutils/cpp/body.h
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/include/mailutils/cpp/debug.h b/include/mailutils/cpp/debug.h
index e0cf972..68e7488 100644
--- a/include/mailutils/cpp/debug.h
+++ b/include/mailutils/cpp/debug.h
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/include/mailutils/cpp/envelope.h b/include/mailutils/cpp/envelope.h
index 5d922b8..df33c92 100644
--- a/include/mailutils/cpp/envelope.h
+++ b/include/mailutils/cpp/envelope.h
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/include/mailutils/cpp/error.h b/include/mailutils/cpp/error.h
index f03c356..1806188 100644
--- a/include/mailutils/cpp/error.h
+++ b/include/mailutils/cpp/error.h
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/include/mailutils/cpp/filter.h b/include/mailutils/cpp/filter.h
index 5766c68..08d75d4 100644
--- a/include/mailutils/cpp/filter.h
+++ b/include/mailutils/cpp/filter.h
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/include/mailutils/cpp/folder.h b/include/mailutils/cpp/folder.h
index 439825c..f80b6de 100644
--- a/include/mailutils/cpp/folder.h
+++ b/include/mailutils/cpp/folder.h
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/include/mailutils/cpp/header.h b/include/mailutils/cpp/header.h
index 130751a..a302305 100644
--- a/include/mailutils/cpp/header.h
+++ b/include/mailutils/cpp/header.h
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/include/mailutils/cpp/iterator.h b/include/mailutils/cpp/iterator.h
index 634eb56..9c5dc7d 100644
--- a/include/mailutils/cpp/iterator.h
+++ b/include/mailutils/cpp/iterator.h
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/include/mailutils/cpp/list.h b/include/mailutils/cpp/list.h
index 44f21a7..810b66b 100644
--- a/include/mailutils/cpp/list.h
+++ b/include/mailutils/cpp/list.h
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/include/mailutils/cpp/mailbox.h b/include/mailutils/cpp/mailbox.h
index 2bc7fc1..42df080 100644
--- a/include/mailutils/cpp/mailbox.h
+++ b/include/mailutils/cpp/mailbox.h
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/include/mailutils/cpp/mailcap.h b/include/mailutils/cpp/mailcap.h
index a5d6ba3..435cbde 100644
--- a/include/mailutils/cpp/mailcap.h
+++ b/include/mailutils/cpp/mailcap.h
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/include/mailutils/cpp/mailer.h b/include/mailutils/cpp/mailer.h
index 40e3884..46bb8ef 100644
--- a/include/mailutils/cpp/mailer.h
+++ b/include/mailutils/cpp/mailer.h
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/include/mailutils/cpp/mailutils.h
b/include/mailutils/cpp/mailutils.h
index da14cce..9689f6c 100644
--- a/include/mailutils/cpp/mailutils.h
+++ b/include/mailutils/cpp/mailutils.h
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/include/mailutils/cpp/message.h b/include/mailutils/cpp/message.h
index dbe2271..19f076d 100644
--- a/include/mailutils/cpp/message.h
+++ b/include/mailutils/cpp/message.h
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/include/mailutils/cpp/mime.h b/include/mailutils/cpp/mime.h
index 199e28e..1ced7b4 100644
--- a/include/mailutils/cpp/mime.h
+++ b/include/mailutils/cpp/mime.h
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/include/mailutils/cpp/mutil.h b/include/mailutils/cpp/mutil.h
index ab7dda3..6222442 100644
--- a/include/mailutils/cpp/mutil.h
+++ b/include/mailutils/cpp/mutil.h
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/include/mailutils/cpp/pop3.h b/include/mailutils/cpp/pop3.h
index 6f15fc8..943e79a 100644
--- a/include/mailutils/cpp/pop3.h
+++ b/include/mailutils/cpp/pop3.h
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/include/mailutils/cpp/registrar.h
b/include/mailutils/cpp/registrar.h
index c380cea..ba9de52 100644
--- a/include/mailutils/cpp/registrar.h
+++ b/include/mailutils/cpp/registrar.h
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/include/mailutils/cpp/secret.h b/include/mailutils/cpp/secret.h
index e7c79df..ab4ea50 100644
--- a/include/mailutils/cpp/secret.h
+++ b/include/mailutils/cpp/secret.h
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/include/mailutils/cpp/sieve.h b/include/mailutils/cpp/sieve.h
index 3dd2a02..c7b1ae1 100644
--- a/include/mailutils/cpp/sieve.h
+++ b/include/mailutils/cpp/sieve.h
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/include/mailutils/cpp/stream.h b/include/mailutils/cpp/stream.h
index 2d4f52f..be05203 100644
--- a/include/mailutils/cpp/stream.h
+++ b/include/mailutils/cpp/stream.h
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/include/mailutils/cpp/url.h b/include/mailutils/cpp/url.h
index c12f944..7f218e4 100644
--- a/include/mailutils/cpp/url.h
+++ b/include/mailutils/cpp/url.h
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2008, 2009, 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/include/mailutils/cstr.h b/include/mailutils/cstr.h
index b493494..787855a 100644
--- a/include/mailutils/cstr.h
+++ b/include/mailutils/cstr.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/include/mailutils/daemon.h b/include/mailutils/daemon.h
index 2418f02..49c43c5 100644
--- a/include/mailutils/daemon.h
+++ b/include/mailutils/daemon.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 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/include/mailutils/debug.hm4 b/include/mailutils/debug.hm4
index e43805e..7682d25 100644
--- a/include/mailutils/debug.hm4
+++ b/include/mailutils/debug.hm4
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail -*- c -*-
- Copyright (C) 1999, 2000, 2005, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2005, 2007, 2008, 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/include/mailutils/diag.h b/include/mailutils/diag.h
index c738f5e..3f3695c 100644
--- a/include/mailutils/diag.h
+++ b/include/mailutils/diag.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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/include/mailutils/envelope.h b/include/mailutils/envelope.h
index 8411d62..7d0f439 100644
--- a/include/mailutils/envelope.h
+++ b/include/mailutils/envelope.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2005, 2006, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2005, 2006, 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/include/mailutils/errno.hin b/include/mailutils/errno.hin
index c197686..306f345 100644
--- a/include/mailutils/errno.hin
+++ b/include/mailutils/errno.hin
@@ -1,7 +1,7 @@
/* -*- c -*- $AUTOWARN
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2003, 2004,
- 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 2004, 2005, 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/include/mailutils/error.h b/include/mailutils/error.h
index 97c8a54..4b3afe3 100644
--- a/include/mailutils/error.h
+++ b/include/mailutils/error.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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/include/mailutils/filter.h b/include/mailutils/filter.h
index f923b2e..779abbd 100644
--- a/include/mailutils/filter.h
+++ b/include/mailutils/filter.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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/include/mailutils/folder.h b/include/mailutils/folder.h
index 4b4cbb3..03390dc 100644
--- a/include/mailutils/folder.h
+++ b/include/mailutils/folder.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2007, 2009, 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/include/mailutils/gocs.h b/include/mailutils/gocs.h
index 8631e33..80d9cbe 100644
--- a/include/mailutils/gocs.h
+++ b/include/mailutils/gocs.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2008, 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/include/mailutils/gsasl.h b/include/mailutils/gsasl.h
index 8bf7a99..583b356 100644
--- a/include/mailutils/gsasl.h
+++ b/include/mailutils/gsasl.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2004, 2005, 2007, 2008,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2004, 2005, 2007, 2008, 2009, 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/include/mailutils/guile.h b/include/mailutils/guile.h
index e2e233f..1c0e6e2 100644
--- a/include/mailutils/guile.h
+++ b/include/mailutils/guile.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2005, 2006, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2005, 2006, 2007, 2009, 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/include/mailutils/header.h b/include/mailutils/header.h
index 79ae7e7..b994415 100644
--- a/include/mailutils/header.h
+++ b/include/mailutils/header.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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/include/mailutils/io.h b/include/mailutils/io.h
index b108743..6dff003 100644
--- a/include/mailutils/io.h
+++ b/include/mailutils/io.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/include/mailutils/iterator.h b/include/mailutils/iterator.h
index e668e14..dfe4c2d 100644
--- a/include/mailutils/iterator.h
+++ b/include/mailutils/iterator.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2004, 2005, 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/include/mailutils/kwd.h b/include/mailutils/kwd.h
index da7036d..bc7c92a 100644
--- a/include/mailutils/kwd.h
+++ b/include/mailutils/kwd.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007 Free Software Foundation, Inc.
+ Copyright (C) 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/include/mailutils/ldap.h b/include/mailutils/ldap.h
index 21fd7be..cd167cf 100644
--- a/include/mailutils/ldap.h
+++ b/include/mailutils/ldap.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 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/include/mailutils/libargp.h b/include/mailutils/libargp.h
index 42f0cc9..63f1aa7 100644
--- a/include/mailutils/libargp.h
+++ b/include/mailutils/libargp.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2007, 2008, 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/include/mailutils/libcfg.h b/include/mailutils/libcfg.h
index 20afa52..d8600ed 100644
--- a/include/mailutils/libcfg.h
+++ b/include/mailutils/libcfg.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2008, 2009, 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/include/mailutils/list.h b/include/mailutils/list.h
index 6c26ed0..cbe31d9 100644
--- a/include/mailutils/list.h
+++ b/include/mailutils/list.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2005, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2005, 2007, 2008, 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/include/mailutils/locker.h b/include/mailutils/locker.h
index 7dee938..da9b3b1 100644
--- a/include/mailutils/locker.h
+++ b/include/mailutils/locker.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2007, 2008, 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/include/mailutils/mailbox.h b/include/mailutils/mailbox.h
index e3222af..d554c9b 100644
--- a/include/mailutils/mailbox.h
+++ b/include/mailutils/mailbox.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2006,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2006, 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/include/mailutils/mailcap.h b/include/mailutils/mailcap.h
index c7b5b00..b6998d1 100644
--- a/include/mailutils/mailcap.h
+++ b/include/mailutils/mailcap.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2003, 2005,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2003, 2005, 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/include/mailutils/mailer.h b/include/mailutils/mailer.h
index 7f41c3e..56f6615 100644
--- a/include/mailutils/mailer.h
+++ b/include/mailutils/mailer.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005,
- 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2007, 2008, 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/include/mailutils/mailutils.h b/include/mailutils/mailutils.h
index 68a0b68..ad0f961 100644
--- a/include/mailutils/mailutils.h
+++ b/include/mailutils/mailutils.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2004, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2007, 2008, 2009,
+ 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/include/mailutils/md5.h b/include/mailutils/md5.h
index efc4711..d6933e4 100644
--- a/include/mailutils/md5.h
+++ b/include/mailutils/md5.h
@@ -1,7 +1,7 @@
/* Declaration of functions and data types used for MD5 sum computing
library functions.
- Copyright (C) 1995-1997,1999,2000,2001,2004,2005,2006
- Free Software Foundation, Inc.
+ Copyright (C) 1995, 1996, 1997, 1999, 2000, 2001, 2004, 2005, 2006,
+ 2010 Free Software Foundation, Inc.
This file is part of the GNU C Library.
This program is free software; you can redistribute it and/or modify it
diff --git a/include/mailutils/message.h b/include/mailutils/message.h
index e0f7628..724766a 100644
--- a/include/mailutils/message.h
+++ b/include/mailutils/message.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2006,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2006, 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/include/mailutils/mime.h b/include/mailutils/mime.h
index 3bf8706..cd70682 100644
--- a/include/mailutils/mime.h
+++ b/include/mailutils/mime.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2003, 2005,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 2005, 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/include/mailutils/monitor.h b/include/mailutils/monitor.h
index 9dc0767..4e170da 100644
--- a/include/mailutils/monitor.h
+++ b/include/mailutils/monitor.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2005, 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/include/mailutils/mu_auth.h b/include/mailutils/mu_auth.h
index 5bd76ed..7453d30 100644
--- a/include/mailutils/mu_auth.h
+++ b/include/mailutils/mu_auth.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2002, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2002, 2005, 2007, 2008, 2009, 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/include/mailutils/mutil.h b/include/mailutils/mutil.h
index a610e23..7acc021 100644
--- a/include/mailutils/mutil.h
+++ b/include/mailutils/mutil.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2006, 2007, 2009, 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/include/mailutils/nls.h b/include/mailutils/nls.h
index 21e765c..c84a772 100644
--- a/include/mailutils/nls.h
+++ b/include/mailutils/nls.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2002, 2005, 2006, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2002, 2005, 2006, 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/include/mailutils/nntp.h b/include/mailutils/nntp.h
index 647f3b4..d16fb54 100644
--- a/include/mailutils/nntp.h
+++ b/include/mailutils/nntp.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 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/include/mailutils/observer.h b/include/mailutils/observer.h
index 8e6c537..ffb9ea5 100644
--- a/include/mailutils/observer.h
+++ b/include/mailutils/observer.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2005, 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/include/mailutils/opool.h b/include/mailutils/opool.h
index 25f6417..78b66a7 100644
--- a/include/mailutils/opool.h
+++ b/include/mailutils/opool.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2008, 2009, 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/include/mailutils/pam.h b/include/mailutils/pam.h
index 61590b3..207bb23 100644
--- a/include/mailutils/pam.h
+++ b/include/mailutils/pam.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 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/include/mailutils/parse822.h b/include/mailutils/parse822.h
index 83e3820..2105539 100644
--- a/include/mailutils/parse822.h
+++ b/include/mailutils/parse822.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2007, 2009, 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/include/mailutils/pop3.h b/include/mailutils/pop3.h
index 4d595d7..d1c7db5 100644
--- a/include/mailutils/pop3.h
+++ b/include/mailutils/pop3.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2003, 2004,
- 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 2004, 2005, 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/include/mailutils/progmailer.h b/include/mailutils/progmailer.h
index f44cad3..e9a82c3 100644
--- a/include/mailutils/progmailer.h
+++ b/include/mailutils/progmailer.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2008 Free Software Foundation, Inc.
+ Copyright (C) 2008, 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/include/mailutils/property.h b/include/mailutils/property.h
index a9c92df..e57bba4 100644
--- a/include/mailutils/property.h
+++ b/include/mailutils/property.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007, 2008
- Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2007, 2008, 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/include/mailutils/python.h b/include/mailutils/python.h
index ca90c5c..9bd32dd 100644
--- a/include/mailutils/python.h
+++ b/include/mailutils/python.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/include/mailutils/radius.h b/include/mailutils/radius.h
index 385e5b3..a62cddc 100644
--- a/include/mailutils/radius.h
+++ b/include/mailutils/radius.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2007, 2008, 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/include/mailutils/refcount.h b/include/mailutils/refcount.h
index 5df0a6f..2c8d287 100644
--- a/include/mailutils/refcount.h
+++ b/include/mailutils/refcount.h
@@ -1,6 +1,6 @@
/* GNU mailutils - a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003, 2005,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2005, 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/include/mailutils/registrar.h b/include/mailutils/registrar.h
index 6462054..91a3acf 100644
--- a/include/mailutils/registrar.h
+++ b/include/mailutils/registrar.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2004, 2005, 2006,
- 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2004, 2005, 2006, 2007, 2008, 2009, 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/include/mailutils/secret.h b/include/mailutils/secret.h
index 24df73a..a97c968 100644
--- a/include/mailutils/secret.h
+++ b/include/mailutils/secret.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/include/mailutils/server.h b/include/mailutils/server.h
index 866da28..da3506c 100644
--- a/include/mailutils/server.h
+++ b/include/mailutils/server.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2008, 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/include/mailutils/sha1.h b/include/mailutils/sha1.h
index f717acf..fecb294 100644
--- a/include/mailutils/sha1.h
+++ b/include/mailutils/sha1.h
@@ -1,6 +1,7 @@
/* Declarations of functions and data types used for SHA1 sum
library functions.
- Copyright (C) 2000, 2001, 2003, 2005, 2006 Free Software Foundation, Inc.
+ Copyright (C) 2000, 2001, 2003, 2005, 2006, 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 the
diff --git a/include/mailutils/sieve.h b/include/mailutils/sieve.h
index ac36534..f89d409 100644
--- a/include/mailutils/sieve.h
+++ b/include/mailutils/sieve.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2005,
- 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2005, 2006, 2007, 2008, 2009,
+ 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/include/mailutils/sql.h b/include/mailutils/sql.h
index 74b8568..84672a2 100644
--- a/include/mailutils/sql.h
+++ b/include/mailutils/sql.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 2007, 2009, 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/include/mailutils/stream.h b/include/mailutils/stream.h
index 20404d4..59c8b25 100644
--- a/include/mailutils/stream.h
+++ b/include/mailutils/stream.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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/include/mailutils/sys/Makefile.am
b/include/mailutils/sys/Makefile.am
index 75aab66..e220ad8 100644
--- a/include/mailutils/sys/Makefile.am
+++ b/include/mailutils/sys/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2002, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2002, 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/include/mailutils/sys/nntp.h b/include/mailutils/sys/nntp.h
index 5b28ad5..8f86bec 100644
--- a/include/mailutils/sys/nntp.h
+++ b/include/mailutils/sys/nntp.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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/include/mailutils/sys/pop3.h b/include/mailutils/sys/pop3.h
index 35b1165..419397b 100644
--- a/include/mailutils/sys/pop3.h
+++ b/include/mailutils/sys/pop3.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2003, 2004,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 2004, 2007, 2009, 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/include/mailutils/syslog.h b/include/mailutils/syslog.h
index 92232c8..34554f9 100644
--- a/include/mailutils/syslog.h
+++ b/include/mailutils/syslog.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2008, 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/include/mailutils/tls.h b/include/mailutils/tls.h
index e4d4005..9848f82 100644
--- a/include/mailutils/tls.h
+++ b/include/mailutils/tls.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2005, 2007, 2008, 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/include/mailutils/types.hin b/include/mailutils/types.hin
index 9c60249..8fa1983 100644
--- a/include/mailutils/types.hin
+++ b/include/mailutils/types.hin
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail -*- c -*-
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2007, 2008, 2009, 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/include/mailutils/url.h b/include/mailutils/url.h
index ea61f84..ca0dcb3 100644
--- a/include/mailutils/url.h
+++ b/include/mailutils/url.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2007, 2008, 2009, 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/include/mailutils/vartab.h b/include/mailutils/vartab.h
index 6a9b828..26f46bb 100644
--- a/include/mailutils/vartab.h
+++ b/include/mailutils/vartab.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007 Free Software Foundation, Inc.
+ Copyright (C) 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/include/mailutils/version.h b/include/mailutils/version.h
index d875f4d..60468c1 100644
--- a/include/mailutils/version.h
+++ b/include/mailutils/version.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2008, 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/lib/Makefile.am b/lib/Makefile.am
index 15dcdc3..d4c3b3c 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -1,7 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## 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
diff --git a/lib/mailcap.c b/lib/mailcap.c
index f99d512..88eab36 100644
--- a/lib/mailcap.c
+++ b/lib/mailcap.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2005, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/lib/mu_asprintf.h b/lib/mu_asprintf.h
index e4a5b5e..9a70cec 100644
--- a/lib/mu_asprintf.h
+++ b/lib/mu_asprintf.h
@@ -1,5 +1,5 @@
/*
- Copyright (C) 2007 Free Software Foundation, Inc.
+ Copyright (C) 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 Library General Public License as published by
diff --git a/lib/mu_dbm.c b/lib/mu_dbm.c
index 86237a3..b62818a 100644
--- a/lib/mu_dbm.c
+++ b/lib/mu_dbm.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2006, 2007, 2009
- Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 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 published by
diff --git a/lib/mu_dbm.h b/lib/mu_dbm.h
index 98f36ec..87c3487 100644
--- a/lib/mu_dbm.h
+++ b/lib/mu_dbm.h
@@ -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/lib/mu_umaxtostr.c b/lib/mu_umaxtostr.c
index aa051bf..c3e9e91 100644
--- a/lib/mu_umaxtostr.c
+++ b/lib/mu_umaxtostr.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2005, 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/lib/muaux.h b/lib/muaux.h
index cf9c83f..4e27a55 100644
--- a/lib/muaux.h
+++ b/lib/muaux.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2008 Free Software Foundation, Inc.
+ Copyright (C) 2008, 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/lib/signal.c b/lib/signal.c
index 54b0d3d..8f5b615 100644
--- a/lib/signal.c
+++ b/lib/signal.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2008 Free Software Foundation, Inc.
+ Copyright (C) 2008, 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/lib/strexit.c b/lib/strexit.c
index d913a39..7f1d01c 100644
--- a/lib/strexit.c
+++ b/lib/strexit.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2008 Free Software Foundation, Inc.
+ Copyright (C) 2008, 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/lib/tcpwrap.c b/lib/tcpwrap.c
index a6504ad..21e6310 100644
--- a/lib/tcpwrap.c
+++ b/lib/tcpwrap.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2004,
- 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 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 published by
diff --git a/lib/tcpwrap.h b/lib/tcpwrap.h
index 369727f..af2d188 100644
--- a/lib/tcpwrap.h
+++ b/lib/tcpwrap.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2004,
- 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008,
+ 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/lib/userprivs.c b/lib/userprivs.c
index 5595682..0a51dd9 100644
--- a/lib/userprivs.c
+++ b/lib/userprivs.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2008 Free Software Foundation, Inc.
+ Copyright (C) 2008, 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/lib/utmp.c b/lib/utmp.c
index 5e76ea7..a9e00be 100644
--- a/lib/utmp.c
+++ b/lib/utmp.c
@@ -1,6 +1,6 @@
/* utmp.c -- Replacements for {set,get,end}utmp functions
-Copyright (C) 2002, 2009 Free Software Foundation, Inc.
+Copyright (C) 2002, 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
diff --git a/libmu_argp/Makefile.am b/libmu_argp/Makefile.am
index 03635aa..3106f5c 100644
--- a/libmu_argp/Makefile.am
+++ b/libmu_argp/Makefile.am
@@ -1,5 +1,5 @@
# This file is part of GNU Mailutils
-# Copyright (C) 2007, 2009 Free Software Foundation, Inc.
+# Copyright (C) 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/libmu_argp/auth.c b/libmu_argp/auth.c
index e21ba1e..b142dcf 100644
--- a/libmu_argp/auth.c
+++ b/libmu_argp/auth.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2009, 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/libmu_argp/cmdline.c b/libmu_argp/cmdline.c
index 7504776..b6cac65 100644
--- a/libmu_argp/cmdline.c
+++ b/libmu_argp/cmdline.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2008, 2009, 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/libmu_argp/cmdline.h b/libmu_argp/cmdline.h
index bfaf74b..fecb043 100644
--- a/libmu_argp/cmdline.h
+++ b/libmu_argp/cmdline.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007 Free Software Foundation, Inc.
+ Copyright (C) 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/libmu_argp/common.c b/libmu_argp/common.c
index aff478c..fca1c17 100644
--- a/libmu_argp/common.c
+++ b/libmu_argp/common.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2008, 2009, 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/libmu_argp/compat.c b/libmu_argp/compat.c
index efacd5a..09c9e2d 100644
--- a/libmu_argp/compat.c
+++ b/libmu_argp/compat.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2009, 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/libmu_argp/mu_argp.c b/libmu_argp/mu_argp.c
index 2172e82..75618f6 100644
--- a/libmu_argp/mu_argp.c
+++ b/libmu_argp/mu_argp.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2004, 2005, 2006,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2009,
+ 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/libmu_argp/mu_argp.h b/libmu_argp/mu_argp.h
index 0c20be2..804f46c 100644
--- a/libmu_argp/mu_argp.h
+++ b/libmu_argp/mu_argp.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2007, 2009, 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/libmu_argp/muinit.c b/libmu_argp/muinit.c
index 6607b07..3853f0f 100644
--- a/libmu_argp/muinit.c
+++ b/libmu_argp/muinit.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2008, 2009, 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/libmu_argp/sieve.c b/libmu_argp/sieve.c
index 17841e0..066fa4c 100644
--- a/libmu_argp/sieve.c
+++ b/libmu_argp/sieve.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.
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/libmu_argp/tls.c b/libmu_argp/tls.c
index a5f0cbe..4688fc8 100644
--- a/libmu_argp/tls.c
+++ b/libmu_argp/tls.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2009, 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/libmu_auth/Makefile.am b/libmu_auth/Makefile.am
index 00a0918..0f97e55 100644
--- a/libmu_auth/Makefile.am
+++ b/libmu_auth/Makefile.am
@@ -1,6 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2002, 2003, 2005, 2006 Free Software Foundation, Inc.
+## Copyright (C) 2002, 2003, 2005, 2006, 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/libmu_auth/gsasl.c b/libmu_auth/gsasl.c
index 91a9fc7..230a275 100644
--- a/libmu_auth/gsasl.c
+++ b/libmu_auth/gsasl.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2004, 2005, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2004, 2005, 2008, 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/libmu_auth/lbuf.c b/libmu_auth/lbuf.c
index 4d38679..ac80284 100644
--- a/libmu_auth/lbuf.c
+++ b/libmu_auth/lbuf.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/libmu_auth/lbuf.h b/libmu_auth/lbuf.h
index e13614b..2b7c060 100644
--- a/libmu_auth/lbuf.h
+++ b/libmu_auth/lbuf.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2005, 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/libmu_auth/ldap.c b/libmu_auth/ldap.c
index 772701d..70d3e0f 100644
--- a/libmu_auth/ldap.c
+++ b/libmu_auth/ldap.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2005, 2007, 2008, 2009, 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/libmu_auth/pam.c b/libmu_auth/pam.c
index e6a3332..ff66c43 100644
--- a/libmu_auth/pam.c
+++ b/libmu_auth/pam.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2002, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2002, 2007, 2008, 2009, 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/libmu_auth/radius.c b/libmu_auth/radius.c
index 96a34de..b848b42 100644
--- a/libmu_auth/radius.c
+++ b/libmu_auth/radius.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2005, 2007, 2008, 2009, 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/libmu_auth/sql.c b/libmu_auth/sql.c
index fe2188b..87e3f60 100644
--- a/libmu_auth/sql.c
+++ b/libmu_auth/sql.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- 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.
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/libmu_auth/sql.h b/libmu_auth/sql.h
index e6e8bfe..3a6696d 100644
--- a/libmu_auth/sql.h
+++ b/libmu_auth/sql.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2005, 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/libmu_auth/tls.c b/libmu_auth/tls.c
index e4efe64..7a4970d 100644
--- a/libmu_auth/tls.c
+++ b/libmu_auth/tls.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2004, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2004, 2007, 2008, 2009, 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/libmu_auth/virtual.c b/libmu_auth/virtual.c
index 8e1185f..1932ea4 100644
--- a/libmu_auth/virtual.c
+++ b/libmu_auth/virtual.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2002, 2006, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2002, 2006, 2007, 2008, 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/libmu_cfg/Makefile.am b/libmu_cfg/Makefile.am
index ba8b2ce..2baa59f 100644
--- a/libmu_cfg/Makefile.am
+++ b/libmu_cfg/Makefile.am
@@ -1,5 +1,5 @@
# This file is part of GNU Mailutils
-# Copyright (C) 2007, 2009 Free Software Foundation, Inc.
+# Copyright (C) 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/libmu_cfg/acl.c b/libmu_cfg/acl.c
index b1d0866..d9b769c 100644
--- a/libmu_cfg/acl.c
+++ b/libmu_cfg/acl.c
@@ -1,5 +1,5 @@
/* This file is part of GNU Mailutils
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/libmu_cfg/auth.c b/libmu_cfg/auth.c
index e628f25..dde04f6 100644
--- a/libmu_cfg/auth.c
+++ b/libmu_cfg/auth.c
@@ -1,5 +1,5 @@
/* This file is part of GNU Mailutils
- Copyright (C) 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2008, 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/libmu_cfg/common.c b/libmu_cfg/common.c
index f794596..17c39c4 100644
--- a/libmu_cfg/common.c
+++ b/libmu_cfg/common.c
@@ -1,5 +1,5 @@
/* This file is part of GNU Mailutils
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/libmu_cfg/gsasl.c b/libmu_cfg/gsasl.c
index f39576d..cd37d46 100644
--- a/libmu_cfg/gsasl.c
+++ b/libmu_cfg/gsasl.c
@@ -1,5 +1,5 @@
/* This file is part of GNU Mailutils
- Copyright (C) 2007 Free Software Foundation, Inc.
+ Copyright (C) 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/libmu_cfg/init.c b/libmu_cfg/init.c
index 8fddb14..d9f84d6 100644
--- a/libmu_cfg/init.c
+++ b/libmu_cfg/init.c
@@ -1,5 +1,5 @@
/* This file is part of GNU Mailutils
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/libmu_cfg/ldap.c b/libmu_cfg/ldap.c
index cf3a1a8..ea59a49 100644
--- a/libmu_cfg/ldap.c
+++ b/libmu_cfg/ldap.c
@@ -1,5 +1,5 @@
/* This file is part of GNU Mailutils
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/libmu_cfg/pam.c b/libmu_cfg/pam.c
index 5848b67..502e306 100644
--- a/libmu_cfg/pam.c
+++ b/libmu_cfg/pam.c
@@ -1,5 +1,5 @@
/* This file is part of GNU Mailutils
- Copyright (C) 2007 Free Software Foundation, Inc.
+ Copyright (C) 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/libmu_cfg/radius.c b/libmu_cfg/radius.c
index 15778fb..62f6960 100644
--- a/libmu_cfg/radius.c
+++ b/libmu_cfg/radius.c
@@ -1,5 +1,5 @@
/* This file is part of GNU Mailutils
- Copyright (C) 2007 Free Software Foundation, Inc.
+ Copyright (C) 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/libmu_cfg/sieve.c b/libmu_cfg/sieve.c
index 58aed81..595fb13 100644
--- a/libmu_cfg/sieve.c
+++ b/libmu_cfg/sieve.c
@@ -1,5 +1,5 @@
/* This file is part of GNU Mailutils
- Copyright (C) 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2008, 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/libmu_cfg/sql.c b/libmu_cfg/sql.c
index 65ad579..360448d 100644
--- a/libmu_cfg/sql.c
+++ b/libmu_cfg/sql.c
@@ -1,5 +1,5 @@
/* This file is part of GNU Mailutils
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/libmu_cfg/tls.c b/libmu_cfg/tls.c
index 05bdfb8..3e7cf38 100644
--- a/libmu_cfg/tls.c
+++ b/libmu_cfg/tls.c
@@ -1,5 +1,5 @@
/* This file is part of GNU Mailutils
- Copyright (C) 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2008, 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/libmu_cfg/virtdomain.c b/libmu_cfg/virtdomain.c
index 5d63a3a..7c3217d 100644
--- a/libmu_cfg/virtdomain.c
+++ b/libmu_cfg/virtdomain.c
@@ -1,5 +1,5 @@
/* This file is part of GNU Mailutils
- Copyright (C) 2007 Free Software Foundation, Inc.
+ Copyright (C) 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/libmu_cpp/Makefile.am b/libmu_cpp/Makefile.am
index 95dc1d6..e6154de 100644
--- a/libmu_cpp/Makefile.am
+++ b/libmu_cpp/Makefile.am
@@ -1,6 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
##
-## Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+## Copyright (C) 2004, 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/libmu_cpp/address.cc b/libmu_cpp/address.cc
index 0d92de6..7ed7dff 100644
--- a/libmu_cpp/address.cc
+++ b/libmu_cpp/address.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/libmu_cpp/attribute.cc b/libmu_cpp/attribute.cc
index 3771158..247c117 100644
--- a/libmu_cpp/attribute.cc
+++ b/libmu_cpp/attribute.cc
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/libmu_cpp/body.cc b/libmu_cpp/body.cc
index 8d8667d..93370a2 100644
--- a/libmu_cpp/body.cc
+++ b/libmu_cpp/body.cc
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/libmu_cpp/debug.cc b/libmu_cpp/debug.cc
index 99483b8..4042137 100644
--- a/libmu_cpp/debug.cc
+++ b/libmu_cpp/debug.cc
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/libmu_cpp/envelope.cc b/libmu_cpp/envelope.cc
index 793ff6e..e1fff64 100644
--- a/libmu_cpp/envelope.cc
+++ b/libmu_cpp/envelope.cc
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/libmu_cpp/filter.cc b/libmu_cpp/filter.cc
index 124a01e..cf53e1b 100644
--- a/libmu_cpp/filter.cc
+++ b/libmu_cpp/filter.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/libmu_cpp/folder.cc b/libmu_cpp/folder.cc
index 8d3155c..aa53941 100644
--- a/libmu_cpp/folder.cc
+++ b/libmu_cpp/folder.cc
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/libmu_cpp/header.cc b/libmu_cpp/header.cc
index e8793e1..cc44067 100644
--- a/libmu_cpp/header.cc
+++ b/libmu_cpp/header.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/libmu_cpp/iterator.cc b/libmu_cpp/iterator.cc
index 75861a2..b0aa161 100644
--- a/libmu_cpp/iterator.cc
+++ b/libmu_cpp/iterator.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/libmu_cpp/list.cc b/libmu_cpp/list.cc
index 4400323..dc29b58 100644
--- a/libmu_cpp/list.cc
+++ b/libmu_cpp/list.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/libmu_cpp/mailbox.cc b/libmu_cpp/mailbox.cc
index dc0bbb5..b0e2d56 100644
--- a/libmu_cpp/mailbox.cc
+++ b/libmu_cpp/mailbox.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/libmu_cpp/mailcap.cc b/libmu_cpp/mailcap.cc
index 07ff5e0..14cb01c 100644
--- a/libmu_cpp/mailcap.cc
+++ b/libmu_cpp/mailcap.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/libmu_cpp/mailer.cc b/libmu_cpp/mailer.cc
index 02ca320..8090fd4 100644
--- a/libmu_cpp/mailer.cc
+++ b/libmu_cpp/mailer.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/libmu_cpp/message.cc b/libmu_cpp/message.cc
index 32b9aba..55fdd38 100644
--- a/libmu_cpp/message.cc
+++ b/libmu_cpp/message.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/libmu_cpp/mime.cc b/libmu_cpp/mime.cc
index d5519e0..483c211 100644
--- a/libmu_cpp/mime.cc
+++ b/libmu_cpp/mime.cc
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/libmu_cpp/mutil.cc b/libmu_cpp/mutil.cc
index 724c399..e4ecceb 100644
--- a/libmu_cpp/mutil.cc
+++ b/libmu_cpp/mutil.cc
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/libmu_cpp/pop3.cc b/libmu_cpp/pop3.cc
index e65ef8e..7979669 100644
--- a/libmu_cpp/pop3.cc
+++ b/libmu_cpp/pop3.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/libmu_cpp/registrar.cc b/libmu_cpp/registrar.cc
index a502d05..26057bb 100644
--- a/libmu_cpp/registrar.cc
+++ b/libmu_cpp/registrar.cc
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/libmu_cpp/secret.cc b/libmu_cpp/secret.cc
index 028e609..4b5582e 100644
--- a/libmu_cpp/secret.cc
+++ b/libmu_cpp/secret.cc
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/libmu_cpp/sieve.cc b/libmu_cpp/sieve.cc
index 8a7bcdf..c3be1b4 100644
--- a/libmu_cpp/sieve.cc
+++ b/libmu_cpp/sieve.cc
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/libmu_cpp/stream.cc b/libmu_cpp/stream.cc
index 7fdcb46..d417007 100644
--- a/libmu_cpp/stream.cc
+++ b/libmu_cpp/stream.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2009, 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/libmu_cpp/url.cc b/libmu_cpp/url.cc
index 7a78415..1ae8c00 100644
--- a/libmu_cpp/url.cc
+++ b/libmu_cpp/url.cc
@@ -1,6 +1,7 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006, 2007, 2008, 2009, 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/libmu_scm/Makefile.am b/libmu_scm/Makefile.am
index 2c4c5ed..92588ed 100644
--- a/libmu_scm/Makefile.am
+++ b/libmu_scm/Makefile.am
@@ -1,7 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2001, 2002, 2006, 2007,
-## 2009 Free Software Foundation, Inc.
+## Copyright (C) 2001, 2002, 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/libmu_scm/mailutils.scm.in b/libmu_scm/mailutils.scm.in
index 187fd92..66d773e 100644
--- a/libmu_scm/mailutils.scm.in
+++ b/libmu_scm/mailutils.scm.in
@@ -1,6 +1,7 @@
;;;; -*- scheme -*-
;;;; GNU Mailutils -- a suite of utilities for electronic mail
-;;;; Copyright (C) 2002,2003,2004,2006,2007,2009 Free Software Foundation, Inc.
+;;;; Copyright (C) 2002, 2003, 2004, 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 published by
diff --git a/libmu_scm/mu_address.c b/libmu_scm/mu_address.c
index 7689943..4d193b3 100644
--- a/libmu_scm/mu_address.c
+++ b/libmu_scm/mu_address.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2006,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2006, 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/libmu_scm/mu_body.c b/libmu_scm/mu_body.c
index 1bb2d85..435e2c2 100644
--- a/libmu_scm/mu_body.c
+++ b/libmu_scm/mu_body.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2006,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2006, 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/libmu_scm/mu_dbgport.c b/libmu_scm/mu_dbgport.c
index 54343b6..f118cb4 100644
--- a/libmu_scm/mu_dbgport.c
+++ b/libmu_scm/mu_dbgport.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/libmu_scm/mu_guile.c b/libmu_scm/mu_guile.c
index b1162ce..c2fb89c 100644
--- a/libmu_scm/mu_guile.c
+++ b/libmu_scm/mu_guile.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/libmu_scm/mu_logger.c b/libmu_scm/mu_logger.c
index 37947f0..8b474d8 100644
--- a/libmu_scm/mu_logger.c
+++ b/libmu_scm/mu_logger.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2006, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2006, 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/libmu_scm/mu_mailbox.c b/libmu_scm/mu_mailbox.c
index e0a3e47..82dd745 100644
--- a/libmu_scm/mu_mailbox.c
+++ b/libmu_scm/mu_mailbox.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2006, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2006, 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/libmu_scm/mu_message.c b/libmu_scm/mu_message.c
index b74ce16..220e4ad 100644
--- a/libmu_scm/mu_message.c
+++ b/libmu_scm/mu_message.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2006, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2006, 2007, 2009, 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/libmu_scm/mu_mime.c b/libmu_scm/mu_mime.c
index 764bb1d..de889ed 100644
--- a/libmu_scm/mu_mime.c
+++ b/libmu_scm/mu_mime.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2006, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2006, 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/libmu_scm/mu_port.c b/libmu_scm/mu_port.c
index a87cf9e..25a565f 100644
--- a/libmu_scm/mu_port.c
+++ b/libmu_scm/mu_port.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2006, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2006, 2007, 2009, 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/libmu_scm/mu_scm.c b/libmu_scm/mu_scm.c
index 3fbc52a..488ac81 100644
--- a/libmu_scm/mu_scm.c
+++ b/libmu_scm/mu_scm.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2006, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2006, 2007, 2009, 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/libmu_scm/mu_scm.h b/libmu_scm/mu_scm.h
index a7e5caf..1f5f70b 100644
--- a/libmu_scm/mu_scm.h
+++ b/libmu_scm/mu_scm.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2006, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2006, 2007, 2009, 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/libmu_scm/mu_util.c b/libmu_scm/mu_util.c
index b21dc20..4482ac8 100644
--- a/libmu_scm/mu_util.c
+++ b/libmu_scm/mu_util.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2006, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2006, 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/libmu_sieve/Makefile.am b/libmu_sieve/Makefile.am
index 949e325..1dc3027 100644
--- a/libmu_sieve/Makefile.am
+++ b/libmu_sieve/Makefile.am
@@ -1,7 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2002, 2003, 2004, 2005, 2007, 2009
-## Free Software Foundation, Inc.
+## Copyright (C) 2002, 2003, 2004, 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
diff --git a/libmu_sieve/actions.c b/libmu_sieve/actions.c
index bce1a7e..fc9fb3d 100644
--- a/libmu_sieve/actions.c
+++ b/libmu_sieve/actions.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2005,
- 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2005, 2006, 2007, 2008, 2009,
+ 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/libmu_sieve/comparator.c b/libmu_sieve/comparator.c
index 92de9af..50fb672 100644
--- a/libmu_sieve/comparator.c
+++ b/libmu_sieve/comparator.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2004,
- 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2004, 2005, 2007, 2008, 2009,
+ 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/libmu_sieve/conf.c b/libmu_sieve/conf.c
index cd6f2b0..f2c0170 100644
--- a/libmu_sieve/conf.c
+++ b/libmu_sieve/conf.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2005,
- 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2005, 2007, 2008, 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/libmu_sieve/extensions/Makefile.am
b/libmu_sieve/extensions/Makefile.am
index 93ca319..cdbdcee 100644
--- a/libmu_sieve/extensions/Makefile.am
+++ b/libmu_sieve/extensions/Makefile.am
@@ -1,7 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2004, 2005, 2006, 2007, 2009
-## Free Software Foundation, Inc.
+## Copyright (C) 2004, 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/libmu_sieve/extensions/list.c b/libmu_sieve/extensions/list.c
index c10cf79..184caad 100644
--- a/libmu_sieve/extensions/list.c
+++ b/libmu_sieve/extensions/list.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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 Lesser General Public License as published by
diff --git a/libmu_sieve/extensions/moderator.c
b/libmu_sieve/extensions/moderator.c
index acbf0e5..9e0aecb 100644
--- a/libmu_sieve/extensions/moderator.c
+++ b/libmu_sieve/extensions/moderator.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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 Lesser General Public License as published by
diff --git a/libmu_sieve/extensions/pipe.c b/libmu_sieve/extensions/pipe.c
index f20995a..fd61a2d 100644
--- a/libmu_sieve/extensions/pipe.c
+++ b/libmu_sieve/extensions/pipe.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2009, 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/libmu_sieve/extensions/spamd.c b/libmu_sieve/extensions/spamd.c
index af3e594..0ee0a4c 100644
--- a/libmu_sieve/extensions/spamd.c
+++ b/libmu_sieve/extensions/spamd.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2004, 2005, 2007, 2008,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2004, 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 Lesser General Public License as published by
diff --git a/libmu_sieve/extensions/timestamp.c
b/libmu_sieve/extensions/timestamp.c
index 58ba2fb..7cbcda8 100644
--- a/libmu_sieve/extensions/timestamp.c
+++ b/libmu_sieve/extensions/timestamp.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2005, 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 Lesser General Public License as published by
diff --git a/libmu_sieve/extensions/vacation.c
b/libmu_sieve/extensions/vacation.c
index ab0a7c9..a2debf5 100644
--- a/libmu_sieve/extensions/vacation.c
+++ b/libmu_sieve/extensions/vacation.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2005, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2005, 2007, 2009, 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/libmu_sieve/load.c b/libmu_sieve/load.c
index 650c7ae..8c7f121 100644
--- a/libmu_sieve/load.c
+++ b/libmu_sieve/load.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.
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/libmu_sieve/prog.c b/libmu_sieve/prog.c
index 99f68d8..bafdcfa 100644
--- a/libmu_sieve/prog.c
+++ b/libmu_sieve/prog.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2004,
- 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2004, 2005, 2006, 2007, 2008,
+ 2009, 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/libmu_sieve/register.c b/libmu_sieve/register.c
index 560512c..251a088 100644
--- a/libmu_sieve/register.c
+++ b/libmu_sieve/register.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2004,
- 2005, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2004, 2005, 2007, 2008, 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/libmu_sieve/relational.c b/libmu_sieve/relational.c
index 7375792..8f1c06c 100644
--- a/libmu_sieve/relational.c
+++ b/libmu_sieve/relational.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2005, 2007, 2008, 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/libmu_sieve/require.c b/libmu_sieve/require.c
index be9ddea..21e072e 100644
--- a/libmu_sieve/require.c
+++ b/libmu_sieve/require.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2004,
- 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2004, 2005, 2006, 2007, 2008,
+ 2009, 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/libmu_sieve/runtime.c b/libmu_sieve/runtime.c
index ceb97c0..c2cb658 100644
--- a/libmu_sieve/runtime.c
+++ b/libmu_sieve/runtime.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.
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/libmu_sieve/sieve-priv.h b/libmu_sieve/sieve-priv.h
index ae99bb1..0bea174 100644
--- a/libmu_sieve/sieve-priv.h
+++ b/libmu_sieve/sieve-priv.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2005, 2006,
- 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2005, 2006, 2007, 2008, 2009,
+ 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/libmu_sieve/sieve.l b/libmu_sieve/sieve.l
index 17835da..ffaaef3 100644
--- a/libmu_sieve/sieve.l
+++ b/libmu_sieve/sieve.l
@@ -1,7 +1,7 @@
%top {
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2004, 2005,
- 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2004, 2005, 2007, 2008, 2009,
+ 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/libmu_sieve/sieve.y b/libmu_sieve/sieve.y
index dd1334f..c3ca2dc 100644
--- a/libmu_sieve/sieve.y
+++ b/libmu_sieve/sieve.y
@@ -1,7 +1,7 @@
%{
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2005,
- 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2005, 2006, 2007, 2008, 2009,
+ 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/libmu_sieve/tests.c b/libmu_sieve/tests.c
index fd0f824..bbcbb6c 100644
--- a/libmu_sieve/tests.c
+++ b/libmu_sieve/tests.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2004, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2007, 2008,
+ 2009, 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/libmu_sieve/util.c b/libmu_sieve/util.c
index 4daf049..327cb52 100644
--- a/libmu_sieve/util.c
+++ b/libmu_sieve/util.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2005,
- 2006, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2005, 2006, 2007, 2008, 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/libproto/Makefile.am b/libproto/Makefile.am
index 2cc7634..314cfb7 100644
--- a/libproto/Makefile.am
+++ b/libproto/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2006, 2007, 2009 Free Software Foundation, Inc.
+## Copyright (C) 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/libproto/imap/Makefile.am b/libproto/imap/Makefile.am
index 5ae5ab7..1acdfd4 100644
--- a/libproto/imap/Makefile.am
+++ b/libproto/imap/Makefile.am
@@ -1,6 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2003, 2005, 2006, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2003, 2005, 2006, 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/libproto/imap/folder.c b/libproto/imap/folder.c
index c38b364..215cfc7 100644
--- a/libproto/imap/folder.c
+++ b/libproto/imap/folder.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2003, 2004,
- 2005, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 2004, 2005, 2006, 2007, 2009,
+ 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/libproto/imap/mbox.c b/libproto/imap/mbox.c
index 5c561d6..d31957a 100644
--- a/libproto/imap/mbox.c
+++ b/libproto/imap/mbox.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2003, 2004,
- 2005, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 2004, 2005, 2006, 2007, 2009,
+ 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/libproto/imap/url.c b/libproto/imap/url.c
index a348eeb..5fa06f5 100644
--- a/libproto/imap/url.c
+++ b/libproto/imap/url.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2003, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 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/libproto/include/Makefile.am b/libproto/include/Makefile.am
index b2be394..0b59a44 100644
--- a/libproto/include/Makefile.am
+++ b/libproto/include/Makefile.am
@@ -1,7 +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
diff --git a/libproto/include/amd.h b/libproto/include/amd.h
index 6f4a866..f643453 100644
--- a/libproto/include/amd.h
+++ b/libproto/include/amd.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2007, 2008,
+ 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/libproto/include/attribute0.h b/libproto/include/attribute0.h
index 1eb417d..f379f7f 100644
--- a/libproto/include/attribute0.h
+++ b/libproto/include/attribute0.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2005, 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/libproto/include/auth0.h b/libproto/include/auth0.h
index a2db8ca..7868bad 100644
--- a/libproto/include/auth0.h
+++ b/libproto/include/auth0.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2007, 2009, 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/libproto/include/body0.h b/libproto/include/body0.h
index 2a38030..156793c 100644
--- a/libproto/include/body0.h
+++ b/libproto/include/body0.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/libproto/include/debug0.h b/libproto/include/debug0.h
index e3e17bd..1b4fc46 100644
--- a/libproto/include/debug0.h
+++ b/libproto/include/debug0.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2005, 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/libproto/include/envelope0.h b/libproto/include/envelope0.h
index 0de9a9c..5e1cae4 100644
--- a/libproto/include/envelope0.h
+++ b/libproto/include/envelope0.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2005, 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/libproto/include/filter0.h b/libproto/include/filter0.h
index bd1f334..6de572b 100644
--- a/libproto/include/filter0.h
+++ b/libproto/include/filter0.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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/libproto/include/folder0.h b/libproto/include/folder0.h
index 66357dc..060e6a3 100644
--- a/libproto/include/folder0.h
+++ b/libproto/include/folder0.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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/libproto/include/header0.h b/libproto/include/header0.h
index 31e1b1e..c4a8a68 100644
--- a/libproto/include/header0.h
+++ b/libproto/include/header0.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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/libproto/include/imap0.h b/libproto/include/imap0.h
index a19d9c1..0b4ff33 100644
--- a/libproto/include/imap0.h
+++ b/libproto/include/imap0.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2007, 2009, 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/libproto/include/iterator0.h b/libproto/include/iterator0.h
index 318f60a..f84c45b 100644
--- a/libproto/include/iterator0.h
+++ b/libproto/include/iterator0.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2004, 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/libproto/include/list0.h b/libproto/include/list0.h
index 9c9a073..697f750 100644
--- a/libproto/include/list0.h
+++ b/libproto/include/list0.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2005, 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/libproto/include/mailbox0.h b/libproto/include/mailbox0.h
index 8ff1672..bbe25f1 100644
--- a/libproto/include/mailbox0.h
+++ b/libproto/include/mailbox0.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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/libproto/include/mailer0.h b/libproto/include/mailer0.h
index 49d1414..949bb15 100644
--- a/libproto/include/mailer0.h
+++ b/libproto/include/mailer0.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2007, 2009, 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/libproto/include/message0.h b/libproto/include/message0.h
index 8425248..cdaccc2 100644
--- a/libproto/include/message0.h
+++ b/libproto/include/message0.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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/libproto/include/mime0.h b/libproto/include/mime0.h
index c3ba0b8..145db33 100644
--- a/libproto/include/mime0.h
+++ b/libproto/include/mime0.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2005, 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/libproto/include/monitor0.h b/libproto/include/monitor0.h
index 079bf8a..3541e15 100644
--- a/libproto/include/monitor0.h
+++ b/libproto/include/monitor0.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 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/libproto/include/observer0.h b/libproto/include/observer0.h
index 51bd29a..164ac26 100644
--- a/libproto/include/observer0.h
+++ b/libproto/include/observer0.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2005, 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/libproto/include/property0.h b/libproto/include/property0.h
index e5bc0e5..25d1d2f 100644
--- a/libproto/include/property0.h
+++ b/libproto/include/property0.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2007, 2008, 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/libproto/include/registrar0.h b/libproto/include/registrar0.h
index 89abb6f..13e15f6 100644
--- a/libproto/include/registrar0.h
+++ b/libproto/include/registrar0.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2004, 2005, 2007, 2008,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2004, 2005, 2007, 2008, 2009, 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/libproto/include/stream0.h b/libproto/include/stream0.h
index 8d4a17a..ff8021b 100644
--- a/libproto/include/stream0.h
+++ b/libproto/include/stream0.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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/libproto/include/url0.h b/libproto/include/url0.h
index f5de62d..1cedd31 100644
--- a/libproto/include/url0.h
+++ b/libproto/include/url0.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2005, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2005, 2007, 2009, 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/libproto/maildir/Makefile.am b/libproto/maildir/Makefile.am
index d7d11ce..4e0da11 100644
--- a/libproto/maildir/Makefile.am
+++ b/libproto/maildir/Makefile.am
@@ -1,6 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2003, 2005, 2006, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2003, 2005, 2006, 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/libproto/maildir/folder.c b/libproto/maildir/folder.c
index 61ceba4..38a9d72 100644
--- a/libproto/maildir/folder.c
+++ b/libproto/maildir/folder.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 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/libproto/maildir/maildir.h b/libproto/maildir/maildir.h
index b10ff12..14a95e4 100644
--- a/libproto/maildir/maildir.h
+++ b/libproto/maildir/maildir.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 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/libproto/maildir/mbox.c b/libproto/maildir/mbox.c
index de2ed03..c9d7470 100644
--- a/libproto/maildir/mbox.c
+++ b/libproto/maildir/mbox.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2007, 2008,
+ 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/libproto/mailer/Makefile.am b/libproto/mailer/Makefile.am
index 71d0550..bb272e0 100644
--- a/libproto/mailer/Makefile.am
+++ b/libproto/mailer/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+## Copyright (C) 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/libproto/mailer/mbox.c b/libproto/mailer/mbox.c
index 8e09df3..367492c 100644
--- a/libproto/mailer/mbox.c
+++ b/libproto/mailer/mbox.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2009, 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/libproto/mailer/prog.c b/libproto/mailer/prog.c
index 67b4271..83b371a 100644
--- a/libproto/mailer/prog.c
+++ b/libproto/mailer/prog.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2008, 2009, 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/libproto/mailer/remote.c b/libproto/mailer/remote.c
index b6fa83a..a9d08be 100644
--- a/libproto/mailer/remote.c
+++ b/libproto/mailer/remote.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/libproto/mailer/sendmail.c b/libproto/mailer/sendmail.c
index 0e112da..651603e 100644
--- a/libproto/mailer/sendmail.c
+++ b/libproto/mailer/sendmail.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2006, 2007, 2008, 2009,
+ 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/libproto/mailer/smtp.c b/libproto/mailer/smtp.c
index 1573a65..07b9db3 100644
--- a/libproto/mailer/smtp.c
+++ b/libproto/mailer/smtp.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2006, 2007, 2009, 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/libproto/mbox/Makefile.am b/libproto/mbox/Makefile.am
index c180024..935659a 100644
--- a/libproto/mbox/Makefile.am
+++ b/libproto/mbox/Makefile.am
@@ -1,6 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2003, 2005, 2006, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2003, 2005, 2006, 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/libproto/mbox/folder.c b/libproto/mbox/folder.c
index ffa8a5b..3557a88 100644
--- a/libproto/mbox/folder.c
+++ b/libproto/mbox/folder.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2003, 2004,
- 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 2004, 2005, 2006, 2007, 2008,
+ 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/libproto/mbox/mbox.c b/libproto/mbox/mbox.c
index 12a2558..d073c02 100644
--- a/libproto/mbox/mbox.c
+++ b/libproto/mbox/mbox.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2003,
- 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 2004, 2005, 2006, 2007, 2008,
+ 2009, 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/libproto/mbox/mbox0.h b/libproto/mbox/mbox0.h
index 5f45877..e9304b6 100644
--- a/libproto/mbox/mbox0.h
+++ b/libproto/mbox/mbox0.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2005, 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/libproto/mbox/mboxscan.c b/libproto/mbox/mboxscan.c
index 3a81af6..44eacfe 100644
--- a/libproto/mbox/mboxscan.c
+++ b/libproto/mbox/mboxscan.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2003, 2005,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 2005, 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/libproto/mh/Makefile.am b/libproto/mh/Makefile.am
index 6896d13..7eadc92 100644
--- a/libproto/mh/Makefile.am
+++ b/libproto/mh/Makefile.am
@@ -1,6 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2003, 2005, 2006, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2003, 2005, 2006, 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/libproto/mh/folder.c b/libproto/mh/folder.c
index 5a40b4a..80251b2 100644
--- a/libproto/mh/folder.c
+++ b/libproto/mh/folder.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2003, 2004, 2005,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2003, 2004, 2005, 2007, 2009, 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/libproto/mh/mbox.c b/libproto/mh/mbox.c
index 8c5df9d..da7da4d 100644
--- a/libproto/mh/mbox.c
+++ b/libproto/mh/mbox.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2004, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2007, 2008,
+ 2009, 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/libproto/nntp/Makefile.am b/libproto/nntp/Makefile.am
index c94cf5c..6f1c2fa 100644
--- a/libproto/nntp/Makefile.am
+++ b/libproto/nntp/Makefile.am
@@ -1,6 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2004, 2005, 2006, 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/libproto/nntp/folder.c b/libproto/nntp/folder.c
index 55d69ed..c6378c6 100644
--- a/libproto/nntp/folder.c
+++ b/libproto/nntp/folder.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 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/libproto/nntp/mbox.c b/libproto/nntp/mbox.c
index 02959b0..3e58ada 100644
--- a/libproto/nntp/mbox.c
+++ b/libproto/nntp/mbox.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 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/libproto/nntp/nntp0.h b/libproto/nntp/nntp0.h
index 582e4bc..5610b24 100644
--- a/libproto/nntp/nntp0.h
+++ b/libproto/nntp/nntp0.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 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/libproto/nntp/nntp_article.c b/libproto/nntp/nntp_article.c
index 49a13c3..2987c10 100644
--- a/libproto/nntp/nntp_article.c
+++ b/libproto/nntp/nntp_article.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 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/libproto/nntp/nntp_body.c b/libproto/nntp/nntp_body.c
index d85d841..f06d034 100644
--- a/libproto/nntp/nntp_body.c
+++ b/libproto/nntp/nntp_body.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 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/libproto/nntp/nntp_carrier.c b/libproto/nntp/nntp_carrier.c
index 1ea749e..bfb8b67 100644
--- a/libproto/nntp/nntp_carrier.c
+++ b/libproto/nntp/nntp_carrier.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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/libproto/nntp/nntp_connect.c b/libproto/nntp/nntp_connect.c
index bccda6d..d6b9741 100644
--- a/libproto/nntp/nntp_connect.c
+++ b/libproto/nntp/nntp_connect.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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/libproto/nntp/nntp_create.c b/libproto/nntp/nntp_create.c
index aadfe5b..005256c 100644
--- a/libproto/nntp/nntp_create.c
+++ b/libproto/nntp/nntp_create.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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/libproto/nntp/nntp_date.c b/libproto/nntp/nntp_date.c
index c77a9ea..e80459c 100644
--- a/libproto/nntp/nntp_date.c
+++ b/libproto/nntp/nntp_date.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 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/libproto/nntp/nntp_debug.c b/libproto/nntp/nntp_debug.c
index 385eb21..54a8d6f 100644
--- a/libproto/nntp/nntp_debug.c
+++ b/libproto/nntp/nntp_debug.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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/libproto/nntp/nntp_destroy.c b/libproto/nntp/nntp_destroy.c
index 7544067..c2eb897 100644
--- a/libproto/nntp/nntp_destroy.c
+++ b/libproto/nntp/nntp_destroy.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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/libproto/nntp/nntp_disconnect.c b/libproto/nntp/nntp_disconnect.c
index 9b546c6..7b8eabb 100644
--- a/libproto/nntp/nntp_disconnect.c
+++ b/libproto/nntp/nntp_disconnect.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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/libproto/nntp/nntp_group.c b/libproto/nntp/nntp_group.c
index 5a80dce..7518efa 100644
--- a/libproto/nntp/nntp_group.c
+++ b/libproto/nntp/nntp_group.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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/libproto/nntp/nntp_head.c b/libproto/nntp/nntp_head.c
index 5fe6432..6f1783f 100644
--- a/libproto/nntp/nntp_head.c
+++ b/libproto/nntp/nntp_head.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 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/libproto/nntp/nntp_help.c b/libproto/nntp/nntp_help.c
index 7ff7817..9930e75 100644
--- a/libproto/nntp/nntp_help.c
+++ b/libproto/nntp/nntp_help.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 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/libproto/nntp/nntp_ihave.c b/libproto/nntp/nntp_ihave.c
index ae50318..1214784 100644
--- a/libproto/nntp/nntp_ihave.c
+++ b/libproto/nntp/nntp_ihave.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 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/libproto/nntp/nntp_iterator.c b/libproto/nntp/nntp_iterator.c
index 4d24dc9..f147901 100644
--- a/libproto/nntp/nntp_iterator.c
+++ b/libproto/nntp/nntp_iterator.c
@@ -1,5 +1,5 @@
/* GNU mailutils - a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 2007, 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 Library Public License as published by
diff --git a/libproto/nntp/nntp_last.c b/libproto/nntp/nntp_last.c
index 3b77272..e30e0b1 100644
--- a/libproto/nntp/nntp_last.c
+++ b/libproto/nntp/nntp_last.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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/libproto/nntp/nntp_list_active.c b/libproto/nntp/nntp_list_active.c
index 782a56f..c45c11a 100644
--- a/libproto/nntp/nntp_list_active.c
+++ b/libproto/nntp/nntp_list_active.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 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/libproto/nntp/nntp_list_distribpats.c
b/libproto/nntp/nntp_list_distribpats.c
index fcaefc6..511f1ee 100644
--- a/libproto/nntp/nntp_list_distribpats.c
+++ b/libproto/nntp/nntp_list_distribpats.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 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/libproto/nntp/nntp_list_distributions.c
b/libproto/nntp/nntp_list_distributions.c
index 82cbbda..9b990c1 100644
--- a/libproto/nntp/nntp_list_distributions.c
+++ b/libproto/nntp/nntp_list_distributions.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 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/libproto/nntp/nntp_list_extensions.c
b/libproto/nntp/nntp_list_extensions.c
index fee5a2e..d6a18ec 100644
--- a/libproto/nntp/nntp_list_extensions.c
+++ b/libproto/nntp/nntp_list_extensions.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 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/libproto/nntp/nntp_list_newsgroups.c
b/libproto/nntp/nntp_list_newsgroups.c
index 73b6734..5b5da42 100644
--- a/libproto/nntp/nntp_list_newsgroups.c
+++ b/libproto/nntp/nntp_list_newsgroups.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 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/libproto/nntp/nntp_list_times.c b/libproto/nntp/nntp_list_times.c
index 7d1099e..e770d47 100644
--- a/libproto/nntp/nntp_list_times.c
+++ b/libproto/nntp/nntp_list_times.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 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/libproto/nntp/nntp_mode_reader.c b/libproto/nntp/nntp_mode_reader.c
index 639a630..04854c8 100644
--- a/libproto/nntp/nntp_mode_reader.c
+++ b/libproto/nntp/nntp_mode_reader.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 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/libproto/nntp/nntp_newgroups.c b/libproto/nntp/nntp_newgroups.c
index 5a3fc19..b406423 100644
--- a/libproto/nntp/nntp_newgroups.c
+++ b/libproto/nntp/nntp_newgroups.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 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/libproto/nntp/nntp_newnews.c b/libproto/nntp/nntp_newnews.c
index c7c5aac..4175205 100644
--- a/libproto/nntp/nntp_newnews.c
+++ b/libproto/nntp/nntp_newnews.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 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/libproto/nntp/nntp_next.c b/libproto/nntp/nntp_next.c
index 32b1684..510f074 100644
--- a/libproto/nntp/nntp_next.c
+++ b/libproto/nntp/nntp_next.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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/libproto/nntp/nntp_post.c b/libproto/nntp/nntp_post.c
index 77d7a04..3849f3e 100644
--- a/libproto/nntp/nntp_post.c
+++ b/libproto/nntp/nntp_post.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 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/libproto/nntp/nntp_quit.c b/libproto/nntp/nntp_quit.c
index 4469559..802e009 100644
--- a/libproto/nntp/nntp_quit.c
+++ b/libproto/nntp/nntp_quit.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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/libproto/nntp/nntp_readline.c b/libproto/nntp/nntp_readline.c
index 677d624..cac93b0 100644
--- a/libproto/nntp/nntp_readline.c
+++ b/libproto/nntp/nntp_readline.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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/libproto/nntp/nntp_response.c b/libproto/nntp/nntp_response.c
index a927fa5..fea1286 100644
--- a/libproto/nntp/nntp_response.c
+++ b/libproto/nntp/nntp_response.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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/libproto/nntp/nntp_sendline.c b/libproto/nntp/nntp_sendline.c
index 92435a8..86db395 100644
--- a/libproto/nntp/nntp_sendline.c
+++ b/libproto/nntp/nntp_sendline.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 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/libproto/nntp/nntp_stat.c b/libproto/nntp/nntp_stat.c
index 1653311..9b5c6f1 100644
--- a/libproto/nntp/nntp_stat.c
+++ b/libproto/nntp/nntp_stat.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 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/libproto/nntp/nntp_stream.c b/libproto/nntp/nntp_stream.c
index 56cf694..9a6a9c7 100644
--- a/libproto/nntp/nntp_stream.c
+++ b/libproto/nntp/nntp_stream.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2004, 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/libproto/nntp/nntp_timeout.c b/libproto/nntp/nntp_timeout.c
index 0fffddd..3682f58 100644
--- a/libproto/nntp/nntp_timeout.c
+++ b/libproto/nntp/nntp_timeout.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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/libproto/nntp/url.c b/libproto/nntp/url.c
index 5179118..73173dd 100644
--- a/libproto/nntp/url.c
+++ b/libproto/nntp/url.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 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/libproto/pop/Makefile.am b/libproto/pop/Makefile.am
index 55e2086..3a3ad8b 100644
--- a/libproto/pop/Makefile.am
+++ b/libproto/pop/Makefile.am
@@ -1,6 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2003, 2004, 2005, 2006, 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/libproto/pop/folder.c b/libproto/pop/folder.c
index db41d40..9e792b8 100644
--- a/libproto/pop/folder.c
+++ b/libproto/pop/folder.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2003, 2005,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 2005, 2007, 2009, 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/libproto/pop/mbox.c b/libproto/pop/mbox.c
index 38a6b1d..7cbe08c 100644
--- a/libproto/pop/mbox.c
+++ b/libproto/pop/mbox.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999,2000,2001,2003,2005,2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 2005, 2007, 2009, 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/libproto/pop/pop3_apop.c b/libproto/pop/pop3_apop.c
index 1978dc6..454c3e5 100644
--- a/libproto/pop/pop3_apop.c
+++ b/libproto/pop/pop3_apop.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2003, 2005,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 2005, 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/libproto/pop/pop3_capa.c b/libproto/pop/pop3_capa.c
index b78e467..24646ee 100644
--- a/libproto/pop/pop3_capa.c
+++ b/libproto/pop/pop3_capa.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2004, 2005, 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/libproto/pop/pop3_carrier.c b/libproto/pop/pop3_carrier.c
index 107cb6e..5c63574 100644
--- a/libproto/pop/pop3_carrier.c
+++ b/libproto/pop/pop3_carrier.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2004, 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/libproto/pop/pop3_connect.c b/libproto/pop/pop3_connect.c
index b7e7547..f71083c 100644
--- a/libproto/pop/pop3_connect.c
+++ b/libproto/pop/pop3_connect.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2007, 2009, 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/libproto/pop/pop3_create.c b/libproto/pop/pop3_create.c
index 7494d90..c9169ba 100644
--- a/libproto/pop/pop3_create.c
+++ b/libproto/pop/pop3_create.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/libproto/pop/pop3_debug.c b/libproto/pop/pop3_debug.c
index 4fe8975..a196029 100644
--- a/libproto/pop/pop3_debug.c
+++ b/libproto/pop/pop3_debug.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/libproto/pop/pop3_dele.c b/libproto/pop/pop3_dele.c
index a987934..0e866dd 100644
--- a/libproto/pop/pop3_dele.c
+++ b/libproto/pop/pop3_dele.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/libproto/pop/pop3_destroy.c b/libproto/pop/pop3_destroy.c
index 7112ed3..fd3d6c8 100644
--- a/libproto/pop/pop3_destroy.c
+++ b/libproto/pop/pop3_destroy.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/libproto/pop/pop3_disconnect.c b/libproto/pop/pop3_disconnect.c
index 45dc9b4..558ffb6 100644
--- a/libproto/pop/pop3_disconnect.c
+++ b/libproto/pop/pop3_disconnect.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2003, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 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/libproto/pop/pop3_iterator.c b/libproto/pop/pop3_iterator.c
index 9f6064a..edffe75 100644
--- a/libproto/pop/pop3_iterator.c
+++ b/libproto/pop/pop3_iterator.c
@@ -1,5 +1,5 @@
/* GNU mailutils - a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 2007, 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 Library Public License as published by
diff --git a/libproto/pop/pop3_list.c b/libproto/pop/pop3_list.c
index ed708a8..ed50f98 100644
--- a/libproto/pop/pop3_list.c
+++ b/libproto/pop/pop3_list.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2007, 2009, 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/libproto/pop/pop3_lista.c b/libproto/pop/pop3_lista.c
index a92355a..d2f825d 100644
--- a/libproto/pop/pop3_lista.c
+++ b/libproto/pop/pop3_lista.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 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/libproto/pop/pop3_noop.c b/libproto/pop/pop3_noop.c
index 4ff118c..906ca93 100644
--- a/libproto/pop/pop3_noop.c
+++ b/libproto/pop/pop3_noop.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/libproto/pop/pop3_pass.c b/libproto/pop/pop3_pass.c
index aa29389..b6cfa67 100644
--- a/libproto/pop/pop3_pass.c
+++ b/libproto/pop/pop3_pass.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/libproto/pop/pop3_quit.c b/libproto/pop/pop3_quit.c
index c34b453..f17d711 100644
--- a/libproto/pop/pop3_quit.c
+++ b/libproto/pop/pop3_quit.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/libproto/pop/pop3_readline.c b/libproto/pop/pop3_readline.c
index 4ccb081..974ed3d 100644
--- a/libproto/pop/pop3_readline.c
+++ b/libproto/pop/pop3_readline.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/libproto/pop/pop3_response.c b/libproto/pop/pop3_response.c
index 0e9a16e..8ff4144 100644
--- a/libproto/pop/pop3_response.c
+++ b/libproto/pop/pop3_response.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/libproto/pop/pop3_retr.c b/libproto/pop/pop3_retr.c
index d71ed67..7f1d071 100644
--- a/libproto/pop/pop3_retr.c
+++ b/libproto/pop/pop3_retr.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/libproto/pop/pop3_rset.c b/libproto/pop/pop3_rset.c
index 81097bd..9ad5797 100644
--- a/libproto/pop/pop3_rset.c
+++ b/libproto/pop/pop3_rset.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/libproto/pop/pop3_sendline.c b/libproto/pop/pop3_sendline.c
index f7424d5..54c1cac 100644
--- a/libproto/pop/pop3_sendline.c
+++ b/libproto/pop/pop3_sendline.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2005, 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/libproto/pop/pop3_stat.c b/libproto/pop/pop3_stat.c
index 682531b..779d10b 100644
--- a/libproto/pop/pop3_stat.c
+++ b/libproto/pop/pop3_stat.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2007, 2009, 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/libproto/pop/pop3_stls.c b/libproto/pop/pop3_stls.c
index 5e61975..b9984f6 100644
--- a/libproto/pop/pop3_stls.c
+++ b/libproto/pop/pop3_stls.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2003, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 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/libproto/pop/pop3_stream.c b/libproto/pop/pop3_stream.c
index fec3dc3..c1ad6f5 100644
--- a/libproto/pop/pop3_stream.c
+++ b/libproto/pop/pop3_stream.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/libproto/pop/pop3_timeout.c b/libproto/pop/pop3_timeout.c
index de6b9be..32b01f0 100644
--- a/libproto/pop/pop3_timeout.c
+++ b/libproto/pop/pop3_timeout.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/libproto/pop/pop3_top.c b/libproto/pop/pop3_top.c
index 093b5e9..4057bb1 100644
--- a/libproto/pop/pop3_top.c
+++ b/libproto/pop/pop3_top.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 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/libproto/pop/pop3_uidl.c b/libproto/pop/pop3_uidl.c
index fc0ec16..71c3ec3 100644
--- a/libproto/pop/pop3_uidl.c
+++ b/libproto/pop/pop3_uidl.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/libproto/pop/pop3_uidla.c b/libproto/pop/pop3_uidla.c
index 53b2a82..f572e7f 100644
--- a/libproto/pop/pop3_uidla.c
+++ b/libproto/pop/pop3_uidla.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2004, 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/libproto/pop/pop3_user.c b/libproto/pop/pop3_user.c
index 57afe38..334050f 100644
--- a/libproto/pop/pop3_user.c
+++ b/libproto/pop/pop3_user.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/libproto/pop/url.c b/libproto/pop/url.c
index 56faed2..1f112bc 100644
--- a/libproto/pop/url.c
+++ b/libproto/pop/url.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2003, 2007,
- 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 2007, 2008, 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/maidag/Makefile.am b/maidag/Makefile.am
index bacdec8..0b28d93 100644
--- a/maidag/Makefile.am
+++ b/maidag/Makefile.am
@@ -1,4 +1,4 @@
-# Copyright (C) 2007, 2009 Free Software Foundation, Inc.
+# Copyright (C) 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/maidag/deliver.c b/maidag/deliver.c
index 5424f8f..24e2f0c 100644
--- a/maidag/deliver.c
+++ b/maidag/deliver.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/maidag/forward.c b/maidag/forward.c
index 527980d..ccba0db 100644
--- a/maidag/forward.c
+++ b/maidag/forward.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/maidag/guile.c b/maidag/guile.c
index 44b08a6..ca85618 100644
--- a/maidag/guile.c
+++ b/maidag/guile.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/maidag/lmtp.c b/maidag/lmtp.c
index 46b245d..e821451 100644
--- a/maidag/lmtp.c
+++ b/maidag/lmtp.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/maidag/maidag.c b/maidag/maidag.c
index 4b66115..69183ea 100644
--- a/maidag/maidag.c
+++ b/maidag/maidag.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/maidag/maidag.h b/maidag/maidag.h
index 06b593f..18ea2ec 100644
--- a/maidag/maidag.h
+++ b/maidag/maidag.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/maidag/mailquota.c b/maidag/mailquota.c
index 8623719..ef0d94e 100644
--- a/maidag/mailquota.c
+++ b/maidag/mailquota.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2004,
- 2005, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2004, 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/maidag/mailtmp.c b/maidag/mailtmp.c
index 775731f..25e592c 100644
--- a/maidag/mailtmp.c
+++ b/maidag/mailtmp.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/maidag/python.c b/maidag/python.c
index 2df544c..71ff506 100644
--- a/maidag/python.c
+++ b/maidag/python.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/maidag/script.c b/maidag/script.c
index 1a981b0..280011e 100644
--- a/maidag/script.c
+++ b/maidag/script.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/maidag/sieve.c b/maidag/sieve.c
index e9c17c9..f3cfd43 100644
--- a/maidag/sieve.c
+++ b/maidag/sieve.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/maidag/util.c b/maidag/util.c
index 463a10f..068f928 100644
--- a/maidag/util.c
+++ b/maidag/util.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007 Free Software Foundation, Inc.
+ Copyright (C) 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 published by
diff --git a/mail/Makefile.am b/mail/Makefile.am
index bcd482d..3da9034 100644
--- a/mail/Makefile.am
+++ b/mail/Makefile.am
@@ -1,6 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 1999,2000,2001,2002,2005,2007 Free Software Foundation, Inc.
+## Copyright (C) 1999, 2000, 2001, 2002, 2005, 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/mail/alias.c b/mail/alias.c
index ea9519c..31532ff 100644
--- a/mail/alias.c
+++ b/mail/alias.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2005, 2006, 2007 Free Software Foundation,
Inc.
+ Copyright (C) 1999, 2001, 2002, 2005, 2006, 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 published by
diff --git a/mail/alt.c b/mail/alt.c
index fc26d8a..e38c6fb 100644
--- a/mail/alt.c
+++ b/mail/alt.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 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/mail/cd.c b/mail/cd.c
index 1ebf69d..01c199f 100644
--- a/mail/cd.c
+++ b/mail/cd.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2005, 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 published by
diff --git a/mail/copy.c b/mail/copy.c
index 604d063..43087db 100644
--- a/mail/copy.c
+++ b/mail/copy.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2005,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2003, 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/mail/decode.c b/mail/decode.c
index 6327456..2eb3a82 100644
--- a/mail/decode.c
+++ b/mail/decode.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2005, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 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/mail/delete.c b/mail/delete.c
index 83dae90..55a7978 100644
--- a/mail/delete.c
+++ b/mail/delete.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2005,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2003, 2005, 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 published by
diff --git a/mail/dp.c b/mail/dp.c
index 81e1990..d52ce1b 100644
--- a/mail/dp.c
+++ b/mail/dp.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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 published by
diff --git a/mail/echo.c b/mail/echo.c
index 52aaf4e..accafed 100644
--- a/mail/echo.c
+++ b/mail/echo.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 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 published by
diff --git a/mail/edit.c b/mail/edit.c
index 593c657..27a394d 100644
--- a/mail/edit.c
+++ b/mail/edit.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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 published by
diff --git a/mail/envelope.c b/mail/envelope.c
index 8525ccc..575c12a 100644
--- a/mail/envelope.c
+++ b/mail/envelope.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/mail/eq.c b/mail/eq.c
index 26113a9..99a509d 100644
--- a/mail/eq.c
+++ b/mail/eq.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2005,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2003, 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/mail/escape.c b/mail/escape.c
index b2e016c..41b7f1b 100644
--- a/mail/escape.c
+++ b/mail/escape.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2005, 2006,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 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 published by
diff --git a/mail/exit.c b/mail/exit.c
index 0e680b6..af2d7bc 100644
--- a/mail/exit.c
+++ b/mail/exit.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2005, 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 published by
diff --git a/mail/file.c b/mail/file.c
index e565878..c0e3463 100644
--- a/mail/file.c
+++ b/mail/file.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2005, 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 published by
diff --git a/mail/folders.c b/mail/folders.c
index 1eaedf4..d832da7 100644
--- a/mail/folders.c
+++ b/mail/folders.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2005, 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 published by
diff --git a/mail/followup.c b/mail/followup.c
index bc905fa..5c699d0 100644
--- a/mail/followup.c
+++ b/mail/followup.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2005,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2003, 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/mail/from.c b/mail/from.c
index 75212e1..7af3cb7 100644
--- a/mail/from.c
+++ b/mail/from.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2005, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 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/mail/headers.c b/mail/headers.c
index 92018ba..5e7e982 100644
--- a/mail/headers.c
+++ b/mail/headers.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2005, 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 published by
diff --git a/mail/help.c b/mail/help.c
index 7618eb1..c6442f1 100644
--- a/mail/help.c
+++ b/mail/help.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2005, 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 published by
diff --git a/mail/hold.c b/mail/hold.c
index aaa580c..8535cc9 100644
--- a/mail/hold.c
+++ b/mail/hold.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2005, 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 published by
diff --git a/mail/if.c b/mail/if.c
index f94f79a..8a93618 100644
--- a/mail/if.c
+++ b/mail/if.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 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 published by
diff --git a/mail/inc.c b/mail/inc.c
index 13a9b90..f0b6617 100644
--- a/mail/inc.c
+++ b/mail/inc.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2005, 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 published by
diff --git a/mail/list.c b/mail/list.c
index 21395dd..c6c4844 100644
--- a/mail/list.c
+++ b/mail/list.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2005, 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 published by
diff --git a/mail/mail.c b/mail/mail.c
index 4f4c879..afeb4e1 100644
--- a/mail/mail.c
+++ b/mail/mail.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004,
- 2005, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 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 published by
diff --git a/mail/mail.h b/mail/mail.h
index 50d3e31..6c419d5 100644
--- a/mail/mail.h
+++ b/mail/mail.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2005,
- 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 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 published by
diff --git a/mail/mailline.c b/mail/mailline.c
index dabf66e..cc0df6d 100644
--- a/mail/mailline.c
+++ b/mail/mailline.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/mail/mailvar.c b/mail/mailvar.c
index f948b1a..7f163ae 100644
--- a/mail/mailvar.c
+++ b/mail/mailvar.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/mail/mbox.c b/mail/mbox.c
index e1d66b7..2b093f2 100644
--- a/mail/mbox.c
+++ b/mail/mbox.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2005, 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 published by
diff --git a/mail/msgset.y b/mail/msgset.y
index dbf484f..270cded 100644
--- a/mail/msgset.y
+++ b/mail/msgset.y
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003, 2005,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 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/mail/next.c b/mail/next.c
index 59ce1b0..4b48b5f 100644
--- a/mail/next.c
+++ b/mail/next.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2005,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2003, 2005, 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 published by
diff --git a/mail/page.c b/mail/page.c
index 4b9f796..760de42 100644
--- a/mail/page.c
+++ b/mail/page.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2005, 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 published by
diff --git a/mail/pipe.c b/mail/pipe.c
index 4afe18a..6efb869 100644
--- a/mail/pipe.c
+++ b/mail/pipe.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2003, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2003, 2005, 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 published by
diff --git a/mail/previous.c b/mail/previous.c
index d07514b..25ed10d 100644
--- a/mail/previous.c
+++ b/mail/previous.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2005,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2003, 2005, 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 published by
diff --git a/mail/print.c b/mail/print.c
index 51d77d4..f4ddf94 100644
--- a/mail/print.c
+++ b/mail/print.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/mail/quit.c b/mail/quit.c
index 3d98890..4efeaf4 100644
--- a/mail/quit.c
+++ b/mail/quit.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2005,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2003, 2005, 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 published by
diff --git a/mail/reply.c b/mail/reply.c
index 880844d..6a85ec7 100644
--- a/mail/reply.c
+++ b/mail/reply.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 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/mail/retain.c b/mail/retain.c
index a9cee47..07656aa 100644
--- a/mail/retain.c
+++ b/mail/retain.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2004, 2005,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2004, 2005, 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 published by
diff --git a/mail/save.c b/mail/save.c
index 7bde1a0..0b681bd 100644
--- a/mail/save.c
+++ b/mail/save.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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 published by
diff --git a/mail/send.c b/mail/send.c
index e77560f..7ebdaaa 100644
--- a/mail/send.c
+++ b/mail/send.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2004,
- 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 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 published by
diff --git a/mail/set.c b/mail/set.c
index 6dfed55..6daf381 100644
--- a/mail/set.c
+++ b/mail/set.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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 published by
diff --git a/mail/setenv.c b/mail/setenv.c
index 624fb13..ed73abf 100644
--- a/mail/setenv.c
+++ b/mail/setenv.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 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 published by
diff --git a/mail/shell.c b/mail/shell.c
index 8f7b8e0..3c44495 100644
--- a/mail/shell.c
+++ b/mail/shell.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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/mail/size.c b/mail/size.c
index dddf48d..c21b8bd 100644
--- a/mail/size.c
+++ b/mail/size.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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/mail/source.c b/mail/source.c
index ddbb809..c7aa43a 100644
--- a/mail/source.c
+++ b/mail/source.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 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 published by
diff --git a/mail/struct.c b/mail/struct.c
index 8d22b41..0f241df 100644
--- a/mail/struct.c
+++ b/mail/struct.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/mail/summary.c b/mail/summary.c
index e569104..4e7721b 100644
--- a/mail/summary.c
+++ b/mail/summary.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2005, 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 published by
diff --git a/mail/table.c b/mail/table.c
index ead4bfe..c8996b8 100644
--- a/mail/table.c
+++ b/mail/table.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2005, 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 published by
diff --git a/mail/tag.c b/mail/tag.c
index cea1404..198b041 100644
--- a/mail/tag.c
+++ b/mail/tag.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2005,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2003, 2005, 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 published by
diff --git a/mail/testsuite/Makefile.am b/mail/testsuite/Makefile.am
index 1af00ca..bb8ddf8 100644
--- a/mail/testsuite/Makefile.am
+++ b/mail/testsuite/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2002, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2002, 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/mail/testsuite/if.mail b/mail/testsuite/if.mail
index 3e887a0..5fa6a01 100644
--- a/mail/testsuite/if.mail
+++ b/mail/testsuite/if.mail
@@ -1,5 +1,5 @@
# This file is part of Mailutils testsuite.
-# Copyright (C) 2005, 2007 Free Software Foundation
+# Copyright (C) 2005, 2007, 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/mail/testsuite/lib/mail.exp b/mail/testsuite/lib/mail.exp
index bdae899..b0b23e9 100644
--- a/mail/testsuite/lib/mail.exp
+++ b/mail/testsuite/lib/mail.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007, 2009 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/mail/testsuite/mail/alias.exp b/mail/testsuite/mail/alias.exp
index 96fa09c..71b5dd9 100644
--- a/mail/testsuite/mail/alias.exp
+++ b/mail/testsuite/mail/alias.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/mail/testsuite/mail/folder.exp b/mail/testsuite/mail/folder.exp
index 328d3df..70a284b 100644
--- a/mail/testsuite/mail/folder.exp
+++ b/mail/testsuite/mail/folder.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/mail/testsuite/mail/if.exp b/mail/testsuite/mail/if.exp
index b5e59ae..e93c262 100644
--- a/mail/testsuite/mail/if.exp
+++ b/mail/testsuite/mail/if.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2005, 2007, 2009 Free Software Foundation
+# Copyright (C) 2002, 2005, 2007, 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/mail/testsuite/mail/read.exp b/mail/testsuite/mail/read.exp
index 5ef1158..5d6d9ac 100644
--- a/mail/testsuite/mail/read.exp
+++ b/mail/testsuite/mail/read.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2005, 2007 Free Software Foundation
+# Copyright (C) 2002, 2005, 2007, 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/mail/testsuite/mail/send.exp b/mail/testsuite/mail/send.exp
index c11aeb9..726cffb 100644
--- a/mail/testsuite/mail/send.exp
+++ b/mail/testsuite/mail/send.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2006, 2007 Free Software Foundation
+# Copyright (C) 2002, 2006, 2007, 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/mail/testsuite/mail/tag.exp b/mail/testsuite/mail/tag.exp
index cc1468f..edb2270 100644
--- a/mail/testsuite/mail/tag.exp
+++ b/mail/testsuite/mail/tag.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/mail/testsuite/mail/write.exp b/mail/testsuite/mail/write.exp
index 85b1d16..d78efd0 100644
--- a/mail/testsuite/mail/write.exp
+++ b/mail/testsuite/mail/write.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007, 2009 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/mail/testsuite/mail/z.exp b/mail/testsuite/mail/z.exp
index 30a086f..39b876a 100644
--- a/mail/testsuite/mail/z.exp
+++ b/mail/testsuite/mail/z.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2005, 2007 Free Software Foundation
+# Copyright (C) 2002, 2005, 2007, 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/mail/testsuite/makespool b/mail/testsuite/makespool
index f253aa6..190ba85 100755
--- a/mail/testsuite/makespool
+++ b/mail/testsuite/makespool
@@ -1,6 +1,6 @@
#! /bin/sh
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2002, 2007 Free Software Foundation, Inc.
+# Copyright (C) 2002, 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 published by
diff --git a/mail/top.c b/mail/top.c
index 5b35665..9fa296e 100644
--- a/mail/top.c
+++ b/mail/top.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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 published by
diff --git a/mail/touch.c b/mail/touch.c
index 2911098..6f232f3 100644
--- a/mail/touch.c
+++ b/mail/touch.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2005, 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 published by
diff --git a/mail/unalias.c b/mail/unalias.c
index faa6a72..7370c24 100644
--- a/mail/unalias.c
+++ b/mail/unalias.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 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 published by
diff --git a/mail/undelete.c b/mail/undelete.c
index e877394..ca99b32 100644
--- a/mail/undelete.c
+++ b/mail/undelete.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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 published by
diff --git a/mail/unset.c b/mail/unset.c
index fa9cd22..cbc6118 100644
--- a/mail/unset.c
+++ b/mail/unset.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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 published by
diff --git a/mail/util.c b/mail/util.c
index 0e1e0b0..70cc8f1 100644
--- a/mail/util.c
+++ b/mail/util.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2004, 2005, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 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 published by
diff --git a/mail/version.c b/mail/version.c
index 75daddd..0136278 100644
--- a/mail/version.c
+++ b/mail/version.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.
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/mail/visual.c b/mail/visual.c
index e71d6f7..6103221 100644
--- a/mail/visual.c
+++ b/mail/visual.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2005, 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 published by
diff --git a/mail/write.c b/mail/write.c
index 5c396fb..dafb7b9 100644
--- a/mail/write.c
+++ b/mail/write.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2005,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2003, 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/mail/z.c b/mail/z.c
index 48ffe8a..a124cbe 100644
--- a/mail/z.c
+++ b/mail/z.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2005, 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 published by
diff --git a/mailbox/Makefile.am b/mailbox/Makefile.am
index d6f8332..1019e7b 100644
--- a/mailbox/Makefile.am
+++ b/mailbox/Makefile.am
@@ -1,7 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2000, 2001, 2002, 2004, 2005, 2006, 2007, 2008,
-## 2009 Free Software Foundation, Inc.
+## Copyright (C) 2000, 2001, 2002, 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/mailbox/acl.c b/mailbox/acl.c
index 7dc5e3e..7fb2acd 100644
--- a/mailbox/acl.c
+++ b/mailbox/acl.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2008, 2009, 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/mailbox/address.c b/mailbox/address.c
index 28ab506..cd151c1 100644
--- a/mailbox/address.c
+++ b/mailbox/address.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2006,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2006, 2007, 2009, 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/mailbox/alloc.c b/mailbox/alloc.c
index d3d44b6..f2e0c64 100644
--- a/mailbox/alloc.c
+++ b/mailbox/alloc.c
@@ -1,5 +1,5 @@
/* Error-proof memory allocation functions.
- Copyright (C) 2008 Free Software Foundation, Inc.
+ Copyright (C) 2008, 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/mailbox/amd.c b/mailbox/amd.c
index 24410c4..3e275eb 100644
--- a/mailbox/amd.c
+++ b/mailbox/amd.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
+ 2008, 2009, 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/mailbox/argcv.c b/mailbox/argcv.c
index be81639..c31836c 100644
--- a/mailbox/argcv.c
+++ b/mailbox/argcv.c
@@ -1,6 +1,6 @@
/* argcv.c - simple functions for parsing input based on whitespace
- Copyright (C) 1999, 2000, 2001, 2003, 2004,
- 2005, 2006 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 2004, 2005, 2006, 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/mailbox/asnprintf.c b/mailbox/asnprintf.c
index e3413af..f8ef543 100644
--- a/mailbox/asnprintf.c
+++ b/mailbox/asnprintf.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/mailbox/asprintf.c b/mailbox/asprintf.c
index 2bcd61d..c563bcb 100644
--- a/mailbox/asprintf.c
+++ b/mailbox/asprintf.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/mailbox/assoc.c b/mailbox/assoc.c
index 1dc6a73..418fa08 100644
--- a/mailbox/assoc.c
+++ b/mailbox/assoc.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/mailbox/attachment.c b/mailbox/attachment.c
index e72265b..0940904 100644
--- a/mailbox/attachment.c
+++ b/mailbox/attachment.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2007, 2009, 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/mailbox/attribute.c b/mailbox/attribute.c
index dfe76ff..d5c5d67 100644
--- a/mailbox/attribute.c
+++ b/mailbox/attribute.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2007, 2009, 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/mailbox/auth.c b/mailbox/auth.c
index 6ffeb08..7975050 100644
--- a/mailbox/auth.c
+++ b/mailbox/auth.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2007, 2009, 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/mailbox/base64.c b/mailbox/base64.c
index 0b6f9de..4c67a48 100644
--- a/mailbox/base64.c
+++ b/mailbox/base64.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2002, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2002, 2009, 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/mailbox/body.c b/mailbox/body.c
index 3c0f5af..cd430cd 100644
--- a/mailbox/body.c
+++ b/mailbox/body.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 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/mailbox/cfg_driver.c b/mailbox/cfg_driver.c
index 412aca5..6d98771 100644
--- a/mailbox/cfg_driver.c
+++ b/mailbox/cfg_driver.c
@@ -1,5 +1,5 @@
/* cfg_driver.c -- Main driver for Mailutils configuration files
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/mailbox/cfg_format.c b/mailbox/cfg_format.c
index 5e9b3cf..0cdbb2d 100644
--- a/mailbox/cfg_format.c
+++ b/mailbox/cfg_format.c
@@ -1,5 +1,5 @@
/* cfg_print.c -- convert configuration parse tree to human-readable format.
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/mailbox/cfg_lexer.l b/mailbox/cfg_lexer.l
index 8e528f8..87c1638 100644
--- a/mailbox/cfg_lexer.l
+++ b/mailbox/cfg_lexer.l
@@ -1,6 +1,6 @@
%top {
/* cfg_lexer.l -- default lexer for Mailutils configuration files
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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
@@ -363,7 +363,7 @@ mu_get_config (const char *file, const char *progname,
int rc = mu_cfg_parse_file (&parse_tree, file, flags);
if (rc == 0)
{
- rc = mu_cfg_tree_postprocess (&parse_tree, flags);
+ rc = mu_cfg_tree_postprocess (parse_tree, flags);
if (rc == 0)
rc = mu_cfg_tree_reduce (parse_tree, progname, progparam, flags,
target_ptr);
diff --git a/mailbox/cfg_parser.y b/mailbox/cfg_parser.y
index 2710afd..a8bd044 100644
--- a/mailbox/cfg_parser.y
+++ b/mailbox/cfg_parser.y
@@ -1,6 +1,6 @@
%{
/* cfg_parser.y -- general-purpose configuration file parser
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/mailbox/cstrcasecmp.c b/mailbox/cstrcasecmp.c
index 04f9e8a..4baeae2 100644
--- a/mailbox/cstrcasecmp.c
+++ b/mailbox/cstrcasecmp.c
@@ -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.
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/mailbox/cstrlower.c b/mailbox/cstrlower.c
index 058075b..98afb5f 100644
--- a/mailbox/cstrlower.c
+++ b/mailbox/cstrlower.c
@@ -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.
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/mailbox/cstrupper.c b/mailbox/cstrupper.c
index 37d69f2..965977d 100644
--- a/mailbox/cstrupper.c
+++ b/mailbox/cstrupper.c
@@ -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.
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/mailbox/daemon.c b/mailbox/daemon.c
index 8f83254..b7fca61 100644
--- a/mailbox/daemon.c
+++ b/mailbox/daemon.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 2007, 2008, 2009, 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/mailbox/date.c b/mailbox/date.c
index da5f1d2..d667e34 100644
--- a/mailbox/date.c
+++ b/mailbox/date.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.
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/mailbox/dbgstderr.c b/mailbox/dbgstderr.c
index 2e02a98..9a2e164 100644
--- a/mailbox/dbgstderr.c
+++ b/mailbox/dbgstderr.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005, 2007 Free Software Foundation,
Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 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/mailbox/dbgsyslog.c b/mailbox/dbgsyslog.c
index bc0b972..f906cd3 100644
--- a/mailbox/dbgsyslog.c
+++ b/mailbox/dbgsyslog.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005, 2007 Free Software Foundation,
Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 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/mailbox/debug.c b/mailbox/debug.c
index 21b18ed..37f9e47 100644
--- a/mailbox/debug.c
+++ b/mailbox/debug.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2007, 2008, 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/mailbox/diag.c b/mailbox/diag.c
index 1efe746..7497c82 100644
--- a/mailbox/diag.c
+++ b/mailbox/diag.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2007, 2009, 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/mailbox/envelope.c b/mailbox/envelope.c
index 8974afb..21facf7 100644
--- a/mailbox/envelope.c
+++ b/mailbox/envelope.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2004, 2005, 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/mailbox/errors b/mailbox/errors
index ecde54b..49910ee 100644
--- a/mailbox/errors
+++ b/mailbox/errors
@@ -1,5 +1,5 @@
# Error messages for GNU Mailutils
-# Copyright (C) 2005, 2006, 2007 Free Software Foundation, Inc.
+# Copyright (C) 2005, 2006, 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/mailbox/fgetpwent.c b/mailbox/fgetpwent.c
index 68b83ce..99ec9da 100644
--- a/mailbox/fgetpwent.c
+++ b/mailbox/fgetpwent.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/mailbox/file_stream.c b/mailbox/file_stream.c
index b773768..edfa1a7 100644
--- a/mailbox/file_stream.c
+++ b/mailbox/file_stream.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2004,
- 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2004, 2005, 2006, 2007, 2008,
+ 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/mailbox/filter.c b/mailbox/filter.c
index 785f22d..6a2e4d1 100644
--- a/mailbox/filter.c
+++ b/mailbox/filter.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2007, 2009, 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/mailbox/filter_iconv.c b/mailbox/filter_iconv.c
index 62229e2..c09d463 100644
--- a/mailbox/filter_iconv.c
+++ b/mailbox/filter_iconv.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 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/mailbox/filter_rfc822.c b/mailbox/filter_rfc822.c
index 0516dc3..d9e0704 100644
--- a/mailbox/filter_rfc822.c
+++ b/mailbox/filter_rfc822.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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/mailbox/filter_trans.c b/mailbox/filter_trans.c
index cbc5fd5..411a07e 100644
--- a/mailbox/filter_trans.c
+++ b/mailbox/filter_trans.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 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/mailbox/folder.c b/mailbox/folder.c
index fec5b43..432c507 100644
--- a/mailbox/folder.c
+++ b/mailbox/folder.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005, 2006,
- 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2006, 2007, 2008, 2009,
+ 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/mailbox/gdebug.c b/mailbox/gdebug.c
index f9dab9e..3d1a54c 100644
--- a/mailbox/gdebug.c
+++ b/mailbox/gdebug.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2007, 2008, 2009, 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/mailbox/gocs.c b/mailbox/gocs.c
index 220f1db..35e85ac 100644
--- a/mailbox/gocs.c
+++ b/mailbox/gocs.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2008, 2009, 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/mailbox/hdritr.c b/mailbox/hdritr.c
index 2f43c37..28fac2e 100644
--- a/mailbox/hdritr.c
+++ b/mailbox/hdritr.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2008 Free Software Foundation, Inc.
+ Copyright (C) 2008, 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/mailbox/header.c b/mailbox/header.c
index 8360679..81cc5b3 100644
--- a/mailbox/header.c
+++ b/mailbox/header.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2007, 2008, 2009, 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/mailbox/ipsrv.c b/mailbox/ipsrv.c
index 68cf503..e3efc62 100644
--- a/mailbox/ipsrv.c
+++ b/mailbox/ipsrv.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2008, 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/mailbox/iterator.c b/mailbox/iterator.c
index b361332..9ace323 100644
--- a/mailbox/iterator.c
+++ b/mailbox/iterator.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2004, 2005, 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/mailbox/kwd.c b/mailbox/kwd.c
index 9947fc6..9135f9f 100644
--- a/mailbox/kwd.c
+++ b/mailbox/kwd.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2009, 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/mailbox/list.c b/mailbox/list.c
index 0bb26d7..8d2d2a1 100644
--- a/mailbox/list.c
+++ b/mailbox/list.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005, 2007, 2008 Free Software
- Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2007, 2008, 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/mailbox/locale.c b/mailbox/locale.c
index 60a11b0..b6bdc08 100644
--- a/mailbox/locale.c
+++ b/mailbox/locale.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2009, 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/mailbox/locker.c b/mailbox/locker.c
index 3b33510..bbe41f9 100644
--- a/mailbox/locker.c
+++ b/mailbox/locker.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2006,
- 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2006, 2007, 2008, 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/mailbox/mailbox.c b/mailbox/mailbox.c
index fc62ab7..91c658b 100644
--- a/mailbox/mailbox.c
+++ b/mailbox/mailbox.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005, 2006,
- 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2006, 2007, 2008, 2009,
+ 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/mailbox/mailcap.c b/mailbox/mailcap.c
index 0efd218..70f3427 100644
--- a/mailbox/mailcap.c
+++ b/mailbox/mailcap.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2003, 2004, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2003, 2004, 2005, 2007, 2009, 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/mailbox/mailer.c b/mailbox/mailer.c
index 9b0e54e..f2786c8 100644
--- a/mailbox/mailer.c
+++ b/mailbox/mailer.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005, 2006,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2006, 2007, 2009, 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/mailbox/mapfile_stream.c b/mailbox/mapfile_stream.c
index a711792..29a6f06 100644
--- a/mailbox/mapfile_stream.c
+++ b/mailbox/mapfile_stream.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 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/mailbox/mbx_default.c b/mailbox/mbx_default.c
index ef2089a..a03e9ea 100644
--- a/mailbox/mbx_default.c
+++ b/mailbox/mbx_default.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2003, 2004,
- 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 2004, 2005, 2006, 2007, 2008,
+ 2009, 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/mailbox/md5.c b/mailbox/md5.c
index 41016b5..a6d3247 100644
--- a/mailbox/md5.c
+++ b/mailbox/md5.c
@@ -1,6 +1,6 @@
/* Functions to compute MD5 message digest of files or memory blocks.
according to the definition of MD5 in RFC 1321 from April 1992.
- Copyright (C) 1995,1996,1997,1999,2000,2001,2005,2006
+ Copyright (C) 1995,1996,1997,1999,2000,2001,2005,2006,2010
Free Software Foundation, Inc.
This file is part of the GNU C Library.
diff --git a/mailbox/memory_stream.c b/mailbox/memory_stream.c
index d703f8c..e433961 100644
--- a/mailbox/memory_stream.c
+++ b/mailbox/memory_stream.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 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/mailbox/message.c b/mailbox/message.c
index ee80f8b..33730a5 100644
--- a/mailbox/message.c
+++ b/mailbox/message.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2004,
- 2005, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2004, 2005, 2006, 2007, 2009,
+ 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/mailbox/message_stream.c b/mailbox/message_stream.c
index aa7b993..98f022b 100644
--- a/mailbox/message_stream.c
+++ b/mailbox/message_stream.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2005,
- 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 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 published by
diff --git a/mailbox/mime.c b/mailbox/mime.c
index 3199a20..421d686 100644
--- a/mailbox/mime.c
+++ b/mailbox/mime.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2003, 2004,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 2004, 2007, 2009, 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/mailbox/mkfilename.c b/mailbox/mkfilename.c
index 00e64bc..ecd6dee 100644
--- a/mailbox/mkfilename.c
+++ b/mailbox/mkfilename.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/mailbox/monitor.c b/mailbox/monitor.c
index 46307fe..55c94a9 100644
--- a/mailbox/monitor.c
+++ b/mailbox/monitor.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 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/mailbox/msrv.c b/mailbox/msrv.c
index 13a85d4..209da44 100644
--- a/mailbox/msrv.c
+++ b/mailbox/msrv.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2008, 2009, 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/mailbox/mu_auth.c b/mailbox/mu_auth.c
index 1e6c276..bba6b45 100644
--- a/mailbox/mu_auth.c
+++ b/mailbox/mu_auth.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2002, 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2002, 2004, 2005, 2006, 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/mailbox/muctype.c b/mailbox/muctype.c
index 59447a3..e425ffb 100644
--- a/mailbox/muctype.c
+++ b/mailbox/muctype.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/mailbox/muerrno.cin b/mailbox/muerrno.cin
index edf48ea..f00fb94 100644
--- a/mailbox/muerrno.cin
+++ b/mailbox/muerrno.cin
@@ -1,7 +1,7 @@
/* -*- c -*- $AUTOWARN
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 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/mailbox/muerror.c b/mailbox/muerror.c
index fd0d7f1..e18f0fe 100644
--- a/mailbox/muerror.c
+++ b/mailbox/muerror.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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/mailbox/munre.c b/mailbox/munre.c
index 4fc86b8..ca66cad 100644
--- a/mailbox/munre.c
+++ b/mailbox/munre.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003, 2006,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2006, 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/mailbox/mutil.c b/mailbox/mutil.c
index 489e153..ce53794 100644
--- a/mailbox/mutil.c
+++ b/mailbox/mutil.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2005, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2005, 2006, 2007, 2009,
+ 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/mailbox/nls.c b/mailbox/nls.c
index c548869..4b9a8fe 100644
--- a/mailbox/nls.c
+++ b/mailbox/nls.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2002, 2006, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2002, 2006, 2007, 2008, 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/mailbox/observer.c b/mailbox/observer.c
index 58dd174..d6b26f4 100644
--- a/mailbox/observer.c
+++ b/mailbox/observer.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2004, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2004, 2005, 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/mailbox/opool.c b/mailbox/opool.c
index c98dc66..acb29ac 100644
--- a/mailbox/opool.c
+++ b/mailbox/opool.c
@@ -1,5 +1,5 @@
/* String-list functions for GNU Mailutils.
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
Based on slist module from GNU Radius. Written by Sergey Poznyakoff.
diff --git a/mailbox/parse822.c b/mailbox/parse822.c
index 6490ff9..b4d66bc 100644
--- a/mailbox/parse822.c
+++ b/mailbox/parse822.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 2007, 2009, 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/mailbox/parsedate.y b/mailbox/parsedate.y
index a73fbbc..79eda8b 100644
--- a/mailbox/parsedate.y
+++ b/mailbox/parsedate.y
@@ -1,6 +1,6 @@
%{
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2007, 2008, 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/mailbox/permstr.c b/mailbox/permstr.c
index 13d980b..d3d184a 100644
--- a/mailbox/permstr.c
+++ b/mailbox/permstr.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2008 Free Software Foundation, Inc.
+ Copyright (C) 2008, 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/mailbox/progmailer.c b/mailbox/progmailer.c
index 718e519..6af0934 100644
--- a/mailbox/progmailer.c
+++ b/mailbox/progmailer.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2006, 2007, 2008, 2009,
+ 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/mailbox/property.c b/mailbox/property.c
index 85082a0..e5980b9 100644
--- a/mailbox/property.c
+++ b/mailbox/property.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005, 2007, 2008
- Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2007, 2008, 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/mailbox/refcount.c b/mailbox/refcount.c
index 2cd77ba..1be1fc6 100644
--- a/mailbox/refcount.c
+++ b/mailbox/refcount.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2003, 2004,
- 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 2004, 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/mailbox/registrar.c b/mailbox/registrar.c
index aa17fea..1f6cc6f 100644
--- a/mailbox/registrar.c
+++ b/mailbox/registrar.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005, 2006,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2006, 2007, 2009, 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/mailbox/rfc2047.c b/mailbox/rfc2047.c
index 28717a3..bf23b7e 100644
--- a/mailbox/rfc2047.c
+++ b/mailbox/rfc2047.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2004, 2005, 2006, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2004, 2005, 2006, 2007, 2009, 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/mailbox/secret.c b/mailbox/secret.c
index 482949e..e472839 100644
--- a/mailbox/secret.c
+++ b/mailbox/secret.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/mailbox/server.c b/mailbox/server.c
index 23b5c6b..3214fb0 100644
--- a/mailbox/server.c
+++ b/mailbox/server.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2008, 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/mailbox/sha1.c b/mailbox/sha1.c
index e4cf16f..57d6377 100644
--- a/mailbox/sha1.c
+++ b/mailbox/sha1.c
@@ -1,7 +1,7 @@
/* sha1.c - Functions to compute SHA1 message digest of files or
memory blocks according to the NIST specification FIPS-180-1.
- Copyright (C) 2000, 2001, 2003, 2004, 2005, 2006 Free Software
+ Copyright (C) 2000, 2001, 2003, 2004, 2005, 2006, 2010 Free Software
Foundation, Inc.
This program is free software; you can redistribute it and/or modify it
diff --git a/mailbox/size_max.h b/mailbox/size_max.h
index ed0bc13..ee3fc25 100644
--- a/mailbox/size_max.h
+++ b/mailbox/size_max.h
@@ -1,5 +1,5 @@
/* size_max.h -- declare SIZE_MAX through system headers
- Copyright (C) 2005-2006 Free Software Foundation, Inc.
+ Copyright (C) 2005, 2006, 2010 Free Software Foundation, Inc.
Written by Simon Josefsson.
This program is free software; you can redistribute it and/or modify
diff --git a/mailbox/socket_stream.c b/mailbox/socket_stream.c
index 0c20320..a28a447 100644
--- a/mailbox/socket_stream.c
+++ b/mailbox/socket_stream.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2004,
- 2005, 2006, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2004, 2005, 2006, 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/mailbox/stream.c b/mailbox/stream.c
index 208ca0b..bdb44da 100644
--- a/mailbox/stream.c
+++ b/mailbox/stream.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2006, 2007, 2009, 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
@@ -298,6 +298,7 @@ mu_stream_readline (mu_stream_t is, char *buf, size_t count,
size_t n, nr = 0;
char c;
/* Grossly inefficient hopefully they override this */
+ count--; /* Leave space for the null. */
for (n = 0; n < count; )
{
status = is->_read (is, &c, 1, offset, &nr);
@@ -419,7 +420,7 @@ mu_stream_getline (mu_stream_t is, char **pbuf, size_t
*pbufsize,
size_t nread;
int rc;
- if (off + 1 == bufsize)
+ if (off == bufsize)
{
char *p;
p = realloc (buf, bufsize + DELTA);
diff --git a/mailbox/stripws.c b/mailbox/stripws.c
index cb96a74..688c8c7 100644
--- a/mailbox/stripws.c
+++ b/mailbox/stripws.c
@@ -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.
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/mailbox/strltrim.c b/mailbox/strltrim.c
index 867cf3c..e869807 100644
--- a/mailbox/strltrim.c
+++ b/mailbox/strltrim.c
@@ -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.
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/mailbox/strrtrim.c b/mailbox/strrtrim.c
index 5a1e230..95e7bab 100644
--- a/mailbox/strrtrim.c
+++ b/mailbox/strrtrim.c
@@ -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.
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/mailbox/strskip.c b/mailbox/strskip.c
index 669ec22..f24d119 100644
--- a/mailbox/strskip.c
+++ b/mailbox/strskip.c
@@ -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.
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/mailbox/syslog.c b/mailbox/syslog.c
index d931659..c97da9b 100644
--- a/mailbox/syslog.c
+++ b/mailbox/syslog.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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 the
diff --git a/mailbox/system.c b/mailbox/system.c
index bd16b4b..8e28caa 100644
--- a/mailbox/system.c
+++ b/mailbox/system.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2002, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2002, 2007, 2009, 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/mailbox/tcp.c b/mailbox/tcp.c
index 0f27684..4d36648 100644
--- a/mailbox/tcp.c
+++ b/mailbox/tcp.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2004, 2006, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2004, 2006, 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/mailbox/testsuite/Addrs b/mailbox/testsuite/Addrs
index a3a2ac6..f301e65 100644
--- a/mailbox/testsuite/Addrs
+++ b/mailbox/testsuite/Addrs
@@ -1,5 +1,5 @@
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/mailbox/testsuite/Argcv b/mailbox/testsuite/Argcv
index ebb2cb7..076edc9 100644
--- a/mailbox/testsuite/Argcv
+++ b/mailbox/testsuite/Argcv
@@ -1,5 +1,5 @@
# This file is part of Mailutils testsuite.
-# Copyright (C) 2005, 2007 Free Software Foundation
+# Copyright (C) 2005, 2007, 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/mailbox/testsuite/Decode2047 b/mailbox/testsuite/Decode2047
index a0ddbbc..96bd334 100644
--- a/mailbox/testsuite/Decode2047
+++ b/mailbox/testsuite/Decode2047
@@ -1,5 +1,5 @@
# This file is part of Mailutils testsuite.
-# Copyright (C) 2003, 2006, 2007 Free Software Foundation
+# Copyright (C) 2003, 2006, 2007, 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/mailbox/testsuite/Encode2047 b/mailbox/testsuite/Encode2047
index 1b63187..de098ec 100644
--- a/mailbox/testsuite/Encode2047
+++ b/mailbox/testsuite/Encode2047
@@ -1,5 +1,5 @@
# This file is part of Mailutils testsuite.
-# Copyright (C) 2006, 2007 Free Software Foundation
+# Copyright (C) 2006, 2007, 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/mailbox/testsuite/Mailcap b/mailbox/testsuite/Mailcap
index 4d31084..a8dcb4e 100644
--- a/mailbox/testsuite/Mailcap
+++ b/mailbox/testsuite/Mailcap
@@ -1,5 +1,5 @@
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/mailbox/testsuite/Makefile.am b/mailbox/testsuite/Makefile.am
index bb00f65..fb30e88 100644
--- a/mailbox/testsuite/Makefile.am
+++ b/mailbox/testsuite/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2002, 2003, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2002, 2003, 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/mailbox/testsuite/Mime b/mailbox/testsuite/Mime
index 20c7185..07d046f 100644
--- a/mailbox/testsuite/Mime
+++ b/mailbox/testsuite/Mime
@@ -1,5 +1,5 @@
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/mailbox/testsuite/lib/mailbox.exp
b/mailbox/testsuite/lib/mailbox.exp
index c836fa1..abc273e 100644
--- a/mailbox/testsuite/lib/mailbox.exp
+++ b/mailbox/testsuite/lib/mailbox.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007, 2009 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/mailbox/testsuite/mailbox/address.exp
b/mailbox/testsuite/mailbox/address.exp
index ba262f3..2809580 100644
--- a/mailbox/testsuite/mailbox/address.exp
+++ b/mailbox/testsuite/mailbox/address.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/mailbox/testsuite/mailbox/argcv.exp
b/mailbox/testsuite/mailbox/argcv.exp
index 3b28216..88db5e1 100644
--- a/mailbox/testsuite/mailbox/argcv.exp
+++ b/mailbox/testsuite/mailbox/argcv.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2005, 2007 Free Software Foundation
+# Copyright (C) 2005, 2007, 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/mailbox/testsuite/mailbox/base64.exp
b/mailbox/testsuite/mailbox/base64.exp
index b1fa5dc..64e8168 100644
--- a/mailbox/testsuite/mailbox/base64.exp
+++ b/mailbox/testsuite/mailbox/base64.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/mailbox/testsuite/mailbox/decode2047.exp
b/mailbox/testsuite/mailbox/decode2047.exp
index 3ff8f48..b91fa65 100644
--- a/mailbox/testsuite/mailbox/decode2047.exp
+++ b/mailbox/testsuite/mailbox/decode2047.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2003, 2006, 2007 Free Software Foundation
+# Copyright (C) 2003, 2006, 2007, 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/mailbox/testsuite/mailbox/encode2047.exp
b/mailbox/testsuite/mailbox/encode2047.exp
index 1ee4ab0..d696130 100644
--- a/mailbox/testsuite/mailbox/encode2047.exp
+++ b/mailbox/testsuite/mailbox/encode2047.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2006, 2007 Free Software Foundation
+# Copyright (C) 2006, 2007, 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/mailbox/testsuite/mailbox/list.exp
b/mailbox/testsuite/mailbox/list.exp
index a9fea53..c081520 100644
--- a/mailbox/testsuite/mailbox/list.exp
+++ b/mailbox/testsuite/mailbox/list.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2003, 2005, 2007, 2008 Free Software Foundation
+# Copyright (C) 2003, 2005, 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/mailbox/testsuite/mailbox/mailcap.exp
b/mailbox/testsuite/mailbox/mailcap.exp
index 892ed3a..eaed867 100644
--- a/mailbox/testsuite/mailbox/mailcap.exp
+++ b/mailbox/testsuite/mailbox/mailcap.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/mailbox/testsuite/mailbox/mime.exp
b/mailbox/testsuite/mailbox/mime.exp
index afabefb..aabecfe 100644
--- a/mailbox/testsuite/mailbox/mime.exp
+++ b/mailbox/testsuite/mailbox/mime.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/mailbox/testsuite/mailbox/url.exp
b/mailbox/testsuite/mailbox/url.exp
index d8c01fc..f390306 100644
--- a/mailbox/testsuite/mailbox/url.exp
+++ b/mailbox/testsuite/mailbox/url.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/mailbox/ticket.c b/mailbox/ticket.c
index 5fabb35..774b711 100644
--- a/mailbox/ticket.c
+++ b/mailbox/ticket.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2004, 2005,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2004, 2005, 2007, 2009, 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/mailbox/url.c b/mailbox/url.c
index 55b5220..5580f8c 100644
--- a/mailbox/url.c
+++ b/mailbox/url.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2007, 2008,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2007, 2008, 2009, 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/mailbox/vartab.c b/mailbox/vartab.c
index c85fa27..10649f5 100644
--- a/mailbox/vartab.c
+++ b/mailbox/vartab.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007 Free Software Foundation, Inc.
+ Copyright (C) 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/mailbox/vasnprintf.c b/mailbox/vasnprintf.c
index ca3b067..0f4350e 100644
--- a/mailbox/vasnprintf.c
+++ b/mailbox/vasnprintf.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/mailbox/version.c b/mailbox/version.c
index 374a269..1967dab 100644
--- a/mailbox/version.c
+++ b/mailbox/version.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2007, 2009, 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/mailbox/wicket.c b/mailbox/wicket.c
index 7d59e53..8169edd 100644
--- a/mailbox/wicket.c
+++ b/mailbox/wicket.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2003, 2004,
- 2005, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2003, 2004, 2005, 2007, 2009, 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/maint.mk b/maint.mk
index 7f71b18..b9628be 100644
--- a/maint.mk
+++ b/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/mapi/MAPIAddress.c b/mapi/MAPIAddress.c
index 79c3009..4466a02 100644
--- a/mapi/MAPIAddress.c
+++ b/mapi/MAPIAddress.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/mapi/MAPIDeleteMail.c b/mapi/MAPIDeleteMail.c
index 153dbe8..cf36a0b 100644
--- a/mapi/MAPIDeleteMail.c
+++ b/mapi/MAPIDeleteMail.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/mapi/MAPIDetails.c b/mapi/MAPIDetails.c
index d9c72a7..c66ec84 100644
--- a/mapi/MAPIDetails.c
+++ b/mapi/MAPIDetails.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/mapi/MAPIFindNext.c b/mapi/MAPIFindNext.c
index 04185f4..1b87f36 100644
--- a/mapi/MAPIFindNext.c
+++ b/mapi/MAPIFindNext.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/mapi/MAPIFreeBuffer.c b/mapi/MAPIFreeBuffer.c
index 5b13eb9..ab1b0a9 100644
--- a/mapi/MAPIFreeBuffer.c
+++ b/mapi/MAPIFreeBuffer.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/mapi/MAPILogoff.c b/mapi/MAPILogoff.c
index d6d144a..6cb0bac 100644
--- a/mapi/MAPILogoff.c
+++ b/mapi/MAPILogoff.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/mapi/MAPILogon.c b/mapi/MAPILogon.c
index 1ca2a33..95be7b7 100644
--- a/mapi/MAPILogon.c
+++ b/mapi/MAPILogon.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/mapi/MAPIReadMail.c b/mapi/MAPIReadMail.c
index a2a56e0..0062355 100644
--- a/mapi/MAPIReadMail.c
+++ b/mapi/MAPIReadMail.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/mapi/MAPISaveMail.c b/mapi/MAPISaveMail.c
index acea200..3f36067 100644
--- a/mapi/MAPISaveMail.c
+++ b/mapi/MAPISaveMail.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/mapi/MAPISendDocuments.c b/mapi/MAPISendDocuments.c
index afac744..80bb5e7 100644
--- a/mapi/MAPISendDocuments.c
+++ b/mapi/MAPISendDocuments.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/mapi/MAPISendMail.c b/mapi/MAPISendMail.c
index c18f00d..034fc68 100644
--- a/mapi/MAPISendMail.c
+++ b/mapi/MAPISendMail.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/mapi/Makefile.am b/mapi/Makefile.am
index f5ea85f..9682f7a 100644
--- a/mapi/Makefile.am
+++ b/mapi/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2001, 2002, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2001, 2002, 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/mapi/mapi.h b/mapi/mapi.h
index 3d7142f..4294b6f 100644
--- a/mapi/mapi.h
+++ b/mapi/mapi.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/messages/Makefile.am b/messages/Makefile.am
index fed19bb..c9edf35 100644
--- a/messages/Makefile.am
+++ b/messages/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/messages/messages.c b/messages/messages.c
index 2b1bff1..292f59c 100644
--- a/messages/messages.c
+++ b/messages/messages.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2004, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 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/messages/testsuite/Makefile.am b/messages/testsuite/Makefile.am
index 0d83dc7..80bb8ec 100644
--- a/messages/testsuite/Makefile.am
+++ b/messages/testsuite/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2002, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2002, 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/messages/testsuite/messages/test.exp
b/messages/testsuite/messages/test.exp
index 89461ef..8af2d04 100644
--- a/messages/testsuite/messages/test.exp
+++ b/messages/testsuite/messages/test.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007, 2009 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/mh/Makefile.am b/mh/Makefile.am
index cb01b67..2fdb487 100644
--- a/mh/Makefile.am
+++ b/mh/Makefile.am
@@ -1,6 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2001, 2002, 2003, 2007, 2009 Free Software Foundation, Inc.
+## Copyright (C) 2001, 2002, 2003, 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/mh/ali.c b/mh/ali.c
index ed2709e..851ee1a 100644
--- a/mh/ali.c
+++ b/mh/ali.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2004, 2005, 2006, 2007,
- 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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 published by
diff --git a/mh/anno.c b/mh/anno.c
index 397c0e8..83119c3 100644
--- a/mh/anno.c
+++ b/mh/anno.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/mh/burst.c b/mh/burst.c
index 4f93ed1..ae02501 100644
--- a/mh/burst.c
+++ b/mh/burst.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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 published by
diff --git a/mh/comp.c b/mh/comp.c
index f0a58e0..fc13db5 100644
--- a/mh/comp.c
+++ b/mh/comp.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2006, 2007,
- 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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 published by
diff --git a/mh/compcommon.c b/mh/compcommon.c
index 5d4b5ab..88d4285 100644
--- a/mh/compcommon.c
+++ b/mh/compcommon.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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 published by
diff --git a/mh/fmtcheck.c b/mh/fmtcheck.c
index 2a01440..3d50ae8 100644
--- a/mh/fmtcheck.c
+++ b/mh/fmtcheck.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003, 2005,
- 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 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 published by
diff --git a/mh/folder.c b/mh/folder.c
index f13e9bc..b13e373 100644
--- a/mh/folder.c
+++ b/mh/folder.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 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 published by
diff --git a/mh/forw.c b/mh/forw.c
index b302bec..196c794 100644
--- a/mh/forw.c
+++ b/mh/forw.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2006, 2007,
- 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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 published by
diff --git a/mh/inc.c b/mh/inc.c
index bf89e41..4dc9117 100644
--- a/mh/inc.c
+++ b/mh/inc.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 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 published by
diff --git a/mh/install-mh.c b/mh/install-mh.c
index 68d3c72..fd88631 100644
--- a/mh/install-mh.c
+++ b/mh/install-mh.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/mh/mailutils-mh.eli b/mh/mailutils-mh.eli
index f4d3736..c3bc6a5 100644
--- a/mh/mailutils-mh.eli
+++ b/mh/mailutils-mh.eli
@@ -1,6 +1,6 @@
;;;; -*- emacs-lisp -*-
;;;; GNU Mailutils -- a suite of utilities for electronic mail
-;;;; Copyright (C) 2003, 2007 Free Software Foundation, Inc.
+;;;; Copyright (C) 2003, 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 published by
diff --git a/mh/mark.c b/mh/mark.c
index 5e2b3a8..f5c6cd3 100644
--- a/mh/mark.c
+++ b/mh/mark.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2006, 2007, 2008,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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 published by
diff --git a/mh/mh.h b/mh/mh.h
index 0f9c600..005a533 100644
--- a/mh/mh.h
+++ b/mh/mh.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2004, 2005,
- 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2004, 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 published by
diff --git a/mh/mh_alias.l b/mh/mh_alias.l
index c38c6e3..926348c 100644
--- a/mh/mh_alias.l
+++ b/mh/mh_alias.l
@@ -1,6 +1,7 @@
%top {
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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 published by
diff --git a/mh/mh_alias.y b/mh/mh_alias.y
index 06b2cc5..c6e742b 100644
--- a/mh/mh_alias.y
+++ b/mh/mh_alias.y
@@ -1,6 +1,7 @@
%{
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2004, 2005, 2006, 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 published by
diff --git a/mh/mh_argp.c b/mh/mh_argp.c
index be989a2..fa5e514 100644
--- a/mh/mh_argp.c
+++ b/mh/mh_argp.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2005,
- 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 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 published by
diff --git a/mh/mh_ctx.c b/mh/mh_ctx.c
index c7b1a0e..1c2c951 100644
--- a/mh/mh_ctx.c
+++ b/mh/mh_ctx.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2004,
- 2005, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2004, 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 published by
diff --git a/mh/mh_fmtgram.y b/mh/mh_fmtgram.y
index a1360cb..2727331 100644
--- a/mh/mh_fmtgram.y
+++ b/mh/mh_fmtgram.y
@@ -1,7 +1,7 @@
%{
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2004,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2004, 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/mh/mh_format.c b/mh/mh_format.c
index f7980f4..868bb85 100644
--- a/mh/mh_format.c
+++ b/mh/mh_format.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2005, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 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 published by
diff --git a/mh/mh_format.h b/mh/mh_format.h
index 63f7abe..de4f30b 100644
--- a/mh/mh_format.h
+++ b/mh/mh_format.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2006, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2006, 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 published by
diff --git a/mh/mh_getopt.c b/mh/mh_getopt.c
index 4c9767a..dbd385a 100644
--- a/mh/mh_getopt.c
+++ b/mh/mh_getopt.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003, 2005,
- 2006, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2005, 2006, 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 published by
diff --git a/mh/mh_getopt.h b/mh/mh_getopt.h
index 45889a6..4815b12 100644
--- a/mh/mh_getopt.h
+++ b/mh/mh_getopt.h
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2002, 2005, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/mh/mh_global.c b/mh/mh_global.c
index a341dd7..4cf567d 100644
--- a/mh/mh_global.c
+++ b/mh/mh_global.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.
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/mh/mh_init.c b/mh/mh_init.c
index eecae2c..3dd69ad 100644
--- a/mh/mh_init.c
+++ b/mh/mh_init.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2005, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 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 published by
diff --git a/mh/mh_list.c b/mh/mh_list.c
index 99f369e..489d028 100644
--- a/mh/mh_list.c
+++ b/mh/mh_list.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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 published by
diff --git a/mh/mh_msgset.c b/mh/mh_msgset.c
index ab2ecfe..4376732 100644
--- a/mh/mh_msgset.c
+++ b/mh/mh_msgset.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2006,
- 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 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 published by
diff --git a/mh/mh_sequence.c b/mh/mh_sequence.c
index 6ec9ce9..a12407c 100644
--- a/mh/mh_sequence.c
+++ b/mh/mh_sequence.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/mh/mh_stream.c b/mh/mh_stream.c
index 83d952c..0e2e6fe 100644
--- a/mh/mh_stream.c
+++ b/mh/mh_stream.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2005,
- 2006, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2005, 2006, 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 published by
diff --git a/mh/mh_whatnow.c b/mh/mh_whatnow.c
index d2bb3f0..f4ecfea 100644
--- a/mh/mh_whatnow.c
+++ b/mh/mh_whatnow.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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 published by
diff --git a/mh/mh_whom.c b/mh/mh_whom.c
index 71d567c..df82cf8 100644
--- a/mh/mh_whom.c
+++ b/mh/mh_whom.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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 published by
diff --git a/mh/mhl.c b/mh/mhl.c
index 5181c9c..daf9910 100644
--- a/mh/mhl.c
+++ b/mh/mhl.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/mh/mhl.format b/mh/mhl.format
index 1246cd3..210d98d 100644
--- a/mh/mhl.format
+++ b/mh/mhl.format
@@ -1,7 +1,7 @@
; This is the default mhl.format file for Mailutils MH.
;
; GNU Mailutils -- a suite of utilities for electronic mail
-; Copyright (C) 2003 Free Software Foundation, Inc.
+; Copyright (C) 2003, 2010 Free Software Foundation, Inc.
; Distributed under GPL.
;
: -- using template mhl.format --
diff --git a/mh/mhn.c b/mh/mhn.c
index e763271..ac19f44 100644
--- a/mh/mhn.c
+++ b/mh/mhn.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2006, 2007, 2008,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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 published by
diff --git a/mh/mhparam.c b/mh/mhparam.c
index ff444f1..85a28b2 100644
--- a/mh/mhparam.c
+++ b/mh/mhparam.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/mh/mhpath.c b/mh/mhpath.c
index 483da34..c222fc7 100644
--- a/mh/mhpath.c
+++ b/mh/mhpath.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2002, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/mh/pick.c b/mh/pick.c
index b145dec..e88aec0 100644
--- a/mh/pick.c
+++ b/mh/pick.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2006, 2007, 2008,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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 published by
diff --git a/mh/pick.h b/mh/pick.h
index ba4f142..53c3fa3 100644
--- a/mh/pick.h
+++ b/mh/pick.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2005, 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 published by
diff --git a/mh/pick.y b/mh/pick.y
index b13afcc..7b7af20 100644
--- a/mh/pick.y
+++ b/mh/pick.y
@@ -1,7 +1,7 @@
%{
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2004, 2005, 2006, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 2004, 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 published by
diff --git a/mh/refile.c b/mh/refile.c
index 26b66a5..9cade4c 100644
--- a/mh/refile.c
+++ b/mh/refile.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- 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.
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/mh/repl.c b/mh/repl.c
index 712595f..af6b22d 100644
--- a/mh/repl.c
+++ b/mh/repl.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2002, 2003, 2005, 2006, 2007,
- 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2002, 2003, 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 published by
diff --git a/mh/replcomps b/mh/replcomps
index 1193c06..55c6a2d 100644
--- a/mh/replcomps
+++ b/mh/replcomps
@@ -1,7 +1,7 @@
%; This is the default replcomps file for Mailutils MH.
%;
%; GNU Mailutils -- a suite of utilities for electronic mail
-%; Copyright (C) 2003 Free Software Foundation, Inc.
+%; Copyright (C) 2003, 2010 Free Software Foundation, Inc.
%; Distributed under GPL.
%;
%(lit)%(formataddr %<{reply-to}%?{from}%?{sender}%?{return-path}%>)\
diff --git a/mh/replgroupcomps b/mh/replgroupcomps
index 9c2db39..e4786b3 100644
--- a/mh/replgroupcomps
+++ b/mh/replgroupcomps
@@ -1,7 +1,7 @@
%; This is the default replgroupcomps file for Mailutils MH.
%;
%; GNU Mailutils -- a suite of utilities for electronic mail
-%; Copyright (C) 2003 Free Software Foundation, Inc.
+%; Copyright (C) 2003, 2010 Free Software Foundation, Inc.
%; Distributed under GPL.
%;
%(lit)%(formataddr{mail-followup-to})\
diff --git a/mh/rmf.c b/mh/rmf.c
index ed1dc90..3aa7c80 100644
--- a/mh/rmf.c
+++ b/mh/rmf.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2002, 2005, 2006, 2007, 2008,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 2002, 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 published by
diff --git a/mh/rmm.c b/mh/rmm.c
index 665dbbd..68562d6 100644
--- a/mh/rmm.c
+++ b/mh/rmm.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2002, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/mh/scan.c b/mh/scan.c
index 238149c..cdffca0 100644
--- a/mh/scan.c
+++ b/mh/scan.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 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 published by
diff --git a/mh/send.c b/mh/send.c
index e3331fb..8118d7f 100644
--- a/mh/send.c
+++ b/mh/send.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2006, 2007, 2008,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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 published by
diff --git a/mh/sortm.c b/mh/sortm.c
index 8f5d467..06482f9 100644
--- a/mh/sortm.c
+++ b/mh/sortm.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2006, 2007, 2008,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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 published by
diff --git a/mh/whatnow.c b/mh/whatnow.c
index e45161d..7b3e666 100644
--- a/mh/whatnow.c
+++ b/mh/whatnow.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/mh/whom.c b/mh/whom.c
index eabe2fe..893fe8e 100644
--- a/mh/whom.c
+++ b/mh/whom.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/mimeview/Makefile.am b/mimeview/Makefile.am
index d46eb75..86bcdc8 100644
--- a/mimeview/Makefile.am
+++ b/mimeview/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2005, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2005, 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/mimeview/mimetypes.l b/mimeview/mimetypes.l
index 6a3c263..f1e0b90 100644
--- a/mimeview/mimetypes.l
+++ b/mimeview/mimetypes.l
@@ -1,6 +1,6 @@
%top {
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2005, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/mimeview/mimetypes.y b/mimeview/mimetypes.y
index 24e6ab8..4f50773 100644
--- a/mimeview/mimetypes.y
+++ b/mimeview/mimetypes.y
@@ -1,6 +1,6 @@
%{
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2005, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/mimeview/mimeview.c b/mimeview/mimeview.c
index 78e98cc..89e5ce8 100644
--- a/mimeview/mimeview.c
+++ b/mimeview/mimeview.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/mimeview/mimeview.h b/mimeview/mimeview.h
index 9716152..972f390 100644
--- a/mimeview/mimeview.h
+++ b/mimeview/mimeview.h
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2005, 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 published by
diff --git a/movemail/Makefile.am b/movemail/Makefile.am
index fabf2ab..7bc6228 100644
--- a/movemail/Makefile.am
+++ b/movemail/Makefile.am
@@ -1,7 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 1999, 2000, 2001, 2002, 2006,
-## 2007 Free Software Foundation, Inc.
+## Copyright (C) 1999, 2000, 2001, 2002, 2006, 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/movemail/movemail.c b/movemail/movemail.c
index 4129dea..c9ce1e1 100644
--- a/movemail/movemail.c
+++ b/movemail/movemail.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2006, 2007, 2008,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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 published by
diff --git a/mu-aux/Makefile.am b/mu-aux/Makefile.am
index 65f1ac2..e0ee233 100644
--- a/mu-aux/Makefile.am
+++ b/mu-aux/Makefile.am
@@ -1,6 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2002, 2003, 2005, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2002, 2003, 2005, 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/mu-aux/debugdef.m4 b/mu-aux/debugdef.m4
index b11b383..34be1cd 100644
--- a/mu-aux/debugdef.m4
+++ b/mu-aux/debugdef.m4
@@ -1,6 +1,6 @@
divert(-1)
# This file is part of Mailutils.
-# Copyright (C) 2006, 2007 Free Software Foundation, Inc.
+# Copyright (C) 2006, 2007, 2010 Free Software Foundation, Inc.
#
# Initially written by Sergey Poznyakoff for Mailfromd project.
#
diff --git a/mu-aux/generr.awk b/mu-aux/generr.awk
index b114b8d..5a4054b 100644
--- a/mu-aux/generr.awk
+++ b/mu-aux/generr.awk
@@ -1,5 +1,5 @@
# generr.awk -- Create error reporting sources for GNU Mailutils
-# Copyright (C) 2005, 2006, 2007 Free Software Foundation, Inc.
+# Copyright (C) 2005, 2006, 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/mu-aux/gylwrap b/mu-aux/gylwrap
index fee29a3..66dbdd0 100755
--- a/mu-aux/gylwrap
+++ b/mu-aux/gylwrap
@@ -1,6 +1,7 @@
#! /bin/sh
# ylwrap - wrapper for lex/yacc invocations.
-# Copyright 1996, 1997, 1998, 1999, 2007 Free Software Foundation, Inc.
+# Copyright 1996, 1997, 1998, 1999, 2007, 2010 Free Software Foundation,
+# Inc.
# Written by Tom Tromey <address@hidden>.
#
# This program is free software; you can redistribute it and/or modify
diff --git a/mu-aux/sqlmod.sh b/mu-aux/sqlmod.sh
index aba1ed3..bd4db04 100755
--- a/mu-aux/sqlmod.sh
+++ b/mu-aux/sqlmod.sh
@@ -1,6 +1,6 @@
#! /bin/sh
# This file is part of GNU Mailutils
-# Copyright (C) 2004 Free Software Foundation, Inc.
+# Copyright (C) 2004, 2010 Free Software Foundation, Inc.
#
# Written by Sergey Poznyakoff
#
diff --git a/mu-aux/texify.sed b/mu-aux/texify.sed
index 7317a84..468001a 100644
--- a/mu-aux/texify.sed
+++ b/mu-aux/texify.sed
@@ -1,4 +1,4 @@
-# Copyright (C) 2002, 2003, 2007 Free Software Foundation, Inc.
+# Copyright (C) 2002, 2003, 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/paths b/paths
index 957eaeb..45ad28e 100644
--- a/paths
+++ b/paths
@@ -1,6 +1,6 @@
# Paths for GNU Mailutils
#
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 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/po/POTFILES.in b/po/POTFILES.in
index 6b4a59e..1f3ad0a 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -1,6 +1,7 @@
#
# List of source files containing translatable strings.
-# Copyright (C) 2002,2003,2004,2005,2008,2009 Free Software Foundation, Inc.
+# Copyright (C) 2002, 2003, 2004, 2005, 2008, 2009, 2010 Free Software
+# Foundation, Inc.
#
comsat/action.c
diff --git a/pop3d/Makefile.am b/pop3d/Makefile.am
index 8a3418c..8a73ede 100644
--- a/pop3d/Makefile.am
+++ b/pop3d/Makefile.am
@@ -1,7 +1,7 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 1999, 2000, 2001, 2002, 2003, 2005,
-## 2007 Free Software Foundation, Inc.
+## Copyright (C) 1999, 2000, 2001, 2002, 2003, 2005, 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/pop3d/apop.c b/pop3d/apop.c
index 5835dd7..632bffb 100644
--- a/pop3d/apop.c
+++ b/pop3d/apop.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/pop3d/auth.c b/pop3d/auth.c
index 21a8f34..cb9c8a0 100644
--- a/pop3d/auth.c
+++ b/pop3d/auth.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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/pop3d/bulletin.c b/pop3d/bulletin.c
index 645f938..031ad49 100644
--- a/pop3d/bulletin.c
+++ b/pop3d/bulletin.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/pop3d/capa.c b/pop3d/capa.c
index e003542..688b09d 100644
--- a/pop3d/capa.c
+++ b/pop3d/capa.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2003, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2003, 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/pop3d/cmd.c b/pop3d/cmd.c
index 4243cb7..84d6b1e 100644
--- a/pop3d/cmd.c
+++ b/pop3d/cmd.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 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/pop3d/dele.c b/pop3d/dele.c
index 88dd834..f838f59 100644
--- a/pop3d/dele.c
+++ b/pop3d/dele.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 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/pop3d/expire.c b/pop3d/expire.c
index f2b75a9..da19ef3 100644
--- a/pop3d/expire.c
+++ b/pop3d/expire.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2005, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/pop3d/extra.c b/pop3d/extra.c
index 10b9812..60b009c 100644
--- a/pop3d/extra.c
+++ b/pop3d/extra.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2005,
- 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2003, 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/pop3d/list.c b/pop3d/list.c
index bd20969..b192875 100644
--- a/pop3d/list.c
+++ b/pop3d/list.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 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/pop3d/lock.c b/pop3d/lock.c
index e346f75..590b9e2 100644
--- a/pop3d/lock.c
+++ b/pop3d/lock.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/pop3d/logindelay.c b/pop3d/logindelay.c
index b6f86a3..9c8020d 100644
--- a/pop3d/logindelay.c
+++ b/pop3d/logindelay.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/pop3d/noop.c b/pop3d/noop.c
index daa823e..a3d8e64 100644
--- a/pop3d/noop.c
+++ b/pop3d/noop.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 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/pop3d/pop3d.c b/pop3d/pop3d.c
index 50621a2..8490fff 100644
--- a/pop3d/pop3d.c
+++ b/pop3d/pop3d.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004,
- 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 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/pop3d/pop3d.h b/pop3d/pop3d.h
index e1b3059..1c1c7d6 100644
--- a/pop3d/pop3d.h
+++ b/pop3d/pop3d.h
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2004, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 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/pop3d/popauth.c b/pop3d/popauth.c
index 4c52512..bc8c443 100644
--- a/pop3d/popauth.c
+++ b/pop3d/popauth.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/pop3d/quit.c b/pop3d/quit.c
index 1b1bfe1..94857cb 100644
--- a/pop3d/quit.c
+++ b/pop3d/quit.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/pop3d/retr.c b/pop3d/retr.c
index 2424677..9f4a222 100644
--- a/pop3d/retr.c
+++ b/pop3d/retr.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 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/pop3d/rset.c b/pop3d/rset.c
index de4aeb6..4a03acf 100644
--- a/pop3d/rset.c
+++ b/pop3d/rset.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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 published by
diff --git a/pop3d/signal.c b/pop3d/signal.c
index 56b1bb0..b12bca7 100644
--- a/pop3d/signal.c
+++ b/pop3d/signal.c
@@ -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/pop3d/stat.c b/pop3d/stat.c
index 238bb9e..0b4699c 100644
--- a/pop3d/stat.c
+++ b/pop3d/stat.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 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/pop3d/stls.c b/pop3d/stls.c
index a6d0d1e..0e35ba7 100644
--- a/pop3d/stls.c
+++ b/pop3d/stls.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2003, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2003, 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/pop3d/testsuite/Makefile.am b/pop3d/testsuite/Makefile.am
index 348157a..0b9982f 100644
--- a/pop3d/testsuite/Makefile.am
+++ b/pop3d/testsuite/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2002, 2007, 2008 Free Software Foundation, Inc.
+## Copyright (C) 2002, 2007, 2008, 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/pop3d/testsuite/lib/pop3d.exp b/pop3d/testsuite/lib/pop3d.exp
index 8b2893f..e75b24e 100644
--- a/pop3d/testsuite/lib/pop3d.exp
+++ b/pop3d/testsuite/lib/pop3d.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007, 2008 Free Software Foundation
+# Copyright (C) 2002, 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/pop3d/testsuite/pop3d.rcin b/pop3d/testsuite/pop3d.rcin
index cf16a79..def7629 100644
--- a/pop3d/testsuite/pop3d.rcin
+++ b/pop3d/testsuite/pop3d.rcin
@@ -1,5 +1,5 @@
# Configuration file for Mailutils Imap4d testsuite.
-# Copyright (C) 2008 Free Software Foundation, Inc.
+# Copyright (C) 2008, 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/pop3d/testsuite/pop3d/read.exp b/pop3d/testsuite/pop3d/read.exp
index a4a17fe..c748133 100644
--- a/pop3d/testsuite/pop3d/read.exp
+++ b/pop3d/testsuite/pop3d/read.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/pop3d/top.c b/pop3d/top.c
index b9e305b..64e9244 100644
--- a/pop3d/top.c
+++ b/pop3d/top.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2005, 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 published by
diff --git a/pop3d/uidl.c b/pop3d/uidl.c
index 7d31fdb..d52cc41 100644
--- a/pop3d/uidl.c
+++ b/pop3d/uidl.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 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/pop3d/user.c b/pop3d/user.c
index 39fb336..6cb130c 100644
--- a/pop3d/user.c
+++ b/pop3d/user.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2001, 2002, 2003, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001, 2002, 2003, 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/python/Makefile.am b/python/Makefile.am
index 6977e5b..fcbb7a2 100644
--- a/python/Makefile.am
+++ b/python/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2009 Free Software Foundation, Inc.
+## Copyright (C) 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/python/libmu_py/Makefile.am b/python/libmu_py/Makefile.am
index 5f4238d..4051143 100644
--- a/python/libmu_py/Makefile.am
+++ b/python/libmu_py/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2009 Free Software Foundation, Inc.
+## Copyright (C) 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/python/libmu_py/address.c b/python/libmu_py/address.c
index ebba61f..611de20 100644
--- a/python/libmu_py/address.c
+++ b/python/libmu_py/address.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/attribute.c b/python/libmu_py/attribute.c
index e1ff76d..df51fa3 100644
--- a/python/libmu_py/attribute.c
+++ b/python/libmu_py/attribute.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/auth.c b/python/libmu_py/auth.c
index 1cd9511..6f342bc 100644
--- a/python/libmu_py/auth.c
+++ b/python/libmu_py/auth.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/body.c b/python/libmu_py/body.c
index 4cd8603..81606ea 100644
--- a/python/libmu_py/body.c
+++ b/python/libmu_py/body.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/c_api.c b/python/libmu_py/c_api.c
index 8b26a4b..8914b20 100644
--- a/python/libmu_py/c_api.c
+++ b/python/libmu_py/c_api.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/debug.c b/python/libmu_py/debug.c
index 78b5056..ac79d35 100644
--- a/python/libmu_py/debug.c
+++ b/python/libmu_py/debug.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/envelope.c b/python/libmu_py/envelope.c
index 90f6969..617b398 100644
--- a/python/libmu_py/envelope.c
+++ b/python/libmu_py/envelope.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/error.c b/python/libmu_py/error.c
index 917303b..77013c9 100644
--- a/python/libmu_py/error.c
+++ b/python/libmu_py/error.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/filter.c b/python/libmu_py/filter.c
index 5ed87b9..01c53b3 100644
--- a/python/libmu_py/filter.c
+++ b/python/libmu_py/filter.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/folder.c b/python/libmu_py/folder.c
index 964abf1..4ba9ddf 100644
--- a/python/libmu_py/folder.c
+++ b/python/libmu_py/folder.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/header.c b/python/libmu_py/header.c
index eebee94..3af10e0 100644
--- a/python/libmu_py/header.c
+++ b/python/libmu_py/header.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/libmu_py.c b/python/libmu_py/libmu_py.c
index 35088b0..bf6da0c 100644
--- a/python/libmu_py/libmu_py.c
+++ b/python/libmu_py/libmu_py.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/libmu_py.h b/python/libmu_py/libmu_py.h
index 0a4df40..21dc560 100644
--- a/python/libmu_py/libmu_py.h
+++ b/python/libmu_py/libmu_py.h
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/list.c b/python/libmu_py/list.c
index 2d98517..a7a9818 100644
--- a/python/libmu_py/list.c
+++ b/python/libmu_py/list.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/mailbox.c b/python/libmu_py/mailbox.c
index 0d4a4ab..b6eea4f 100644
--- a/python/libmu_py/mailbox.c
+++ b/python/libmu_py/mailbox.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/mailcap.c b/python/libmu_py/mailcap.c
index 5c4900b..8f65cbe 100644
--- a/python/libmu_py/mailcap.c
+++ b/python/libmu_py/mailcap.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/mailer.c b/python/libmu_py/mailer.c
index 6581ed4..968ea02 100644
--- a/python/libmu_py/mailer.c
+++ b/python/libmu_py/mailer.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/message.c b/python/libmu_py/message.c
index de36e16..49827c2 100644
--- a/python/libmu_py/message.c
+++ b/python/libmu_py/message.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/mime.c b/python/libmu_py/mime.c
index 55939ed..fd9e1a0 100644
--- a/python/libmu_py/mime.c
+++ b/python/libmu_py/mime.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/nls.c b/python/libmu_py/nls.c
index 9b3aba0..2d54c5c 100644
--- a/python/libmu_py/nls.c
+++ b/python/libmu_py/nls.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/registrar.c b/python/libmu_py/registrar.c
index 9198509..88ef162 100644
--- a/python/libmu_py/registrar.c
+++ b/python/libmu_py/registrar.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/script.c b/python/libmu_py/script.c
index e728544..da49146 100644
--- a/python/libmu_py/script.c
+++ b/python/libmu_py/script.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/secret.c b/python/libmu_py/secret.c
index 8f6ee78..0033d02 100644
--- a/python/libmu_py/secret.c
+++ b/python/libmu_py/secret.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/sieve.c b/python/libmu_py/sieve.c
index d0b8bdb..9c38fa2 100644
--- a/python/libmu_py/sieve.c
+++ b/python/libmu_py/sieve.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/stream.c b/python/libmu_py/stream.c
index ea2080a..0ef7385 100644
--- a/python/libmu_py/stream.c
+++ b/python/libmu_py/stream.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/url.c b/python/libmu_py/url.c
index af82f50..2b8a7dc 100644
--- a/python/libmu_py/url.c
+++ b/python/libmu_py/url.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/libmu_py/util.c b/python/libmu_py/util.c
index e3a2087..0741c25 100644
--- a/python/libmu_py/util.c
+++ b/python/libmu_py/util.c
@@ -1,6 +1,6 @@
/*
GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009, 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/python/mailutils/Makefile.am b/python/mailutils/Makefile.am
index 61a7f8e..5cf261d 100644
--- a/python/mailutils/Makefile.am
+++ b/python/mailutils/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2009 Free Software Foundation, Inc.
+## Copyright (C) 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/python/mailutils/__init__.py b/python/mailutils/__init__.py
index 490fc30..bea528a 100644
--- a/python/mailutils/__init__.py
+++ b/python/mailutils/__init__.py
@@ -1,5 +1,5 @@
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 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/python/mailutils/address.py b/python/mailutils/address.py
index 0bb7636..759b03c 100644
--- a/python/mailutils/address.py
+++ b/python/mailutils/address.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/attribute.py b/python/mailutils/attribute.py
index affdb5c..45fd710 100644
--- a/python/mailutils/attribute.py
+++ b/python/mailutils/attribute.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/auth.py b/python/mailutils/auth.py
index 8095aa0..8b68edc 100644
--- a/python/mailutils/auth.py
+++ b/python/mailutils/auth.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/body.py b/python/mailutils/body.py
index b47285e..02af50b 100644
--- a/python/mailutils/body.py
+++ b/python/mailutils/body.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/debug.py b/python/mailutils/debug.py
index 629b10e..141dd8a 100644
--- a/python/mailutils/debug.py
+++ b/python/mailutils/debug.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/envelope.py b/python/mailutils/envelope.py
index 3f03bc7..86926e3 100644
--- a/python/mailutils/envelope.py
+++ b/python/mailutils/envelope.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/error.py b/python/mailutils/error.py
index a9d809e..4ef0b47 100644
--- a/python/mailutils/error.py
+++ b/python/mailutils/error.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/filter.py b/python/mailutils/filter.py
index 22681af..e3242aa 100644
--- a/python/mailutils/filter.py
+++ b/python/mailutils/filter.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/folder.py b/python/mailutils/folder.py
index 9d1c162..738f1ff 100644
--- a/python/mailutils/folder.py
+++ b/python/mailutils/folder.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/header.py b/python/mailutils/header.py
index 8e06c9a..78bfb2d 100644
--- a/python/mailutils/header.py
+++ b/python/mailutils/header.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/mailbox.py b/python/mailutils/mailbox.py
index 1eda85f..1bde2c9 100644
--- a/python/mailutils/mailbox.py
+++ b/python/mailutils/mailbox.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/mailcap.py b/python/mailutils/mailcap.py
index 14db053..a555364 100644
--- a/python/mailutils/mailcap.py
+++ b/python/mailutils/mailcap.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/mailer.py b/python/mailutils/mailer.py
index 65704f8..19cf665 100644
--- a/python/mailutils/mailer.py
+++ b/python/mailutils/mailer.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/message.py b/python/mailutils/message.py
index 2e8fd7b..0f4744a 100644
--- a/python/mailutils/message.py
+++ b/python/mailutils/message.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/mime.py b/python/mailutils/mime.py
index 6b67c48..9937f66 100644
--- a/python/mailutils/mime.py
+++ b/python/mailutils/mime.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/nls.py b/python/mailutils/nls.py
index 475bf93..90eacb2 100644
--- a/python/mailutils/nls.py
+++ b/python/mailutils/nls.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/registrar.py b/python/mailutils/registrar.py
index cb45708..bdfa270 100644
--- a/python/mailutils/registrar.py
+++ b/python/mailutils/registrar.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/secret.py b/python/mailutils/secret.py
index b28934b..51e91ba 100644
--- a/python/mailutils/secret.py
+++ b/python/mailutils/secret.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/sieve.py b/python/mailutils/sieve.py
index 38cbf6a..36c5263 100644
--- a/python/mailutils/sieve.py
+++ b/python/mailutils/sieve.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/stream.py b/python/mailutils/stream.py
index e1b7093..8a2fef2 100644
--- a/python/mailutils/stream.py
+++ b/python/mailutils/stream.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/url.py b/python/mailutils/url.py
index 286575d..3efeba0 100644
--- a/python/mailutils/url.py
+++ b/python/mailutils/url.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/python/mailutils/util.py b/python/mailutils/util.py
index 648b9f3..1bf0dc7 100644
--- a/python/mailutils/util.py
+++ b/python/mailutils/util.py
@@ -1,6 +1,6 @@
#
# GNU Mailutils -- a suite of utilities for electronic mail
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 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/readmsg/Makefile.am b/readmsg/Makefile.am
index 7a5ba0d..d22141f 100644
--- a/readmsg/Makefile.am
+++ b/readmsg/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/readmsg/msglist.c b/readmsg/msglist.c
index 6bbd3b5..267ca55 100644
--- a/readmsg/msglist.c
+++ b/readmsg/msglist.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2005, 2007,
- 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 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/readmsg/readmsg.c b/readmsg/readmsg.c
index c70ed8e..72406b5 100644
--- a/readmsg/readmsg.c
+++ b/readmsg/readmsg.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2004, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 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/readmsg/readmsg.h b/readmsg/readmsg.h
index 0bd5188..f1bd87c 100644
--- a/readmsg/readmsg.h
+++ b/readmsg/readmsg.h
@@ -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/readmsg/testsuite/Makefile.am b/readmsg/testsuite/Makefile.am
index 5748598..56b7a01 100644
--- a/readmsg/testsuite/Makefile.am
+++ b/readmsg/testsuite/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2002, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2002, 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/readmsg/testsuite/readmsg/test.exp
b/readmsg/testsuite/readmsg/test.exp
index 2492648..c789962 100644
--- a/readmsg/testsuite/readmsg/test.exp
+++ b/readmsg/testsuite/readmsg/test.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007, 2009 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/Makefile.am b/sieve/Makefile.am
index 99fa75a..41eee59 100644
--- a/sieve/Makefile.am
+++ b/sieve/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2001, 2002, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2001, 2002, 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/sieve/examples/Makefile b/sieve/examples/Makefile
deleted file mode 100644
index a15819b..0000000
--- a/sieve/examples/Makefile
+++ /dev/null
@@ -1,31 +0,0 @@
-# cmu-sieve/sv/Makefile
-
-default: test-complex
-
-HOME :=$(shell pwd)
-
-export HOME
-
-.PHONY: test-complex
-test-complex:
- rm -f mbox.complex.*
- grep -v X-UID < mbox.complex > mbox.complex.in
- HOME=`pwd` ../sieve -k -f mbox.complex.in t-complex.sv
-
-test: INBOX
- ./Test 2>&1 | tee test.out
-
-test-compile: ../sieve
- for s in ex-*.sv; do echo "Compiling: $$s"; ../sieve -c $$s; done
-
-.PHONY: INBOX
-INBOX:
- cp INBOX.orig INBOX
-
-t-%: t-%.sv INBOX ../sieve
- ../sieve -vvv -f INBOX $<
-
-.PHONY: ../sieve
-../sieve:
- make -C .. sieve
-
diff --git a/sieve/examples/ex-1.10.2.sv b/sieve/examples/ex-1.10.2.sv
index 32fd46e..62a6075 100644
--- a/sieve/examples/ex-1.10.2.sv
+++ b/sieve/examples/ex-1.10.2.sv
@@ -1,5 +1,6 @@
-if size :under 500K {
+if size :under 500K
+ {
discard;
-}
+ }
keep;
diff --git a/sieve/examples/ex-2.3a.sv b/sieve/examples/ex-2.3a.sv
index 9aa4690..0168f3b 100644
--- a/sieve/examples/ex-2.3a.sv
+++ b/sieve/examples/ex-2.3a.sv
@@ -1,3 +1,3 @@
- if size :over 550 { # this is a comment
- discard;
- }
+if size :over 550 { # this is a comment
+ discard;
+}
diff --git a/sieve/examples/ex-2.5.1.sv b/sieve/examples/ex-2.5.1.sv
index 921b465..3af10a1 100644
--- a/sieve/examples/ex-2.5.1.sv
+++ b/sieve/examples/ex-2.5.1.sv
@@ -1,13 +1,13 @@
- require "fileinto";
-
- if anyof (
- not exists ["From", "Date"],
- header :contains "from" "address@hidden"
- )
+require "fileinto";
+
+if anyof (
+ not exists ["From", "Date"],
+ header :contains "from" "address@hidden"
+ )
{
- discard;
+ discard;
}
- if header :contains "from" "coyote"
+if header :contains "from" "coyote"
{
- fileinto "popbox"; # "pop://sam:address@hidden";
+ fileinto "popbox"; # "pop://sam:address@hidden";
}
diff --git a/sieve/examples/ex-2.7.3.sv b/sieve/examples/ex-2.7.3.sv
index 7aa2b7d..a73a58b 100644
--- a/sieve/examples/ex-2.7.3.sv
+++ b/sieve/examples/ex-2.7.3.sv
@@ -1,5 +1,6 @@
- if header :contains :comparator "i;octet" "Subject"
- "MAKE MONEY FAST" {
- discard;
- }
+if header :contains :comparator "i;octet" "Subject"
+ "MAKE MONEY FAST"
+ {
+ discard;
+ }
diff --git a/sieve/examples/ex-3.1a.sv b/sieve/examples/ex-3.1a.sv
index a038e7c..d3fc145 100644
--- a/sieve/examples/ex-3.1a.sv
+++ b/sieve/examples/ex-3.1a.sv
@@ -1,8 +1,14 @@
- require "fileinto";
- if header :contains "from" "coyote" {
- discard;
- } elsif header :contains ["subject"] ["$$$"] {
- discard;
- } else {
- fileinto "INBOX";
- }
+require "fileinto";
+
+if header :contains "from" "coyote"
+ {
+ discard;
+ }
+elsif header :contains ["subject"] ["$$$"]
+ {
+ discard;
+ }
+else
+ {
+ fileinto "INBOX";
+ }
diff --git a/sieve/examples/ex-3.1b.sv b/sieve/examples/ex-3.1b.sv
index e864a90..03ecc47 100644
--- a/sieve/examples/ex-3.1b.sv
+++ b/sieve/examples/ex-3.1b.sv
@@ -1,9 +1,14 @@
require [ "redirect" ];
- if header :contains ["From"] ["coyote"] {
- redirect "address@hidden";
- } elsif header :contains "Subject" "$$$" {
- redirect "address@hidden";
- } else {
- redirect "address@hidden";
- }
+if header :contains ["From"] ["coyote"]
+ {
+ redirect "address@hidden";
+ }
+elsif header :contains "Subject" "$$$"
+ {
+ redirect "address@hidden";
+ }
+else
+ {
+ redirect "address@hidden";
+ }
diff --git a/sieve/examples/ex-3.2.sv b/sieve/examples/ex-3.2.sv
index c6ea1af..6ae85ae 100644
--- a/sieve/examples/ex-3.2.sv
+++ b/sieve/examples/ex-3.2.sv
@@ -1,4 +1,4 @@
- require ["fileinto", "reject"];
- require "fileinto";
+require ["fileinto", "reject"];
+require "fileinto";
# require "vacation";
diff --git a/sieve/examples/ex-4.1.sv b/sieve/examples/ex-4.1.sv
index d9475ac..0bff57f 100644
--- a/sieve/examples/ex-4.1.sv
+++ b/sieve/examples/ex-4.1.sv
@@ -1,8 +1,9 @@
require "reject";
-if header :contains "from" "address@hidden" {
- reject
- "I am not taking mail from you, and I don't want
- your birdseed, either!";
-}
+if header :contains "from" "address@hidden"
+ {
+ reject
+ "I am not taking mail from you, and I don't want
+ your birdseed, either!";
+ }
diff --git a/sieve/examples/ex-4.2.sv b/sieve/examples/ex-4.2.sv
index 53f3728..ec96e76 100644
--- a/sieve/examples/ex-4.2.sv
+++ b/sieve/examples/ex-4.2.sv
@@ -1,5 +1,6 @@
- require "fileinto";
- if header :contains ["from"] "coyote" {
- fileinto "INBOX.harassment";
- }
+require "fileinto";
+if header :contains ["from"] "coyote"
+ {
+ fileinto "INBOX.harassment";
+ }
diff --git a/sieve/examples/ex-4.4a.sv b/sieve/examples/ex-4.4a.sv
index d042bbd..0e5ae22 100644
--- a/sieve/examples/ex-4.4a.sv
+++ b/sieve/examples/ex-4.4a.sv
@@ -1,2 +1,2 @@
- if size :under 1M { keep; } else { discard; }
+if size :under 1M { keep; } else { discard; }
diff --git a/sieve/examples/ex-4.4b.sv b/sieve/examples/ex-4.4b.sv
index 923adb2..7f0e196 100644
--- a/sieve/examples/ex-4.4b.sv
+++ b/sieve/examples/ex-4.4b.sv
@@ -1,3 +1,2 @@
-
- if not size :under 1M { discard; }
+if not size :under 1M { discard; }
diff --git a/sieve/examples/ex-4.5.sv b/sieve/examples/ex-4.5.sv
index 46dd8c8..6cef88b 100644
--- a/sieve/examples/ex-4.5.sv
+++ b/sieve/examples/ex-4.5.sv
@@ -1,3 +1,4 @@
- if header :contains ["from"] ["address@hidden"] {
- discard;
- }
+if header :contains ["from"] ["address@hidden"]
+ {
+ discard;
+ }
diff --git a/sieve/examples/ex-5.1.sv b/sieve/examples/ex-5.1.sv
index 793e2d1..689bd58 100644
--- a/sieve/examples/ex-5.1.sv
+++ b/sieve/examples/ex-5.1.sv
@@ -1,4 +1,5 @@
-if address :is :all "from" "address@hidden" {
- discard;
-}
+if address :is :all "from" "address@hidden"
+ {
+ discard;
+ }
diff --git a/sieve/examples/ex-5.7.sv b/sieve/examples/ex-5.7.sv
index 2d18486..4065188 100644
--- a/sieve/examples/ex-5.7.sv
+++ b/sieve/examples/ex-5.7.sv
@@ -3,11 +3,13 @@
# These should be true, then, and not affect the test mbox.
-if header :is ["X-Caffeine"] [""] {
+if header :is ["X-Caffeine"] [""]
+ {
discard;
-}
+ }
-if not header :contains ["X-Caffeine"] [""] {
+if not header :contains ["X-Caffeine"] [""]
+ {
discard;
-}
+ }
diff --git a/sieve/examples/ex-9.sv b/sieve/examples/ex-9.sv
index 99ac799..d11523a 100644
--- a/sieve/examples/ex-9.sv
+++ b/sieve/examples/ex-9.sv
@@ -9,7 +9,7 @@ require ["fileinto", "reject"];
# "stuffed" to three)
#
if size :over 1M
-{
+ {
reject text:
Please do not send me large attachments.
Put your file on a server and send me the URL.
@@ -18,22 +18,22 @@ Thank you.
.
;
stop;
-}
+ }
#
# Handle messages from known mailing lists
# Move messages from IETF filter discussion list to filter folder
#
if header :is "Sender" "address@hidden"
-{
+ {
fileinto "filter"; # move to "filter" folder
-}
+ }
#
# Keep all messages to or from people in my company
#
elsif address :domain :is ["From", "To"] "example.com"
-{
+ {
keep; # keep in "In" folder
-}
+ }
#
# Try and catch unsolicited email. If a message is not to me,
@@ -45,15 +45,15 @@ elsif anyof (
header :matches
"subject" ["*make*money*fast*", "*university*dipl*mas*"]
)
-{
- # If message header does not contain my address,
- # it's from a list.
- fileinto "spam"; # move to "spam" folder
-}
+ {
+ # If message header does not contain my address,
+ # it's from a list.
+ fileinto "spam"; # move to "spam" folder
+ }
else
-{
- # Move all other (non-company) mail to "personal"
- # folder.
- fileinto "personal";
-}
+ {
+ # Move all other (non-company) mail to "personal"
+ # folder.
+ fileinto "personal";
+ }
diff --git a/sieve/examples/ex-save-all.sv b/sieve/examples/ex-save-all.sv
index 0b09010..17cda14 100644
--- a/sieve/examples/ex-save-all.sv
+++ b/sieve/examples/ex-save-all.sv
@@ -1,4 +1,3 @@
-
require "fileinto";
fileinto "./_save-all.mbox";
diff --git a/sieve/examples/example.sv b/sieve/examples/example.sv
index 466d4ee..de8a597 100644
--- a/sieve/examples/example.sv
+++ b/sieve/examples/example.sv
@@ -1,18 +1,21 @@
# Example sieve script.
- require [ "fileinto", "redirect" ];
+require [ "fileinto", "redirect" ];
- if size :over 20 {
- fileinto "/home/sam/p/gnu/mailutils/cmu-sieve/sv/inbox";
+if size :over 20
+ {
+ fileinto "/home/sam/p/gnu/mailutils/cmu-sieve/sv/inbox";
}
- if address :domain :is "to" "uwaterloo.ca" {
- redirect "address@hidden";
+if address :domain :is "to" "uwaterloo.ca"
+ {
+ redirect "address@hidden";
}
- if header :is "Status" "RO" {
- redirect "address@hidden";
+if header :is "Status" "RO"
+ {
+ redirect "address@hidden";
}
- keep;
+keep;
diff --git a/sieve/examples/exn-5.4.sv b/sieve/examples/exn-5.4.sv
index 2bd5b9a..862ac6d 100644
--- a/sieve/examples/exn-5.4.sv
+++ b/sieve/examples/exn-5.4.sv
@@ -1,5 +1,6 @@
require "envelope";
-if envelope :all :is "from" "address@hidden" {
- discard;
-}
+if envelope :all :is "from" "address@hidden"
+ {
+ discard;
+ }
diff --git a/sieve/examples/t-complex.sv b/sieve/examples/t-complex.sv
index b6519a3..f15c806 100644
--- a/sieve/examples/t-complex.sv
+++ b/sieve/examples/t-complex.sv
@@ -4,62 +4,62 @@ require [ "comparator-i;octet", "comparator-i;ascii-casemap"
];
# Idiom to determine existence of a header.
if header :contains [ "x-sweetheart", "x-unlikely" ] ""
-{
- stop;
-}
+ {
+ stop;
+ }
if header :is "return-PATH" "<>"
-{
- fileinto "mbox.complex.null-path";
-}
+ {
+ fileinto "mbox.complex.null-path";
+ }
if header :matches "newsgroups" "comp.os.*"
-{
- fileinto "mbox.complex.news-comp-os";
-}
+ {
+ fileinto "mbox.complex.news-comp-os";
+ }
elsif exists "newsgroups"
-{
- fileinto "mbox.complex.news";
-}
+ {
+ fileinto "mbox.complex.news";
+ }
if size :over 10000
-{
- fileinto "mbox.complex.large";
-# redirect "address@hidden";
-}
+ {
+ fileinto "mbox.complex.large";
+ # redirect "address@hidden";
+ }
elsif allof ( size :over 2000 , size :under 10000 )
-{
- fileinto "mbox.complex.largeish";
-}
+ {
+ fileinto "mbox.complex.largeish";
+ }
elsif size :over 100
-{
- fileinto "mbox.complex.smallish";
-}
+ {
+ fileinto "mbox.complex.smallish";
+ }
else
-{
-# Too small to bother reading.
- discard;
-}
+ {
+ # Too small to bother reading.
+ discard;
+ }
if exists "x-redirect"
-{
- redirect "address@hidden";
-}
+ {
+ redirect "address@hidden";
+ }
# if header :contains ["to", "cc"] "address@hidden"
-# {
-# fileinto "./mbox.mailutils.out";
-# keep;
+# {
+# fileinto "./mbox.mailutils.out";
+# keep;
# if header :contains ["to", "cc"] "address@hidden"
-# {
-# fileinto "./mbox.mailutils.out";
-# keep;
-# }
+# {
+# fileinto "./mbox.mailutils.out";
+# keep;
+# }
# else
-# {
-# stop;
-# discard;
-# }
+# {
+# stop;
+# discard;
+# }
# Keep (don't delete) messages, even if filed into another mailbox.
keep;
diff --git a/sieve/examples/t-exists.sv b/sieve/examples/t-exists.sv
index 0f3b9d2..5cd0887 100644
--- a/sieve/examples/t-exists.sv
+++ b/sieve/examples/t-exists.sv
@@ -1,5 +1,5 @@
if exists "X"
-{
+ {
keep;
-}
+ }
diff --git a/sieve/examples/t-fileinto.sv b/sieve/examples/t-fileinto.sv
index d0d5332..2e3bbdc 100644
--- a/sieve/examples/t-fileinto.sv
+++ b/sieve/examples/t-fileinto.sv
@@ -4,11 +4,11 @@ if allof(
size :over 10 ,
exists "x-caffeine"
)
-{
- fileinto "jetfuel";
-}
+ {
+ fileinto "jetfuel";
+ }
else
-{
- fileinto "decaf";
-}
+ {
+ fileinto "decaf";
+ }
diff --git a/sieve/examples/t-mailutils.sv b/sieve/examples/t-mailutils.sv
index 7d4f372..234bfe0 100644
--- a/sieve/examples/t-mailutils.sv
+++ b/sieve/examples/t-mailutils.sv
@@ -1,7 +1,7 @@
require "fileinto";
if header :contains ["to", "cc"] "address@hidden"
-{
- fileinto "=l.mailutils";
-}
+ {
+ fileinto "=l.mailutils";
+ }
diff --git a/sieve/sieve.c b/sieve/sieve.c
index 76b7c6c..5cb55f8 100644
--- a/sieve/sieve.c
+++ b/sieve/sieve.c
@@ -1,6 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 1999, 2000, 2001, 2002, 2003,
- 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 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 published by
diff --git a/sieve/testsuite/Makefile.am b/sieve/testsuite/Makefile.am
index 002c7dc..e3b77ae 100644
--- a/sieve/testsuite/Makefile.am
+++ b/sieve/testsuite/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2002, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2002, 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/sieve/testsuite/Redirect b/sieve/testsuite/Redirect
index 145fc72..806d86f 100644
--- a/sieve/testsuite/Redirect
+++ b/sieve/testsuite/Redirect
@@ -1,5 +1,5 @@
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/Reject b/sieve/testsuite/Reject
index 260d27e..d8ed5e8 100644
--- a/sieve/testsuite/Reject
+++ b/sieve/testsuite/Reject
@@ -1,5 +1,5 @@
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/lib/sieve.exp b/sieve/testsuite/lib/sieve.exp
index e2defb0..83e8e77 100644
--- a/sieve/testsuite/lib/sieve.exp
+++ b/sieve/testsuite/lib/sieve.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/scripts/addr_is_all.sv
b/sieve/testsuite/scripts/addr_is_all.sv
index 6b5ea14..9b41867 100644
--- a/sieve/testsuite/scripts/addr_is_all.sv
+++ b/sieve/testsuite/scripts/addr_is_all.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if address :is :all "From" "address@hidden" {
diff --git a/sieve/testsuite/scripts/addr_is_domain.sv
b/sieve/testsuite/scripts/addr_is_domain.sv
index b6f81f5..5c463de 100644
--- a/sieve/testsuite/scripts/addr_is_domain.sv
+++ b/sieve/testsuite/scripts/addr_is_domain.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if address :is :domain "From" "desert.example.org" {
diff --git a/sieve/testsuite/scripts/addr_is_local.sv
b/sieve/testsuite/scripts/addr_is_local.sv
index 09b9953..db9c6fe 100644
--- a/sieve/testsuite/scripts/addr_is_local.sv
+++ b/sieve/testsuite/scripts/addr_is_local.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if address :is :localpart "From" "youcouldberich!" {
diff --git a/sieve/testsuite/scripts/addr_matches.sv
b/sieve/testsuite/scripts/addr_matches.sv
index afadc23..90936b3 100644
--- a/sieve/testsuite/scripts/addr_matches.sv
+++ b/sieve/testsuite/scripts/addr_matches.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if address :matches :all "From" "*invalid" {
diff --git a/sieve/testsuite/scripts/address.sv
b/sieve/testsuite/scripts/address.sv
index 6b5ea14..9b41867 100644
--- a/sieve/testsuite/scripts/address.sv
+++ b/sieve/testsuite/scripts/address.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if address :is :all "From" "address@hidden" {
diff --git a/sieve/testsuite/scripts/allof00.sv
b/sieve/testsuite/scripts/allof00.sv
index 59c6e63..ff58f38 100644
--- a/sieve/testsuite/scripts/allof00.sv
+++ b/sieve/testsuite/scripts/allof00.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if allof(false,false) {
diff --git a/sieve/testsuite/scripts/allof01.sv
b/sieve/testsuite/scripts/allof01.sv
index 04838b3..04089b7 100644
--- a/sieve/testsuite/scripts/allof01.sv
+++ b/sieve/testsuite/scripts/allof01.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if allof(false,true) {
diff --git a/sieve/testsuite/scripts/allof11.sv
b/sieve/testsuite/scripts/allof11.sv
index d9b328a..7d9818a 100644
--- a/sieve/testsuite/scripts/allof11.sv
+++ b/sieve/testsuite/scripts/allof11.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if allof(true,true) {
diff --git a/sieve/testsuite/scripts/anyof00.sv
b/sieve/testsuite/scripts/anyof00.sv
index d81fca2..595ea6a 100644
--- a/sieve/testsuite/scripts/anyof00.sv
+++ b/sieve/testsuite/scripts/anyof00.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if anyof(false,false) {
diff --git a/sieve/testsuite/scripts/anyof01.sv
b/sieve/testsuite/scripts/anyof01.sv
index b0e9c78..0bb3e23 100644
--- a/sieve/testsuite/scripts/anyof01.sv
+++ b/sieve/testsuite/scripts/anyof01.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if anyof(false,true) {
diff --git a/sieve/testsuite/scripts/anyof11.sv
b/sieve/testsuite/scripts/anyof11.sv
index 22937d1..5c5217f 100644
--- a/sieve/testsuite/scripts/anyof11.sv
+++ b/sieve/testsuite/scripts/anyof11.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if anyof(true,true) {
diff --git a/sieve/testsuite/scripts/discard.sv
b/sieve/testsuite/scripts/discard.sv
index df48f79..5a6718b 100644
--- a/sieve/testsuite/scripts/discard.sv
+++ b/sieve/testsuite/scripts/discard.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
discard;
diff --git a/sieve/testsuite/scripts/envelope1.sv
b/sieve/testsuite/scripts/envelope1.sv
index c3db45d..6e1ef89 100644
--- a/sieve/testsuite/scripts/envelope1.sv
+++ b/sieve/testsuite/scripts/envelope1.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if envelope "from" "address@hidden" {
diff --git a/sieve/testsuite/scripts/exists1.sv
b/sieve/testsuite/scripts/exists1.sv
index d61a3c2..fd64a4b 100644
--- a/sieve/testsuite/scripts/exists1.sv
+++ b/sieve/testsuite/scripts/exists1.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if exists "X-Caffeine" {
diff --git a/sieve/testsuite/scripts/exists2.sv
b/sieve/testsuite/scripts/exists2.sv
index 0a22e0c..2b081a4 100644
--- a/sieve/testsuite/scripts/exists2.sv
+++ b/sieve/testsuite/scripts/exists2.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if exists ["X-Caffeine", "From"] {
diff --git a/sieve/testsuite/scripts/exists3.sv
b/sieve/testsuite/scripts/exists3.sv
index 0e28548..628be7b 100644
--- a/sieve/testsuite/scripts/exists3.sv
+++ b/sieve/testsuite/scripts/exists3.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if exists ["X-Caffeine", "X-Status"] {
diff --git a/sieve/testsuite/scripts/false.sv b/sieve/testsuite/scripts/false.sv
index 99f2234..eeeda39 100644
--- a/sieve/testsuite/scripts/false.sv
+++ b/sieve/testsuite/scripts/false.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if false {
diff --git a/sieve/testsuite/scripts/fileinto.sv
b/sieve/testsuite/scripts/fileinto.sv
index 4ba4167..95fb702 100644
--- a/sieve/testsuite/scripts/fileinto.sv
+++ b/sieve/testsuite/scripts/fileinto.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation.
+# Copyright (C) 2002, 2007, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
require "fileinto";
diff --git a/sieve/testsuite/scripts/header-mime.sv
b/sieve/testsuite/scripts/header-mime.sv
index f68eabe..33a0912 100644
--- a/sieve/testsuite/scripts/header-mime.sv
+++ b/sieve/testsuite/scripts/header-mime.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if header :mime :is "Content-Description" "How doth" {
diff --git a/sieve/testsuite/scripts/header1.sv
b/sieve/testsuite/scripts/header1.sv
index 1ebd969..fc25b40 100644
--- a/sieve/testsuite/scripts/header1.sv
+++ b/sieve/testsuite/scripts/header1.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if header :is "X-Caffeine" "C8H10N4O2" {
diff --git a/sieve/testsuite/scripts/header2.sv
b/sieve/testsuite/scripts/header2.sv
index b96ba71..3c959e7 100644
--- a/sieve/testsuite/scripts/header2.sv
+++ b/sieve/testsuite/scripts/header2.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if header ["X-Caffeine","Subject"] ["C8H10N4O2","Coffee"] {
diff --git a/sieve/testsuite/scripts/header3.sv
b/sieve/testsuite/scripts/header3.sv
index f151f77..fcf3235 100644
--- a/sieve/testsuite/scripts/header3.sv
+++ b/sieve/testsuite/scripts/header3.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if header :matches "Subject" "*$$$*" {
diff --git a/sieve/testsuite/scripts/i-casemap-contains.sv
b/sieve/testsuite/scripts/i-casemap-contains.sv
index fba1a23..f8dd74b 100644
--- a/sieve/testsuite/scripts/i-casemap-contains.sv
+++ b/sieve/testsuite/scripts/i-casemap-contains.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
require "comparator-i;ascii-casemap";
diff --git a/sieve/testsuite/scripts/i-casemap-is.sv
b/sieve/testsuite/scripts/i-casemap-is.sv
index d465dc3..d3cd3d4 100644
--- a/sieve/testsuite/scripts/i-casemap-is.sv
+++ b/sieve/testsuite/scripts/i-casemap-is.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
require "comparator-i;ascii-casemap";
diff --git a/sieve/testsuite/scripts/i-casemap-matches.sv
b/sieve/testsuite/scripts/i-casemap-matches.sv
index 2643261..85a8c41 100644
--- a/sieve/testsuite/scripts/i-casemap-matches.sv
+++ b/sieve/testsuite/scripts/i-casemap-matches.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
require "comparator-i;ascii-casemap";
diff --git a/sieve/testsuite/scripts/i-casemap-regex.sv
b/sieve/testsuite/scripts/i-casemap-regex.sv
index d6ae652..7909f39 100644
--- a/sieve/testsuite/scripts/i-casemap-regex.sv
+++ b/sieve/testsuite/scripts/i-casemap-regex.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
require "comparator-i;ascii-casemap";
diff --git a/sieve/testsuite/scripts/i-numeric-contains.sv
b/sieve/testsuite/scripts/i-numeric-contains.sv
index 6134371..c80df7b 100644
--- a/sieve/testsuite/scripts/i-numeric-contains.sv
+++ b/sieve/testsuite/scripts/i-numeric-contains.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
require "comparator-i;ascii-numeric";
diff --git a/sieve/testsuite/scripts/i-numeric-is.sv
b/sieve/testsuite/scripts/i-numeric-is.sv
index 7842d8b..ebae98e 100644
--- a/sieve/testsuite/scripts/i-numeric-is.sv
+++ b/sieve/testsuite/scripts/i-numeric-is.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
require "comparator-i;ascii-numeric";
diff --git a/sieve/testsuite/scripts/i-octet-contains.sv
b/sieve/testsuite/scripts/i-octet-contains.sv
index d8e3182..bb559e2 100644
--- a/sieve/testsuite/scripts/i-octet-contains.sv
+++ b/sieve/testsuite/scripts/i-octet-contains.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
require "comparator-i;octet";
diff --git a/sieve/testsuite/scripts/i-octet-is.sv
b/sieve/testsuite/scripts/i-octet-is.sv
index 22f6867..a4ff1d7 100644
--- a/sieve/testsuite/scripts/i-octet-is.sv
+++ b/sieve/testsuite/scripts/i-octet-is.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
require "comparator-i;octet";
diff --git a/sieve/testsuite/scripts/i-octet-matches.sv
b/sieve/testsuite/scripts/i-octet-matches.sv
index 840e1fb..d7b8233 100644
--- a/sieve/testsuite/scripts/i-octet-matches.sv
+++ b/sieve/testsuite/scripts/i-octet-matches.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
require "comparator-i;octet";
diff --git a/sieve/testsuite/scripts/i-octet-regex.sv
b/sieve/testsuite/scripts/i-octet-regex.sv
index 61dd58f..6a4703d 100644
--- a/sieve/testsuite/scripts/i-octet-regex.sv
+++ b/sieve/testsuite/scripts/i-octet-regex.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
require "comparator-i;octet";
diff --git a/sieve/testsuite/scripts/keep.sv b/sieve/testsuite/scripts/keep.sv
index 4a85ab7..9e8c837 100644
--- a/sieve/testsuite/scripts/keep.sv
+++ b/sieve/testsuite/scripts/keep.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
keep;
diff --git a/sieve/testsuite/scripts/mul-addr.sv
b/sieve/testsuite/scripts/mul-addr.sv
index e11b7c2..fd4b077 100644
--- a/sieve/testsuite/scripts/mul-addr.sv
+++ b/sieve/testsuite/scripts/mul-addr.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
require "fileinto";
diff --git a/sieve/testsuite/scripts/not.sv b/sieve/testsuite/scripts/not.sv
index 40e45cf..27b7370 100644
--- a/sieve/testsuite/scripts/not.sv
+++ b/sieve/testsuite/scripts/not.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if not false {
diff --git a/sieve/testsuite/scripts/null.sv b/sieve/testsuite/scripts/null.sv
index 4ee48b9..02e27a4 100644
--- a/sieve/testsuite/scripts/null.sv
+++ b/sieve/testsuite/scripts/null.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
# Empty script to test implicit keep.
diff --git a/sieve/testsuite/scripts/numaddr.sv
b/sieve/testsuite/scripts/numaddr.sv
index 5a85bcd..2f63cdd 100644
--- a/sieve/testsuite/scripts/numaddr.sv
+++ b/sieve/testsuite/scripts/numaddr.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
require "test-numaddr";
diff --git a/sieve/testsuite/scripts/redirect.sv
b/sieve/testsuite/scripts/redirect.sv
index b9965e4..aac6c52 100644
--- a/sieve/testsuite/scripts/redirect.sv
+++ b/sieve/testsuite/scripts/redirect.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
require "redirect";
diff --git a/sieve/testsuite/scripts/reject.sv
b/sieve/testsuite/scripts/reject.sv
index c42572c..c164dec 100644
--- a/sieve/testsuite/scripts/reject.sv
+++ b/sieve/testsuite/scripts/reject.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
require "reject";
diff --git a/sieve/testsuite/scripts/rel-address.sv
b/sieve/testsuite/scripts/rel-address.sv
index b8fad11..103298d 100644
--- a/sieve/testsuite/scripts/rel-address.sv
+++ b/sieve/testsuite/scripts/rel-address.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2003, Free Software Foundation.
+# Copyright (C) 2003, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
require ["relational", "comparator-i;ascii-numeric"];
diff --git a/sieve/testsuite/scripts/rel-hairy.sv
b/sieve/testsuite/scripts/rel-hairy.sv
index a9c560d..f319f19 100644
--- a/sieve/testsuite/scripts/rel-hairy.sv
+++ b/sieve/testsuite/scripts/rel-hairy.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2003, Free Software Foundation.
+# Copyright (C) 2003, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
require ["relational", "comparator-i;ascii-numeric", "fileinto"];
diff --git a/sieve/testsuite/scripts/rel-header.sv
b/sieve/testsuite/scripts/rel-header.sv
index 1421efb..1a131fa 100644
--- a/sieve/testsuite/scripts/rel-header.sv
+++ b/sieve/testsuite/scripts/rel-header.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2003, Free Software Foundation.
+# Copyright (C) 2003, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
require ["relational", "comparator-i;ascii-numeric"];
diff --git a/sieve/testsuite/scripts/size1.sv b/sieve/testsuite/scripts/size1.sv
index 4bf2bac..023656a 100644
--- a/sieve/testsuite/scripts/size1.sv
+++ b/sieve/testsuite/scripts/size1.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if size :under 400 {
diff --git a/sieve/testsuite/scripts/size2.sv b/sieve/testsuite/scripts/size2.sv
index 9f68a98..49a271e 100644
--- a/sieve/testsuite/scripts/size2.sv
+++ b/sieve/testsuite/scripts/size2.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if size :over 500 {
diff --git a/sieve/testsuite/scripts/stop.sv b/sieve/testsuite/scripts/stop.sv
index 577eba8..9a6335d 100644
--- a/sieve/testsuite/scripts/stop.sv
+++ b/sieve/testsuite/scripts/stop.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
stop;
diff --git a/sieve/testsuite/scripts/true.sv b/sieve/testsuite/scripts/true.sv
index 6e39cd9..64068d0 100644
--- a/sieve/testsuite/scripts/true.sv
+++ b/sieve/testsuite/scripts/true.sv
@@ -1,6 +1,6 @@
# -*- sieve -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, Free Software Foundation.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
# See file COPYING for distribution conditions.
if true {
diff --git a/sieve/testsuite/sieve/action.exp b/sieve/testsuite/sieve/action.exp
index dd6af96..fcb1d6e 100644
--- a/sieve/testsuite/sieve/action.exp
+++ b/sieve/testsuite/sieve/action.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007, 2009 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/sieve/address.exp
b/sieve/testsuite/sieve/address.exp
index 6856063..60f0909 100644
--- a/sieve/testsuite/sieve/address.exp
+++ b/sieve/testsuite/sieve/address.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/sieve/allof.exp b/sieve/testsuite/sieve/allof.exp
index 3b30243..1cdfa1e 100644
--- a/sieve/testsuite/sieve/allof.exp
+++ b/sieve/testsuite/sieve/allof.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/sieve/anyof.exp b/sieve/testsuite/sieve/anyof.exp
index 7974cf6..7f720a6 100644
--- a/sieve/testsuite/sieve/anyof.exp
+++ b/sieve/testsuite/sieve/anyof.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/sieve/compile.exp
b/sieve/testsuite/sieve/compile.exp
index 029113b..dd7d5c0 100644
--- a/sieve/testsuite/sieve/compile.exp
+++ b/sieve/testsuite/sieve/compile.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/sieve/envelope.exp
b/sieve/testsuite/sieve/envelope.exp
index caf28f4..3c94fe0 100644
--- a/sieve/testsuite/sieve/envelope.exp
+++ b/sieve/testsuite/sieve/envelope.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/sieve/exists.exp b/sieve/testsuite/sieve/exists.exp
index d65a83e..5f7b514 100644
--- a/sieve/testsuite/sieve/exists.exp
+++ b/sieve/testsuite/sieve/exists.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/sieve/ext.exp b/sieve/testsuite/sieve/ext.exp
index 59443ae..3afcff8 100644
--- a/sieve/testsuite/sieve/ext.exp
+++ b/sieve/testsuite/sieve/ext.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/sieve/false.exp b/sieve/testsuite/sieve/false.exp
index 9dc8b7f..f1709f5 100644
--- a/sieve/testsuite/sieve/false.exp
+++ b/sieve/testsuite/sieve/false.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/sieve/header.exp b/sieve/testsuite/sieve/header.exp
index d10df85..91a0e33 100644
--- a/sieve/testsuite/sieve/header.exp
+++ b/sieve/testsuite/sieve/header.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/sieve/i-casemap.exp
b/sieve/testsuite/sieve/i-casemap.exp
index f57577d..08cf4fb 100644
--- a/sieve/testsuite/sieve/i-casemap.exp
+++ b/sieve/testsuite/sieve/i-casemap.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/sieve/i-numeric.exp
b/sieve/testsuite/sieve/i-numeric.exp
index b160718..82cc7e6 100644
--- a/sieve/testsuite/sieve/i-numeric.exp
+++ b/sieve/testsuite/sieve/i-numeric.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/sieve/i-octet.exp
b/sieve/testsuite/sieve/i-octet.exp
index 40fec89..18abe89 100644
--- a/sieve/testsuite/sieve/i-octet.exp
+++ b/sieve/testsuite/sieve/i-octet.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/sieve/mul-addr.exp
b/sieve/testsuite/sieve/mul-addr.exp
index 1d284ed..2d63ae3 100644
--- a/sieve/testsuite/sieve/mul-addr.exp
+++ b/sieve/testsuite/sieve/mul-addr.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/sieve/not.exp b/sieve/testsuite/sieve/not.exp
index c62d5fa..346629e 100644
--- a/sieve/testsuite/sieve/not.exp
+++ b/sieve/testsuite/sieve/not.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/sieve/redirect.exp
b/sieve/testsuite/sieve/redirect.exp
index cab28a6..d782c80 100644
--- a/sieve/testsuite/sieve/redirect.exp
+++ b/sieve/testsuite/sieve/redirect.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/sieve/reject.exp b/sieve/testsuite/sieve/reject.exp
index 8bdd101..c2a2c48 100644
--- a/sieve/testsuite/sieve/reject.exp
+++ b/sieve/testsuite/sieve/reject.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/sieve/relational.exp
b/sieve/testsuite/sieve/relational.exp
index 70aa490..79866ec 100644
--- a/sieve/testsuite/sieve/relational.exp
+++ b/sieve/testsuite/sieve/relational.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/sieve/size.exp b/sieve/testsuite/sieve/size.exp
index 74a5af0..bdca47f 100644
--- a/sieve/testsuite/sieve/size.exp
+++ b/sieve/testsuite/sieve/size.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sieve/testsuite/sieve/true.exp b/sieve/testsuite/sieve/true.exp
index 0558a97..7fc7e02 100644
--- a/sieve/testsuite/sieve/true.exp
+++ b/sieve/testsuite/sieve/true.exp
@@ -1,6 +1,6 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2007 Free Software Foundation
+# Copyright (C) 2002, 2007, 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/sql/Makefile.am b/sql/Makefile.am
index 16d0863..2ad125f 100644
--- a/sql/Makefile.am
+++ b/sql/Makefile.am
@@ -1,6 +1,6 @@
## This file is part of GNU Mailutils
-## Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2004, 2005, 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/sql/mysql.c b/sql/mysql.c
index dc45c8c..fd919a7 100644
--- a/sql/mysql.c
+++ b/sql/mysql.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 2006, 2007, 2009, 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/sql/odbc.c b/sql/odbc.c
index 2f2e5b1..bb9e345 100644
--- a/sql/odbc.c
+++ b/sql/odbc.c
@@ -1,5 +1,5 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2005, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2005, 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/sql/postgres.c b/sql/postgres.c
index 3406062..e4e4c87 100644
--- a/sql/postgres.c
+++ b/sql/postgres.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 2007, 2009, 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/sql/sql.c b/sql/sql.c
index 07e7745..b256beb 100644
--- a/sql/sql.c
+++ b/sql/sql.c
@@ -1,5 +1,6 @@
/* GNU Mailutils -- a suite of utilities for electronic mail
- Copyright (C) 2004, 2005, 2006, 2007, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 2006, 2007, 2009, 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/testsuite/Makefile.am b/testsuite/Makefile.am
index 2830dce..5182ae0 100644
--- a/testsuite/Makefile.am
+++ b/testsuite/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with GNU Automake to create Makefile.in
-## Copyright (C) 2002, 2007 Free Software Foundation, Inc.
+## Copyright (C) 2002, 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/testsuite/etc/mail.rc b/testsuite/etc/mail.rc
index e0e472d..2161648 100644
--- a/testsuite/etc/mail.rc
+++ b/testsuite/etc/mail.rc
@@ -1,3 +1,6 @@
+# This file is part of GNU Mailutils testsuite.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
+# See file COPYING for distribution conditions.
set quiet nocrt dot
set screen=10 columns=80
set indentprefix="> "
diff --git a/testsuite/etc/mailutils.rc.in b/testsuite/etc/mailutils.rc.in
index 0502946..5daa443 100644
--- a/testsuite/etc/mailutils.rc.in
+++ b/testsuite/etc/mailutils.rc.in
@@ -1,3 +1,7 @@
+# This file is part of GNU Mailutils testsuite.
+# Copyright (C) 2002, 2010 Free Software Foundation, Inc.
+# See file COPYING for distribution conditions.
+
mailbox {
mailbox-pattern "$MU_SPOOL_DIR/$arg{user}";
}
diff --git a/testsuite/lib/mailutils.exp b/testsuite/lib/mailutils.exp
index 10d8043..827f0d3 100644
--- a/testsuite/lib/mailutils.exp
+++ b/testsuite/lib/mailutils.exp
@@ -1,6 +1,7 @@
# -*- tcl -*-
# This file is part of Mailutils testsuite.
-# Copyright (C) 2002, 2005, 2007, 2008, 2009 Free Software Foundation
+# Copyright (C) 2002, 2005, 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
hooks/post-receive
--
GNU Mailutils
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [SCM] GNU Mailutils branch, master, updated. rel-2_1-26-gc29efb8,
Sergey Poznyakoff <=