commit 7648f9fb6a272880b6247b1b4a56af550957d8ea
parent 8aa5c43ade178e04f68a7aa1fe09de63cfb2225f
Author: Oliver Lowe <o@olowe.co>
Date: Sun, 17 Aug 2025 16:47:29 +1000
delete change stuff
getting tired
Diffstat:
126 files changed, 15 insertions(+), 43158 deletions(-)
diff --git a/appdata/Makefile.am b/appdata/Makefile.am
@@ -1,44 +0,0 @@
-# Copyright 1999-2015 the Claws Mail team.
-# This file is part of Claws Mail package, and distributed under the
-# terms of the General Public License version 3 (or later).
-# See COPYING file for license details.
-
-@INTLTOOL_XML_RULE@
-
-appdata_in_files = claws-mail.appdata.xml.in \
- claws-mail-acpi_notifier.metainfo.xml.in \
- claws-mail-address_keeper.metainfo.xml.in \
- claws-mail-archive.metainfo.xml.in \
- claws-mail-att_remover.metainfo.xml.in \
- claws-mail-attachwarner.metainfo.xml.in \
- claws-mail-bogofilter.metainfo.xml.in \
- claws-mail-bsfilter.metainfo.xml.in \
- claws-mail-clamd.metainfo.xml.in \
- claws-mail-fancy.metainfo.xml.in \
- claws-mail-fetchinfo.metainfo.xml.in \
- claws-mail-gdata.metainfo.xml.in \
- claws-mail-libravatar.metainfo.xml.in \
- claws-mail-mailmbox.metainfo.xml.in \
- claws-mail-managesieve.metainfo.xml.in \
- claws-mail-newmail.metainfo.xml.in \
- claws-mail-notification.metainfo.xml.in \
- claws-mail-pdf_viewer.metainfo.xml.in \
- claws-mail-perl.metainfo.xml.in \
- claws-mail-pgpcore.metainfo.xml.in \
- claws-mail-pgpinline.metainfo.xml.in \
- claws-mail-pgpmime.metainfo.xml.in \
- claws-mail-python.metainfo.xml.in \
- claws-mail-rssyl.metainfo.xml.in \
- claws-mail-smime.metainfo.xml.in \
- claws-mail-spam_report.metainfo.xml.in \
- claws-mail-spamassassin.metainfo.xml.in \
- claws-mail-tnef_parse.metainfo.xml.in \
- claws-mail-vcalendar.metainfo.xml.in
-
-appdatadir=$(datarootdir)/appdata
-appdata_DATA = $(appdata_in_files:.xml.in=.xml)
-
-EXTRA_DIST = $(appdata_DATA) $(appdata_in_files)
-
-
-.PHONY: test
diff --git a/appdata/claws-mail-acpi_notifier.metainfo.xml.in b/appdata/claws-mail-acpi_notifier.metainfo.xml.in
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-acpi_notifier</id>
-<extends>claws-mail.desktop</extends>
-<name>AcpiNotifier</name>
-<_summary>Enables mail notification via LEDs on some laptops.</_summary>
-<url type="homepage">http://claws-mail.org/plugin.php?plugin=acpinotifier</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-address_keeper.metainfo.xml.in b/appdata/claws-mail-address_keeper.metainfo.xml.in
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-address_keeper</id>
-<extends>claws-mail.desktop</extends>
-<name>AddressKeeper</name>
-<_summary>Keeps all recipient addresses in a designated addressbook folder.</_summary>
-<url type="homepage">http://claws-mail.org/plugins.php</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-archive.metainfo.xml.in b/appdata/claws-mail-archive.metainfo.xml.in
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-archive</id>
-<extends>claws-mail.desktop</extends>
-<name>Mail Archiver</name>
-<_summary>Adds archiving features to Claws Mail.</_summary>
-<url type="homepage">http://claws-mail.org/plugins.php</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-att_remover.metainfo.xml.in b/appdata/claws-mail-att_remover.metainfo.xml.in
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-att_remover</id>
-<extends>claws-mail.desktop</extends>
-<name>AttRemover</name>
-<_summary>Lets you remove attachments from emails.</_summary>
-<url type="homepage">http://claws-mail.org/plugins.php</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-attachwarner.metainfo.xml.in b/appdata/claws-mail-attachwarner.metainfo.xml.in
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-attachwarner</id>
-<extends>claws-mail.desktop</extends>
-<name>AttachWarner</name>
-<_summary>Warns you when you compose a message mentioning an attachment in the message body without attaching any files to the message.</_summary>
-<url type="homepage">http://claws-mail.org/plugin.php?plugin=attachwarner</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-bogofilter.metainfo.xml.in b/appdata/claws-mail-bogofilter.metainfo.xml.in
@@ -1,13 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-bogofilter</id>
-<extends>claws-mail.desktop</extends>
-<name>Bogofilter</name>
-<_summary>Enables the scanning of incoming mail received from a POP, IMAP, or LOCAL account using Bogofilter.
-It can optionally delete mail identified as spam or save it to a designated folder.</_summary>
-<url type="homepage">http://claws-mail.org/plugin.php?plugin=bogofilter</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-bsfilter.metainfo.xml.in b/appdata/claws-mail-bsfilter.metainfo.xml.in
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-bsfilter</id>
-<extends>claws-mail.desktop</extends>
-<name>BSfilter</name>
-<_summary>Check all messages that are received from an IMAP, LOCAL or POP account for spam using Bsfilter.</_summary>
-<url type="homepage">http://claws-mail.org/plugins.php</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-clamd.metainfo.xml.in b/appdata/claws-mail-clamd.metainfo.xml.in
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-clamd</id>
-<extends>claws-mail.desktop</extends>
-<name>Clamd</name>
-<_summary>Scans all messages that are received from an IMAP, LOCAL or POP account using clamd (Clam AV).</_summary>
-<url type="homepage">http://claws-mail.org/plugins.php</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-fancy.metainfo.xml.in b/appdata/claws-mail-fancy.metainfo.xml.in
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-fancy</id>
-<extends>claws-mail.desktop</extends>
-<name>Fancy</name>
-<_summary>Renders HTML e-mail using the WebKit library.</_summary>
-<url type="homepage">http://claws-mail.org/plugins.php</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-fetchinfo.metainfo.xml.in b/appdata/claws-mail-fetchinfo.metainfo.xml.in
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-fetchinfo</id>
-<extends>claws-mail.desktop</extends>
-<name>Fetchinfo</name>
-<_summary>Inserts headers containing: UIDL, Claws' account name, POP server, user ID and retrieval time.</_summary>
-<url type="homepage">http://claws-mail.org/plugins.php</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-gdata.metainfo.xml.in b/appdata/claws-mail-gdata.metainfo.xml.in
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-gdata</id>
-<extends>claws-mail.desktop</extends>
-<name>GData</name>
-<_summary>Provides an interface to Google services.</_summary>
-<url type="homepage">http://claws-mail.org/plugins.php</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-libravatar.metainfo.xml.in b/appdata/claws-mail-libravatar.metainfo.xml.in
@@ -1,13 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-libravatar</id>
-<extends>claws-mail.desktop</extends>
-<name>Libravatar</name>
-<_summary>Displays libravatar/gravatar profiles' images or a dynamically generated or predefined alternative.
-Libravatar federated user domains are also supported.</_summary>
-<url type="homepage">http://claws-mail.org/plugin.php?plugin=libravatar</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-mailmbox.metainfo.xml.in b/appdata/claws-mail-mailmbox.metainfo.xml.in
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-mailmbox</id>
-<extends>claws-mail.desktop</extends>
-<name>mailMBOX</name>
-<_summary>Adds support for mailboxes in mbox format.</_summary>
-<url type="homepage">http://claws-mail.org/plugins.php</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-managesieve.metainfo.xml.in b/appdata/claws-mail-managesieve.metainfo.xml.in
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2015 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-managesieve</id>
-<extends>claws-mail.desktop</extends>
-<name>ManageSieve</name>
-<_summary>Provides an interface for managing Sieve filters on IMAP servers. Those filters are used for server-side mail filtering.</_summary>
-<url type="homepage">http://claws-mail.org/plugin.php?plugin=managesieve</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-newmail.metainfo.xml.in b/appdata/claws-mail-newmail.metainfo.xml.in
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-newmail</id>
-<extends>claws-mail.desktop</extends>
-<name>NewMail</name>
-<_summary>Writes a message header summary to a log file on arrival of new mail after sorting.</_summary>
-<url type="homepage">http://claws-mail.org/plugins.php</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-notification.metainfo.xml.in b/appdata/claws-mail-notification.metainfo.xml.in
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-notification</id>
-<extends>claws-mail.desktop</extends>
-<name>Notification</name>
-<_summary>Provides various ways to notify the user of new and unread email.</_summary>
-<url type="homepage">http://claws-mail.org/plugin.php?plugin=notification</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-pdf_viewer.metainfo.xml.in b/appdata/claws-mail-pdf_viewer.metainfo.xml.in
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-pdf_viewer</id>
-<extends>claws-mail.desktop</extends>
-<name>PDF Viewer</name>
-<_summary>Enables viewing PDF and PostScript attachments.</_summary>
-<url type="homepage">http://claws-mail.org/plugin.php?plugin=pdf_viewer</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-perl.metainfo.xml.in b/appdata/claws-mail-perl.metainfo.xml.in
@@ -1,13 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-perl</id>
-<extends>claws-mail.desktop</extends>
-<name>Perl</name>
-<_summary>Provides a Perl interface to Claws Mail's filtering mechanism, allowing the use of
-full Perl power in email filters.</_summary>
-<url type="homepage">http://claws-mail.org/plugins.php</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-pgpcore.metainfo.xml.in b/appdata/claws-mail-pgpcore.metainfo.xml.in
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-pgpcore</id>
-<extends>claws-mail.desktop</extends>
-<name>PGP/Core</name>
-<_summary>Handles core PGP functions and is a dependency of both the PGP/Inline and PGP/MIME plugins.</_summary>
-<url type="homepage">http://claws-mail.org/plugin.php?plugin=gpg</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-pgpinline.metainfo.xml.in b/appdata/claws-mail-pgpinline.metainfo.xml.in
@@ -1,13 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-pgpinline</id>
-<extends>claws-mail.desktop</extends>
-<name>PGP/Inline</name>
-<_summary>Handles PGP/Inline signed and encrypted mails. You can decrypt mails, verify signatures,
-and sign and encrypt your own mails.</_summary>
-<url type="homepage">http://claws-mail.org/plugin.php?plugin=gpg</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-pgpmime.metainfo.xml.in b/appdata/claws-mail-pgpmime.metainfo.xml.in
@@ -1,13 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-pgpmime</id>
-<extends>claws-mail.desktop</extends>
-<name>PGP/MIME</name>
-<_summary>Handles PGP/MIME signed and encrypted mails. You can decrypt mails, verify signatures,
-and sign and encrypt your own mails.</_summary>
-<url type="homepage">http://claws-mail.org/plugin.php?plugin=gpg</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-python.metainfo.xml.in b/appdata/claws-mail-python.metainfo.xml.in
@@ -1,13 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-python</id>
-<extends>claws-mail.desktop</extends>
-<name>Python</name>
-<_summary>Provides Python integration features. Code can be entered into an embedded Python
-console or stored in scripts.</_summary>
-<url type="homepage">http://claws-mail.org/plugin.php?plugin=python</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-rssyl.metainfo.xml.in b/appdata/claws-mail-rssyl.metainfo.xml.in
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-rssyl</id>
-<extends>claws-mail.desktop</extends>
-<name>RSSyl</name>
-<_summary>Read your favourite RSS 1.0, 2.0 and Atom feeds in Claws Mail.</_summary>
-<url type="homepage">http://claws-mail.org/plugin.php?plugin=rssyl</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-smime.metainfo.xml.in b/appdata/claws-mail-smime.metainfo.xml.in
@@ -1,13 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-smime</id>
-<extends>claws-mail.desktop</extends>
-<name>S/MIME</name>
-<_summary>Handles S/MIME signed and encrypted mails. You can decrypt mails, verify
-signatures and sign and encrypt your own mails. </_summary>
-<url type="homepage">http://claws-mail.org/plugins.php</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-spam_report.metainfo.xml.in b/appdata/claws-mail-spam_report.metainfo.xml.in
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-spam_report</id>
-<extends>claws-mail.desktop</extends>
-<name>SpamReport</name>
-<_summary>Reports spam to various places.</_summary>
-<url type="homepage">http://claws-mail.org/plugins.php</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-spamassassin.metainfo.xml.in b/appdata/claws-mail-spamassassin.metainfo.xml.in
@@ -1,13 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-spamassassin</id>
-<extends>claws-mail.desktop</extends>
-<name>SpamAssassin</name>
-<_summary>Enables the scanning of incoming mail received from a POP, IMAP, or LOCAL account using SpamAssassin.
-It can optionally delete mail identified as spam or save it to a designated folder.</_summary>
-<url type="homepage">http://claws-mail.org/plugin.php?plugin=spamassassin</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-tnef_parse.metainfo.xml.in b/appdata/claws-mail-tnef_parse.metainfo.xml.in
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-tnef_parse</id>
-<extends>claws-mail.desktop</extends>
-<name>TNEF parse</name>
-<_summary>Enables reading application/ms-tnef attachments.</_summary>
-<url type="homepage">http://claws-mail.org/plugin.php?plugin=tnef_parser</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail-vcalendar.metainfo.xml.in b/appdata/claws-mail-vcalendar.metainfo.xml.in
@@ -1,13 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 the Claws Mail team -->
-<component type="addon">
-<id>claws-mail-vcalendar</id>
-<extends>claws-mail.desktop</extends>
-<name>vCalendar</name>
-<_summary>Enables vCalendar message handling like that produced by Evolution or Outlook, and
-handles webCal subscriptions. It provides a personal calendar and public calendar import.</_summary>
-<url type="homepage">http://claws-mail.org/plugin.php?plugin=vcalendar</url>
-<metadata_license>CC0-1.0</metadata_license>
-<project_license>GPL-3.0+</project_license>
-<updatecontact>devel@lists.claws-mail.org</updatecontact>
-</component>
diff --git a/appdata/claws-mail.appdata.xml.in b/appdata/claws-mail.appdata.xml.in
@@ -1,28 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Copyright 2014 Colin Leroy <colin@colino.net> and the Claws Mail team -->
-<application>
- <id type="desktop">claws-mail.desktop</id>
- <metadata_license>CC-BY-SA-3.0</metadata_license>
- <project_license>GPL-3.0+</project_license>
- <description>
- <_p>
- Claws Mail is a fast, powerful and very extensible email client.
- </_p>
- <_p>
- It is highly configurable and handles hundreds of thousands of emails
- easily. Messages are managed in the standard MH format, and are easy to interact
- with.
- </_p>
- <_p>
- Lots of extra functionality is provided by plugins, such as PGP signatures
- and encryption, an RSS aggregator, a calendar, powerful spam filtering,
- Perl and Python interactions, HTML and PDF rendering, and more.
- </_p>
- </description>
- <screenshots>
- <screenshot type="default" width="928" height="522">http://www.claws-mail.org/appdata/claws-main.png</screenshot>
- <screenshot width="928" height="522">http://www.claws-mail.org/appdata/claws-setup.png</screenshot>
- </screenshots>
- <url type="homepage">http://www.claws-mail.org/</url>
- <updatecontact>devel@lists.claws-mail.org</updatecontact>
-</application>
diff --git a/claws-features.h.in b/claws-features.h.in
@@ -1,4 +1,3 @@
-#undef HAVE_LIBETPAN
#undef HAVE_VALGRIND
#undef USE_ENCHANT
#undef USE_GNUTLS
diff --git a/configure.ac b/configure.ac
@@ -6,8 +6,8 @@ m4_define([claws_VERSION],
AC_INIT([claws-mail],
m4_defn([claws_VERSION]))
AC_CONFIG_SRCDIR([src/main.c])
-AC_CONFIG_AUX_DIR([config])
AC_CONFIG_MACRO_DIR([m4])
+AC_CONFIG_AUX_DIR([config])
AC_CANONICAL_TARGET
AM_INIT_AUTOMAKE([no-define])
@@ -103,30 +103,9 @@ LT_LANG([Windows Resource])
LT_INIT
AC_PROG_AWK
-dnl AC_PROG_CXX will set CXX=g++ even if it finds no useable C++
-dnl compiler, so we have to check whether the program named by
-dnl CXX exists.
-AC_PROG_CXX
-AC_PATH_PROG(REAL_CXX, $CXX)
-HAVE_CXX=no
-if test -n "$REAL_CXX"; then
- HAVE_CXX=yes
-fi
-
AC_SYS_LARGEFILE
-dnl Copied from the official gtk+-2 configure.in
-AC_MSG_CHECKING([for host platform])
-case "$host" in
- *-apple-*)
- platform_osx=yes
- LDFLAGS="$LDFLAGS -Wl,-export_dynamic"
- ;;
- *)
- platform_osx=no
- LDFLAGS="$LDFLAGS -Wl,--export-dynamic"
- ;;
-esac
+LDFLAGS="$LDFLAGS -Wl,--export-dynamic"
AC_MSG_CHECKING([for time_t format specifier])
_gcc_cflags_save=$CFLAGS
@@ -154,16 +133,6 @@ if test $USE_MAINTAINER_MODE = yes; then
AM_CFLAGS="$AM_CFLAGS -g"
fi
-case "$target" in
-*-darwin*)
- AM_CFLAGS="$AM_CFLAGS -fno-common"
- ;;
-*-*-solaris*)
- AM_CFLAGS="$AM_CFLAGS -std=gnu99"
- AC_DEFINE([SOLARIS], [], [Target is Solaris])
- ;;
-esac
-
AC_SUBST(AM_CFLAGS)
dnl Checks for iconv
@@ -180,10 +149,6 @@ AC_DEFINE_UNQUOTED(GETTEXT_PACKAGE,"$GETTEXT_PACKAGE", [Define text domain.])
AM_GNU_GETTEXT_VERSION([0.18])
AM_GNU_GETTEXT([external])
-AC_ARG_ENABLE(manual,
- [ --disable-manual Do not build user manual],
- [enable_manual=$enableval], [enable_manual=yes])
-
AC_ARG_ENABLE(gnutls,
[ --disable-gnutls Do not build GnuTLS support for TLS],
[enable_gnutls=$enableval], [enable_gnutls=yes])
@@ -196,10 +161,6 @@ AC_ARG_ENABLE(enchant,
[ --disable-enchant Do not build Enchant support for spell-checking],
[enable_enchant=$enableval], [enable_enchant=yes])
-AC_ARG_ENABLE(libetpan,
- [ --disable-libetpan Do not build libetpan support for IMAP4/NNTP],
- [enable_libetpan=$enableval], [enable_libetpan=yes])
-
AC_ARG_ENABLE(valgrind,
[ --disable-valgrind Do not build valgrind support for debugging],
[enable_valgrind=$enableval], [enable_valgrind=yes])
@@ -212,38 +173,6 @@ AC_ARG_ENABLE(more-addressbook-debug,
[ --enable-more-addressbook-debug Build with additional addressbook debug calls],
[enable_more_addressbook_debug=$enableval], [enable_more_addressbook_debug=no])
-manualdir='${docdir}/manual'
-AC_ARG_WITH(manualdir,
- [ --with-manualdir=DIR Manual directory],
- [manualdir="$withval"])
-AC_SUBST(manualdir)
-
-dnl ******************************
-dnl ** Check for required tools **
-dnl ** to build manuals **
-dnl ******************************
-
-AC_PATH_PROG(DOCBOOK2HTML, docbook2html)
-AC_PATH_PROG(DOCBOOK2TXT, docbook2txt)
-AC_PATH_PROG(DOCBOOK2PS, docbook2ps)
-AC_PATH_PROG(DOCBOOK2PDF, docbook2pdf)
-
-AM_CONDITIONAL(MANUAL_HTML, test -n "$DOCBOOK2HTML")
-AM_CONDITIONAL(MANUAL_TXT, test -n "$DOCBOOK2TXT")
-AM_CONDITIONAL(MANUAL_PDF, test -n "$DOCBOOK2PDF")
-AM_CONDITIONAL(MANUAL_PS, test -n "$DOCBOOK2PS")
-
-if test x"$enable_manual" = x"yes"; then
- if test -n "$DOCBOOK2TXT" -o -n "$DOCBOOK2HTML" \
- -o -n "$DOCBOOK2PS" -o -n "$DOCBOOK2PDF"; then
- enable_manual=yes
- else
- enable_manual=no
- fi
-fi
-
-AM_CONDITIONAL(BUILD_MANUAL, test x"$enable_manual" = xyes)
-
dnl Set PACKAGE_DATA_DIR in config.h.
if test "x${datarootdir}" = 'x${prefix}/share'; then
if test "x${prefix}" = "xNONE"; then
@@ -421,71 +350,13 @@ AC_SUBST(LIBRESOLV)
LIBS="$LIBS $LIBRESOLV"
-dnl Libetpan
-AC_MSG_CHECKING([whether to use libetpan])
-if test x"$enable_libetpan" = xyes; then
- AC_MSG_RESULT(yes)
-
- libetpan_config=no
- libetpan_result=no
- libetpan_versiontype=0
-
- # since 1.9.4, libetpan uses pkg-config
- PKG_CHECK_MODULES([LIBETPAN], [libetpan >= 1.9.4],
- [
- LIBETPAN_VERSION=`pkg-config --modversion libetpan | $AWK -F. '{printf "%d", ($1 * 10000) + ($2 * 100) + $3}'`
- libetpan_config=yes
- ],
- [
- # before ws libetpan 1.9.4, libetpan uses its own libetpan-config script
- AC_PATH_PROG(libetpanconfig, [libetpan-config])
- if test "x$libetpanconfig" != "x"; then
- LIBETPAN_CFLAGS="`$libetpanconfig --cflags`"
- LIBETPAN_LIBS="`$libetpanconfig --libs`"
- # support libetpan version like x.x and x.x.x
- libetpan_versiontype=`$libetpanconfig --version | tr -dc . | wc -c`
- if test $libetpan_versiontype -eq 1; then
- LIBETPAN_VERSION=`$libetpanconfig --version | $AWK -F. '{printf "%d", ($1 * 100) + $2}'`
- else
- LIBETPAN_VERSION=`$libetpanconfig --version | $AWK -F. '{printf "%d", ($1 * 10000) + ($2 * 100) + $3}'`
- fi
- libetpan_config=yes
- fi
- ])
- if test "x$libetpan_config" = "xyes"; then
- libetpan_save_CPPFLAGS=$CPPFLAGS
- CPPFLAGS="$CPPFLAGS $LIBETPAN_CFLAGS"
- AC_CHECK_HEADER(libetpan/libetpan.h, [libetpan_result=yes])
- if test "x$libetpan_result" = "xyes"; then
- AC_MSG_CHECKING([whether libetpan-config hints compiles and links fine])
- libetpan_save_LIBS=$LIBS
- LIBS="$LIBS $LIBETPAN_LIBS"
- AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <libetpan/dbstorage.h>]], [[db_mailstorage_init(NULL, NULL);]])],[libetpan_result=yes],[libetpan_result=no])
- LIBS=$libetpan_save_LIBS
- AC_MSG_RESULT([$libetpan_result])
- fi
- CPPFLAGS=$libetpan_save_CPPFLAGS
- fi
- if test "x$libetpan_result" = "xyes"; then
- if test $libetpan_versiontype -eq 1; then
- if test "$LIBETPAN_VERSION" -lt "57"; then
- AC_MSG_RESULT([*** Claws Mail requires libetpan 0.57 or newer. See http://www.etpan.org/])
- AC_MSG_RESULT([*** You can use --disable-libetpan if you don't need IMAP4 and/or NNTP support.])
- AC_MSG_ERROR([libetpan 0.57 not found])
- fi
- fi
- AC_SUBST(LIBETPAN_CFLAGS)
- AC_SUBST(LIBETPAN_LIBS)
- AC_DEFINE(HAVE_LIBETPAN, 1, Define if you want IMAP and/or NNTP support.)
- else
- AC_MSG_RESULT([*** Claws Mail requires libetpan 0.57 or newer. See http://www.etpan.org/ ])
- AC_MSG_RESULT([*** You can use --disable-libetpan if you don't need IMAP4 and/or NNTP support.])
- AC_MSG_ERROR([libetpan 0.57 not found])
- fi
-else
- AC_MSG_RESULT(no)
-fi
-AM_CONDITIONAL(CLAWS_LIBETPAN, test "x$libetpan_result" = "xyes")
+PKG_CHECK_MODULES([LIBETPAN], [libetpan >= 1.9.4])
+LIBETPAN_LIBS=`pkg-config --libs libetpan`
+AC_SUBST(LIBETPAN_LIBS)
+LIBS="$LIBS $LIBETPAN_LIBS"
+LIBETPAN_CFLAGS=`pkg-config --cflags libetpan`
+AC_SUBST(LIBETPAN_CFLAGS)
+CPPFLAGS="$CPPFLAGS $LIBETPAN_CFLAGS"
AC_MSG_CHECKING([whether to use valgrind])
if test x$enable_valgrind = xyes; then
@@ -523,7 +394,6 @@ else
AC_MSG_RESULT(no)
fi
-dnl expat **********************************************************************
PKG_CHECK_MODULES(EXPAT, expat, HAVE_EXPAT=yes, HAVE_EXPAT=no)
if test x"$HAVE_EXPAT" = xno; then
@@ -539,31 +409,14 @@ fi
AC_SUBST(EXPAT_CFLAGS)
AC_SUBST(EXPAT_LIBS)
-dnl cairo **********************************************************************
PKG_CHECK_MODULES(CAIRO, cairo >= 1.12.0, HAVE_CAIRO=yes, HAVE_CAIRO=no)
AC_SUBST(CAIRO_CFLAGS)
AC_SUBST(CAIRO_LIBS)
-dnl fontconfig *****************************************************************
PKG_CHECK_MODULES(FONTCONFIG, fontconfig, HAVE_FONTCONFIG=yes, HAVE_FONTCONFIG=no)
AC_SUBST(FONTCONFIG_CFLAGS)
AC_SUBST(FONTCONFIG_LIBS)
-dnl Gpgme **********************************************************************
-PKG_CHECK_MODULES(GPGME, [gpgme >= 1.1.1], HAVE_GPGME_PKGCONFIG=yes, HAVE_GPGME_PKGCONFIG=no)
-if test x"$HAVE_GPGME_PKGCONFIG" = xyes; then
- PKG_CHECK_MODULES(LIBGPG_ERROR, [gpg-error])
-else
- AM_PATH_GPGME(1.1.1, HAVE_GPGME_CONFIG=yes, HAVE_GPGME_CONFIG=no)
-fi
-
-if test x"$HAVE_GPGME_PKGCONFIG" = xyes -o x"$HAVE_GPGME_CONFIG" = xyes; then
- AC_DEFINE(USE_GPGME, 1, Define if you use GPGME to support OpenPGP.)
- HAVE_GPGME=yes
-else
- HAVE_GPGME=no
-fi
-
AC_CONFIG_FILES([
Makefile
po/Makefile.in
@@ -575,26 +428,16 @@ src/common/tests/Makefile
src/gtk/Makefile
src/etpan/Makefile
src/tests/Makefile
-doc/Makefile
-doc/man/Makefile
-tools/Makefile
-config/Makefile
-manual/Makefile
claws-mail.pc
])
AC_OUTPUT
-dnl Output the configuration summary
-echo ""
echo "$PACKAGE $VERSION"
echo ""
echo "gnuTLS : $enable_gnutls"
echo "OAuth2 : $enable_oauth2"
echo "iconv : $am_cv_func_iconv"
echo "enchant : $enable_enchant"
-echo "IMAP4 (libetpan) : $enable_libetpan"
-echo "NNTP (libetpan) : $enable_libetpan"
-echo "Manual : $enable_manual"
echo "Unit tests : $enable_tests"
echo "Valgrind support : $enable_valgrind"
diff --git a/doc/Makefile.am b/doc/Makefile.am
@@ -1,8 +0,0 @@
-# Copyright 1999-2014 the Claws Mail team.
-# This file is part of Claws Mail package, and distributed under the
-# terms of the General Public License version 3 (or later).
-# See COPYING file for license details.
-
-SUBDIRS = man
-
-.PHONY: test
diff --git a/doc/src/password_encryption.txt b/doc/password_encryption.txt
diff --git a/doc/src/glade.txt b/doc/src/glade.txt
@@ -1,40 +0,0 @@
-Using glade to create interfaces for Sylpheed
----------------------------------------------
-
-Sylpheed is not a glade project and so it cannot use the directory and
-file structure that is created by glade directly. Glade is only used to
-design the user interface and write most of the GTK code.
-
-To create a part of the Sylpheed user interface ,create a new window in
-glade and put all the widgets that you need into it. Glade always wants
-to have its glade file in the project directory where it creates the
-files, so its better to do this in a temporary directory. After saving
-the C source copy the GTK code from the create_<WINDOWNAME>() function to
-your own code in Sylpheed. Remove the code that is actually creating the
-window and the function call that adds the top widget to the window. Also
-remove all calls to gtk_widget_ref() and gtk_object_set_data_full(). To
-make it to replace the glade part it is probably better to leave the rest
-untouched. If you put the copied part at the beginning of your function
-you can keep the function calls and the variable declarations in one part.
-As it is done in other parts of Sylpheed, you can define a struct for
-your window that uses the widgets created by glade and remembers all of
-the widgets that you need using pointers in the struct. You can simply
-assign the widget pointers to your struct members after the glade block.
-
-To make glade's code match Sylpheed's coding style you can use the indent
-command with the -kr and -i8 parameters on the interface.c file before
-you copy the code.
-
-To make it easy to find which glade file contains the widget description
-for the code contained in a C file its probably good to copy the glade
-file from the temporary directory to a file with the same name as the
-C file with a ".glade" suffix instead of ".c". If you want to change an
-existing user interface you can either copy the glade file to a temporary
-directory or open it directly and change the project directory in glade
-to a temporary directory, because, otherwise, glade will write all its
-project stuff into the Sylpheed source directory. Don't forget to copy
-the modified file back after you saved your user interface in glade.
-
-If you want to use different composite widgets in one C file you should
-use multiple windows in glade to create them and then copy them one by
-one to your own code.
diff --git a/doc/src/maintainer_guide.txt b/doc/src/maintainer_guide.txt
@@ -1,386 +0,0 @@
-Contents:
-
- 1. Files in src/
- 2. Files in src/common/
- 3. Files in src/gtk/
- 4. Hooks summary
-
-
-------------------------------------------------------------------------------
-1. Files in src/
-
-account.c
- is the accounts list dialog
-action.c
- dialog and functions for external actions
-addr_compl.c
- is the address completion process
-addrbook.c
- management of address book
-addrcache.c
- functions to maintain address cache
-addrcindex.c
- functions to maintain address completion index
-addrclip.c
- contains address clipboard objects and related functions
-addressadd.c
- add address to address book dialog
-addressbook.c
- is the address book dialog
-addrgather.c
- dialog for gathering EMail addresses from mail folder
-addrharvest.c
- functions for an E-Mail address harvester
-addrindex.c
- general functions for accessing address index file
-addritem.c
- general primitive address item objects
-addrselect.c
- address list item selection objects
-alertpanel.c
- dialog displaying warnings and notifications
-codeconv.c
- conversion of charset encodings
-compose.c
- is the compose dialog
-crash.c
- collect gdb backtrace info on crashes
-customheader.c
- function to parse custom headers configuration file
-displayheader.c
- function to parse headers display configuration file
-editaddress.c
- editing single addressbook entries
-editbook.c
- editing addressbooks
-editgroup.c
- editing addressbook groups
-editjpilot.c
- edit JPilot address book data
-editldap.c
- edit LDAP address book data
-editldap_basedn.c
- LDAP Base DN selection dialog
-editvcard.c
- edit vCard address book data
-enriched.c
- parses text/enriched mime type
-exphtmldlg.c
- export address book to HTML file (GUI)
-expldifdlg.c
- export address book to LDIF file (GUI)
-export.c
- exports MH folders to MBOX
-exporthtml.c
- export address book to HTML file
-exportldif.c
- export address book to LDIF file
-filtering.c
- handles the filtering process and function for filtering data structure
-folder.c
- handles the folder structure (left panel) without any gtk
-folder_item_prefs.c
- folder property functions (load, save, copy, ...)
-foldersel.c
- dialog for selecting mail folders
-folderview.c
- is the left panel gtk implementation
-grouplistdialog.c
- this is the newsgroup selection dialog box
-headerview.c
- is the little header viewer between the list of mails and
- the mail viewer.html.c
-imap.c
- is the handling of the IMAP4 procotol
-import.c
- import from mbox dialog
-importldif.c
- import LDIF address book data
-importmutt.c
- import Mutt address book data
-importpine.c
- import Pine address book data
-inc.c
- retrievement of POP3 or mbox accounts
-inputdialog.c
- this is a dialog for the user to type something.
-jpilot.c
- functions necessary to access JPilot database files
-ldapctrl.c
- functions for LDAP control data
-ldapquery.c
- functions necessary to define and perform LDAP queries
-ldapserver.c
- functions necessary to access LDAP servers
-ldaputil.c
- some utility functions to access LDAP servers
-ldif.c
- functions necessary to access LDIF files (LDAP Data Interchange Format
- files)
-logwindow.c
- is the log window (tool menu / log window)
-main.c
- is the main program entry of Sylpheed
-mainwindow.c
- is the 3-paned main window
-manual.c
- help menu: links to manual and FAQ
-matcher.c
- this is some function to match the messages, to handle data structure
- of matcher/filtering/scoring system or to convert data structures
- to string.
-matcher_parser_lex.l
- this is the lexer used in the parse operation of the configuration files
- of the matcher/filtering/scoring system.
-matcher_parser_parse.y
- this is the parser of the configuration files of
- the matcher/filtering/scoring system.
-mbox.c
- is the mbox importer/exporter
-mbox_folder.c
- is the mbox folder support
-message_search.c
- dialog for searching current message
-messageview.c
- is the mail viewer part of the main window
-mh.c
- handles mh folders
-mimeview.c
- is the displaying of the list of the MIME part of the mail
- (at the top of the mail viewer when it is displayed)
-msgcache.c
- handles cached message infos
-mutt.c
- functions necessary to access MUTT address book file
-news.c
- is the news session handling (it uses the nntp protocol)
-noticeview.c
- *********** NO DESCRIPTION *********
-passphrase.c
- *********** NO DESCRIPTION *********
-pine.c
- functions necessary to access Pine address book file
-pop.c
- functions for POP3 sessions
-prefs_account.c
- is preferences for account dialog
-prefs_actions.c
- is preferences for action dialog
-prefs_common.c
- is the preferences dialog
-prefs_customheader.c
- is the preferences dialog for custom headers
-prefs_display_header.c
- is the preferences dialog for headers display
-prefs_filtering.c
- is preferences for filtering system dialog
-prefs_filtering_action.c
- let the user define the actions for a filtering rule
-prefs_folder_item.c
- is the preference dialog for a folder item
-prefs_gtk.c
- common functions for handling config windows
-prefs_matcher.c
- let the user define the condition for a filtering rule or a scoring rule
-prefs_scoring.c
- is preferences for scoring system dialog
-prefs_summary_column.c
- dialog for selecting items to display in summaryview
-prefs_template.c
- dialog for editing templates
-prefs_toolbar.c
- dialog for customizing toolbars
-procheader.c
- is the RFC822 headers parser.
-procmime.c
- is a MIME parser.
-procmsg.c
- handle the list of message files.
-progressdialog.c
- is a dialog box with a progress bar
-quote_fmt.c
- is the quotation system for forward or reply
-quote_fmt_lex.l
- is the lexer for the configuration of the quotation system
-quote_fmt_parse.y
- is the parser for the configuration of the quotation system
-recv.c
- this will receive some data from a file descriptor and write
- them to a file.
-rfc2015.c
- GPG support
-scoring.c
- handles the scoring process and function for scoring data structure
-select-keys.c
- dialog for selecting gpg keys
-send_message.c
- message sending to SMTP or through sendmail command.
-setup.c
- functions for first run (select mailbox dialog)
-sigstatus.c
- dialog for gpg signature check
-sourcewindow.c
- displays the source of the messages.
-ssl_manager.c
- dialog for handling SSL certificates
-statusbar.c
- functions for handling statusbar output
-stock_pixmap.c
- handle the pixmaps including pixmap theming
-string_match.c
- regexp pattern matching utilities
-summary_search.c
- dialog for searching folders
-summaryview.c
- is the displaying of list of the mail in a folder
- (up/right in the main window).
-syldap.c
- functions necessary to access LDAP servers
-textview.c
- is the mail (without MIME part) displaying of the
- mail viewer.
-toolbar.c
- functions for handling toolbars
-undo.c
- undo functions for message editor
-unmime.c
- decodes headers based on RFC2045 and RFC2047
-vcard.c
- functions necessary to access vCard files
-
-
-------------------------------------------------------------------------------
-2. Files in src/common/
-
-hooks.c
- functions for handling hooks
-log.c
- functions for logging (stdout, file, hook)
-md5.c
- This is MD5 calculation
-mgutils.c
- common tools for string and list handling
-nntp.c
- is the handling of the NNTP procotol
-passcrypt.c
- encoding of the password in the configuration files.
-plugin.c
- functions for plugin handling
-prefs.c
- is a preference file parser.
-quoted-printable.c
- handle quoted-printable conversion
-session.c
- This is network connection.
-smtp.c
- handles the SMTP and ESMTP protocol with authentification
-socket.c
- is some function to make it easier to use TCP/unix socket.
-ssl.c
- SSL init and cleanup functions
-ssl_certificate.c
- functions for checking SSL certificates
-stringtable.c
- functions for handling hashed string tables
-sylpheed.c
- application init and cleanup functions
-template.c
- functions for loading and saving templates
-utils.c
- common tool functions
-uuencode.c
- UU encoder
-xml.c
- XML parser
-xmlprops.c
- *********** NO DESCRIPTION *********
-
-
-------------------------------------------------------------------------------
-3. Files in src/gtk/
-
-about.c
- this is the about dialog
-colorlabel.c
- dialog for setting message color
-description_window.c
- dialog for showing descriptions (e.g. action syntax)
-filesel.c
- This is a file selection dialog
-gtkaspell.c
- spellchecking widget
-gtksctree.c
- This is a modified GtkCTree.
-gtkshruler.c
- ruler widget (shown in message editor)
-gtkstext.c
- This is a modified GtkText.
-gtkutils.c
- common tools for gtk widgets (e.g. ctree)
-gtkvscrollbutton.c
- composite widget to provide vertical scrolling
-manage_window.c
- *********** NO DESCRIPTION *********
-menu.c
- functions for handling menus
-pluginwindow.c
- dialog for loading and unloading plugins
-prefswindow.c
- treeview based preferences dialog
-sslcertwindow.c
- dialog to display, change or add SSL certificates
-
-
-------------------------------------------------------------------------------
-4. Hooks summary
-
-FOLDER_ITEM_UPDATE_HOOKLIST
- invocation after folder content has changed
- definition folder.h
- usage folder.c, trayicon plugin
- source FolderItemUpdateData
- return /
-FOLDER_UPDATE_HOOKLIST
- invocation after folder content has changed
- definition folder.h
- usage folder.c
- source FolderUpdateData
- return /
-LOG_APPEND_TEXT_HOOKLIST
- invocation after appending LogText to logfiles
- definition common/log.h
- usage logwindow.c, demo plugin
- source LogText
- return /
-MAIL_FILTERING_HOOKLIST
- invocation before applying filtering rules
- definition procmsg.h
- usage spamassassin plugin, clamav plugin.
- source MailFilteringData
- return TRUE stops further processing of current message
-MAIL_RECEIVE_HOOKLIST
- invocation after mail retrieval (before filtering)
- definition pop.h
- usage fetchinfo plugin
- source MailFilteringData
- return TRUE stops further processing of this message
-MSGINFO_UPDATE_HOOKLIST
- invocation when msginfo has changed
- definition procmsg.h
- usage summaryview.c
- source MsginfoUpdate
- return /
-PROGRESSINDICATOR_HOOKLIST
- invocation starts/stops/sets progressbar
- definition common/progressindicator.h
- usage mainwindow.c
- source ProgressData
- data MainWindow
- return /
-SSLCERT_ASK_HOOKLIST
- invocation asks for accepting new or modified SSL sertificates
- definition common/ssl_certificate.h
- usage ssl_certificate.c
- source SSLCertHookData
- return /
-
diff --git a/doc/src/readme.txt b/doc/src/readme.txt
@@ -1,19 +0,0 @@
-rfc977.txt NNTP
-rfc1939.txt POP3
-rfc2045.txt MIME 1
-rfc2046.txt MIME 2
-rfc2047.txt MIME 3
-rfc2048.txt MIME 4
-rfc2049.txt MIME 5
-rfc2183.txt The Content-Disposition Header Field
-rfc2342.txt IMAP4 Namespace
-rfc2359.txt IMAP4 UIDPLUS extension
-rfc2487.txt SMTP Service Extension for Secure SMTP over TLS
-rfc2554.txt SMTP Service Extension for Authentication
-rfc2683.txt IMAP4 Implementation Recommendations
-rfc2821.txt SMTP
-rfc2822.txt Internet Message Format
-rfc2980.txt Common NNTP Extensions
-rfc3156.txt MIME Security with OpenPGP
-rfc3501.txt INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
-rfc5804.txt A Protocol for Remotely Managing Sieve Scripts
diff --git a/doc/src/rfc1939.txt b/doc/src/rfc1939.txt
@@ -1,1291 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Myers
-Request for Comments: 1939 Carnegie Mellon
-STD: 53 M. Rose
-Obsoletes: 1725 Dover Beach Consulting, Inc.
-Category: Standards Track May 1996
-
-
- Post Office Protocol - Version 3
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Table of Contents
-
- 1. Introduction ................................................ 2
- 2. A Short Digression .......................................... 2
- 3. Basic Operation ............................................. 3
- 4. The AUTHORIZATION State ..................................... 4
- QUIT Command ................................................ 5
- 5. The TRANSACTION State ....................................... 5
- STAT Command ................................................ 6
- LIST Command ................................................ 6
- RETR Command ................................................ 8
- DELE Command ................................................ 8
- NOOP Command ................................................ 9
- RSET Command ................................................ 9
- 6. The UPDATE State ............................................ 10
- QUIT Command ................................................ 10
- 7. Optional POP3 Commands ...................................... 11
- TOP Command ................................................. 11
- UIDL Command ................................................ 12
- USER Command ................................................ 13
- PASS Command ................................................ 14
- APOP Command ................................................ 15
- 8. Scaling and Operational Considerations ...................... 16
- 9. POP3 Command Summary ........................................ 18
- 10. Example POP3 Session ....................................... 19
- 11. Message Format ............................................. 19
- 12. References ................................................. 20
- 13. Security Considerations .................................... 20
- 14. Acknowledgements ........................................... 20
- 15. Authors' Addresses ......................................... 21
- Appendix A. Differences from RFC 1725 .......................... 22
-
-
-
-Myers & Rose Standards Track [Page 1]
-
-RFC 1939 POP3 May 1996
-
-
- Appendix B. Command Index ...................................... 23
-
-1. Introduction
-
- On certain types of smaller nodes in the Internet it is often
- impractical to maintain a message transport system (MTS). For
- example, a workstation may not have sufficient resources (cycles,
- disk space) in order to permit a SMTP server [RFC821] and associated
- local mail delivery system to be kept resident and continuously
- running. Similarly, it may be expensive (or impossible) to keep a
- personal computer interconnected to an IP-style network for long
- amounts of time (the node is lacking the resource known as
- "connectivity").
-
- Despite this, it is often very useful to be able to manage mail on
- these smaller nodes, and they often support a user agent (UA) to aid
- the tasks of mail handling. To solve this problem, a node which can
- support an MTS entity offers a maildrop service to these less endowed
- nodes. The Post Office Protocol - Version 3 (POP3) is intended to
- permit a workstation to dynamically access a maildrop on a server
- host in a useful fashion. Usually, this means that the POP3 protocol
- is used to allow a workstation to retrieve mail that the server is
- holding for it.
-
- POP3 is not intended to provide extensive manipulation operations of
- mail on the server; normally, mail is downloaded and then deleted. A
- more advanced (and complex) protocol, IMAP4, is discussed in
- [RFC1730].
-
- For the remainder of this memo, the term "client host" refers to a
- host making use of the POP3 service, while the term "server host"
- refers to a host which offers the POP3 service.
-
-2. A Short Digression
-
- This memo does not specify how a client host enters mail into the
- transport system, although a method consistent with the philosophy of
- this memo is presented here:
-
- When the user agent on a client host wishes to enter a message
- into the transport system, it establishes an SMTP connection to
- its relay host and sends all mail to it. This relay host could
- be, but need not be, the POP3 server host for the client host. Of
- course, the relay host must accept mail for delivery to arbitrary
- recipient addresses, that functionality is not required of all
- SMTP servers.
-
-
-
-
-
-Myers & Rose Standards Track [Page 2]
-
-RFC 1939 POP3 May 1996
-
-
-3. Basic Operation
-
- Initially, the server host starts the POP3 service by listening on
- TCP port 110. When a client host wishes to make use of the service,
- it establishes a TCP connection with the server host. When the
- connection is established, the POP3 server sends a greeting. The
- client and POP3 server then exchange commands and responses
- (respectively) until the connection is closed or aborted.
-
- Commands in the POP3 consist of a case-insensitive keyword, possibly
- followed by one or more arguments. All commands are terminated by a
- CRLF pair. Keywords and arguments consist of printable ASCII
- characters. Keywords and arguments are each separated by a single
- SPACE character. Keywords are three or four characters long. Each
- argument may be up to 40 characters long.
-
- Responses in the POP3 consist of a status indicator and a keyword
- possibly followed by additional information. All responses are
- terminated by a CRLF pair. Responses may be up to 512 characters
- long, including the terminating CRLF. There are currently two status
- indicators: positive ("+OK") and negative ("-ERR"). Servers MUST
- send the "+OK" and "-ERR" in upper case.
-
- Responses to certain commands are multi-line. In these cases, which
- are clearly indicated below, after sending the first line of the
- response and a CRLF, any additional lines are sent, each terminated
- by a CRLF pair. When all lines of the response have been sent, a
- final line is sent, consisting of a termination octet (decimal code
- 046, ".") and a CRLF pair. If any line of the multi-line response
- begins with the termination octet, the line is "byte-stuffed" by
- pre-pending the termination octet to that line of the response.
- Hence a multi-line response is terminated with the five octets
- "CRLF.CRLF". When examining a multi-line response, the client checks
- to see if the line begins with the termination octet. If so and if
- octets other than CRLF follow, the first octet of the line (the
- termination octet) is stripped away. If so and if CRLF immediately
- follows the termination character, then the response from the POP
- server is ended and the line containing ".CRLF" is not considered
- part of the multi-line response.
-
- A POP3 session progresses through a number of states during its
- lifetime. Once the TCP connection has been opened and the POP3
- server has sent the greeting, the session enters the AUTHORIZATION
- state. In this state, the client must identify itself to the POP3
- server. Once the client has successfully done this, the server
- acquires resources associated with the client's maildrop, and the
- session enters the TRANSACTION state. In this state, the client
- requests actions on the part of the POP3 server. When the client has
-
-
-
-Myers & Rose Standards Track [Page 3]
-
-RFC 1939 POP3 May 1996
-
-
- issued the QUIT command, the session enters the UPDATE state. In
- this state, the POP3 server releases any resources acquired during
- the TRANSACTION state and says goodbye. The TCP connection is then
- closed.
-
- A server MUST respond to an unrecognized, unimplemented, or
- syntactically invalid command by responding with a negative status
- indicator. A server MUST respond to a command issued when the
- session is in an incorrect state by responding with a negative status
- indicator. There is no general method for a client to distinguish
- between a server which does not implement an optional command and a
- server which is unwilling or unable to process the command.
-
- A POP3 server MAY have an inactivity autologout timer. Such a timer
- MUST be of at least 10 minutes' duration. The receipt of any command
- from the client during that interval should suffice to reset the
- autologout timer. When the timer expires, the session does NOT enter
- the UPDATE state--the server should close the TCP connection without
- removing any messages or sending any response to the client.
-
-4. The AUTHORIZATION State
-
- Once the TCP connection has been opened by a POP3 client, the POP3
- server issues a one line greeting. This can be any positive
- response. An example might be:
-
- S: +OK POP3 server ready
-
- The POP3 session is now in the AUTHORIZATION state. The client must
- now identify and authenticate itself to the POP3 server. Two
- possible mechanisms for doing this are described in this document,
- the USER and PASS command combination and the APOP command. Both
- mechanisms are described later in this document. Additional
- authentication mechanisms are described in [RFC1734]. While there is
- no single authentication mechanism that is required of all POP3
- servers, a POP3 server must of course support at least one
- authentication mechanism.
-
- Once the POP3 server has determined through the use of any
- authentication command that the client should be given access to the
- appropriate maildrop, the POP3 server then acquires an exclusive-
- access lock on the maildrop, as necessary to prevent messages from
- being modified or removed before the session enters the UPDATE state.
- If the lock is successfully acquired, the POP3 server responds with a
- positive status indicator. The POP3 session now enters the
- TRANSACTION state, with no messages marked as deleted. If the
- maildrop cannot be opened for some reason (for example, a lock can
- not be acquired, the client is denied access to the appropriate
-
-
-
-Myers & Rose Standards Track [Page 4]
-
-RFC 1939 POP3 May 1996
-
-
- maildrop, or the maildrop cannot be parsed), the POP3 server responds
- with a negative status indicator. (If a lock was acquired but the
- POP3 server intends to respond with a negative status indicator, the
- POP3 server must release the lock prior to rejecting the command.)
- After returning a negative status indicator, the server may close the
- connection. If the server does not close the connection, the client
- may either issue a new authentication command and start again, or the
- client may issue the QUIT command.
-
- After the POP3 server has opened the maildrop, it assigns a message-
- number to each message, and notes the size of each message in octets.
- The first message in the maildrop is assigned a message-number of
- "1", the second is assigned "2", and so on, so that the nth message
- in a maildrop is assigned a message-number of "n". In POP3 commands
- and responses, all message-numbers and message sizes are expressed in
- base-10 (i.e., decimal).
-
- Here is the summary for the QUIT command when used in the
- AUTHORIZATION state:
-
- QUIT
-
- Arguments: none
-
- Restrictions: none
-
- Possible Responses:
- +OK
-
- Examples:
- C: QUIT
- S: +OK dewey POP3 server signing off
-
-5. The TRANSACTION State
-
- Once the client has successfully identified itself to the POP3 server
- and the POP3 server has locked and opened the appropriate maildrop,
- the POP3 session is now in the TRANSACTION state. The client may now
- issue any of the following POP3 commands repeatedly. After each
- command, the POP3 server issues a response. Eventually, the client
- issues the QUIT command and the POP3 session enters the UPDATE state.
-
-
-
-
-
-
-
-
-
-
-Myers & Rose Standards Track [Page 5]
-
-RFC 1939 POP3 May 1996
-
-
- Here are the POP3 commands valid in the TRANSACTION state:
-
- STAT
-
- Arguments: none
-
- Restrictions:
- may only be given in the TRANSACTION state
-
- Discussion:
- The POP3 server issues a positive response with a line
- containing information for the maildrop. This line is
- called a "drop listing" for that maildrop.
-
- In order to simplify parsing, all POP3 servers are
- required to use a certain format for drop listings. The
- positive response consists of "+OK" followed by a single
- space, the number of messages in the maildrop, a single
- space, and the size of the maildrop in octets. This memo
- makes no requirement on what follows the maildrop size.
- Minimal implementations should just end that line of the
- response with a CRLF pair. More advanced implementations
- may include other information.
-
- NOTE: This memo STRONGLY discourages implementations
- from supplying additional information in the drop
- listing. Other, optional, facilities are discussed
- later on which permit the client to parse the messages
- in the maildrop.
-
- Note that messages marked as deleted are not counted in
- either total.
-
- Possible Responses:
- +OK nn mm
-
- Examples:
- C: STAT
- S: +OK 2 320
-
-
- LIST [msg]
-
- Arguments:
- a message-number (optional), which, if present, may NOT
- refer to a message marked as deleted
-
-
-
-
-
-Myers & Rose Standards Track [Page 6]
-
-RFC 1939 POP3 May 1996
-
-
- Restrictions:
- may only be given in the TRANSACTION state
-
- Discussion:
- If an argument was given and the POP3 server issues a
- positive response with a line containing information for
- that message. This line is called a "scan listing" for
- that message.
-
- If no argument was given and the POP3 server issues a
- positive response, then the response given is multi-line.
- After the initial +OK, for each message in the maildrop,
- the POP3 server responds with a line containing
- information for that message. This line is also called a
- "scan listing" for that message. If there are no
- messages in the maildrop, then the POP3 server responds
- with no scan listings--it issues a positive response
- followed by a line containing a termination octet and a
- CRLF pair.
-
- In order to simplify parsing, all POP3 servers are
- required to use a certain format for scan listings. A
- scan listing consists of the message-number of the
- message, followed by a single space and the exact size of
- the message in octets. Methods for calculating the exact
- size of the message are described in the "Message Format"
- section below. This memo makes no requirement on what
- follows the message size in the scan listing. Minimal
- implementations should just end that line of the response
- with a CRLF pair. More advanced implementations may
- include other information, as parsed from the message.
-
- NOTE: This memo STRONGLY discourages implementations
- from supplying additional information in the scan
- listing. Other, optional, facilities are discussed
- later on which permit the client to parse the messages
- in the maildrop.
-
- Note that messages marked as deleted are not listed.
-
- Possible Responses:
- +OK scan listing follows
- -ERR no such message
-
- Examples:
- C: LIST
- S: +OK 2 messages (320 octets)
- S: 1 120
-
-
-
-Myers & Rose Standards Track [Page 7]
-
-RFC 1939 POP3 May 1996
-
-
- S: 2 200
- S: .
- ...
- C: LIST 2
- S: +OK 2 200
- ...
- C: LIST 3
- S: -ERR no such message, only 2 messages in maildrop
-
-
- RETR msg
-
- Arguments:
- a message-number (required) which may NOT refer to a
- message marked as deleted
-
- Restrictions:
- may only be given in the TRANSACTION state
-
- Discussion:
- If the POP3 server issues a positive response, then the
- response given is multi-line. After the initial +OK, the
- POP3 server sends the message corresponding to the given
- message-number, being careful to byte-stuff the termination
- character (as with all multi-line responses).
-
- Possible Responses:
- +OK message follows
- -ERR no such message
-
- Examples:
- C: RETR 1
- S: +OK 120 octets
- S: <the POP3 server sends the entire message here>
- S: .
-
-
- DELE msg
-
- Arguments:
- a message-number (required) which may NOT refer to a
- message marked as deleted
-
- Restrictions:
- may only be given in the TRANSACTION state
-
-
-
-
-
-
-Myers & Rose Standards Track [Page 8]
-
-RFC 1939 POP3 May 1996
-
-
- Discussion:
- The POP3 server marks the message as deleted. Any future
- reference to the message-number associated with the message
- in a POP3 command generates an error. The POP3 server does
- not actually delete the message until the POP3 session
- enters the UPDATE state.
-
- Possible Responses:
- +OK message deleted
- -ERR no such message
-
- Examples:
- C: DELE 1
- S: +OK message 1 deleted
- ...
- C: DELE 2
- S: -ERR message 2 already deleted
-
-
- NOOP
-
- Arguments: none
-
- Restrictions:
- may only be given in the TRANSACTION state
-
- Discussion:
- The POP3 server does nothing, it merely replies with a
- positive response.
-
- Possible Responses:
- +OK
-
- Examples:
- C: NOOP
- S: +OK
-
-
- RSET
-
- Arguments: none
-
- Restrictions:
- may only be given in the TRANSACTION state
-
- Discussion:
- If any messages have been marked as deleted by the POP3
- server, they are unmarked. The POP3 server then replies
-
-
-
-Myers & Rose Standards Track [Page 9]
-
-RFC 1939 POP3 May 1996
-
-
- with a positive response.
-
- Possible Responses:
- +OK
-
- Examples:
- C: RSET
- S: +OK maildrop has 2 messages (320 octets)
-
-6. The UPDATE State
-
- When the client issues the QUIT command from the TRANSACTION state,
- the POP3 session enters the UPDATE state. (Note that if the client
- issues the QUIT command from the AUTHORIZATION state, the POP3
- session terminates but does NOT enter the UPDATE state.)
-
- If a session terminates for some reason other than a client-issued
- QUIT command, the POP3 session does NOT enter the UPDATE state and
- MUST not remove any messages from the maildrop.
-
- QUIT
-
- Arguments: none
-
- Restrictions: none
-
- Discussion:
- The POP3 server removes all messages marked as deleted
- from the maildrop and replies as to the status of this
- operation. If there is an error, such as a resource
- shortage, encountered while removing messages, the
- maildrop may result in having some or none of the messages
- marked as deleted be removed. In no case may the server
- remove any messages not marked as deleted.
-
- Whether the removal was successful or not, the server
- then releases any exclusive-access lock on the maildrop
- and closes the TCP connection.
-
- Possible Responses:
- +OK
- -ERR some deleted messages not removed
-
- Examples:
- C: QUIT
- S: +OK dewey POP3 server signing off (maildrop empty)
- ...
- C: QUIT
-
-
-
-Myers & Rose Standards Track [Page 10]
-
-RFC 1939 POP3 May 1996
-
-
- S: +OK dewey POP3 server signing off (2 messages left)
- ...
-
-7. Optional POP3 Commands
-
- The POP3 commands discussed above must be supported by all minimal
- implementations of POP3 servers.
-
- The optional POP3 commands described below permit a POP3 client
- greater freedom in message handling, while preserving a simple POP3
- server implementation.
-
- NOTE: This memo STRONGLY encourages implementations to support
- these commands in lieu of developing augmented drop and scan
- listings. In short, the philosophy of this memo is to put
- intelligence in the part of the POP3 client and not the POP3
- server.
-
- TOP msg n
-
- Arguments:
- a message-number (required) which may NOT refer to to a
- message marked as deleted, and a non-negative number
- of lines (required)
-
- Restrictions:
- may only be given in the TRANSACTION state
-
- Discussion:
- If the POP3 server issues a positive response, then the
- response given is multi-line. After the initial +OK, the
- POP3 server sends the headers of the message, the blank
- line separating the headers from the body, and then the
- number of lines of the indicated message's body, being
- careful to byte-stuff the termination character (as with
- all multi-line responses).
-
- Note that if the number of lines requested by the POP3
- client is greater than than the number of lines in the
- body, then the POP3 server sends the entire message.
-
- Possible Responses:
- +OK top of message follows
- -ERR no such message
-
- Examples:
- C: TOP 1 10
- S: +OK
-
-
-
-Myers & Rose Standards Track [Page 11]
-
-RFC 1939 POP3 May 1996
-
-
- S: <the POP3 server sends the headers of the
- message, a blank line, and the first 10 lines
- of the body of the message>
- S: .
- ...
- C: TOP 100 3
- S: -ERR no such message
-
-
- UIDL [msg]
-
- Arguments:
- a message-number (optional), which, if present, may NOT
- refer to a message marked as deleted
-
- Restrictions:
- may only be given in the TRANSACTION state.
-
- Discussion:
- If an argument was given and the POP3 server issues a positive
- response with a line containing information for that message.
- This line is called a "unique-id listing" for that message.
-
- If no argument was given and the POP3 server issues a positive
- response, then the response given is multi-line. After the
- initial +OK, for each message in the maildrop, the POP3 server
- responds with a line containing information for that message.
- This line is called a "unique-id listing" for that message.
-
- In order to simplify parsing, all POP3 servers are required to
- use a certain format for unique-id listings. A unique-id
- listing consists of the message-number of the message,
- followed by a single space and the unique-id of the message.
- No information follows the unique-id in the unique-id listing.
-
- The unique-id of a message is an arbitrary server-determined
- string, consisting of one to 70 characters in the range 0x21
- to 0x7E, which uniquely identifies a message within a
- maildrop and which persists across sessions. This
- persistence is required even if a session ends without
- entering the UPDATE state. The server should never reuse an
- unique-id in a given maildrop, for as long as the entity
- using the unique-id exists.
-
- Note that messages marked as deleted are not listed.
-
- While it is generally preferable for server implementations
- to store arbitrarily assigned unique-ids in the maildrop,
-
-
-
-Myers & Rose Standards Track [Page 12]
-
-RFC 1939 POP3 May 1996
-
-
- this specification is intended to permit unique-ids to be
- calculated as a hash of the message. Clients should be able
- to handle a situation where two identical copies of a
- message in a maildrop have the same unique-id.
-
- Possible Responses:
- +OK unique-id listing follows
- -ERR no such message
-
- Examples:
- C: UIDL
- S: +OK
- S: 1 whqtswO00WBw418f9t5JxYwZ
- S: 2 QhdPYR:00WBw1Ph7x7
- S: .
- ...
- C: UIDL 2
- S: +OK 2 QhdPYR:00WBw1Ph7x7
- ...
- C: UIDL 3
- S: -ERR no such message, only 2 messages in maildrop
-
-
- USER name
-
- Arguments:
- a string identifying a mailbox (required), which is of
- significance ONLY to the server
-
- Restrictions:
- may only be given in the AUTHORIZATION state after the POP3
- greeting or after an unsuccessful USER or PASS command
-
- Discussion:
- To authenticate using the USER and PASS command
- combination, the client must first issue the USER
- command. If the POP3 server responds with a positive
- status indicator ("+OK"), then the client may issue
- either the PASS command to complete the authentication,
- or the QUIT command to terminate the POP3 session. If
- the POP3 server responds with a negative status indicator
- ("-ERR") to the USER command, then the client may either
- issue a new authentication command or may issue the QUIT
- command.
-
- The server may return a positive response even though no
- such mailbox exists. The server may return a negative
- response if mailbox exists, but does not permit plaintext
-
-
-
-Myers & Rose Standards Track [Page 13]
-
-RFC 1939 POP3 May 1996
-
-
- password authentication.
-
- Possible Responses:
- +OK name is a valid mailbox
- -ERR never heard of mailbox name
-
- Examples:
- C: USER frated
- S: -ERR sorry, no mailbox for frated here
- ...
- C: USER mrose
- S: +OK mrose is a real hoopy frood
-
-
- PASS string
-
- Arguments:
- a server/mailbox-specific password (required)
-
- Restrictions:
- may only be given in the AUTHORIZATION state immediately
- after a successful USER command
-
- Discussion:
- When the client issues the PASS command, the POP3 server
- uses the argument pair from the USER and PASS commands to
- determine if the client should be given access to the
- appropriate maildrop.
-
- Since the PASS command has exactly one argument, a POP3
- server may treat spaces in the argument as part of the
- password, instead of as argument separators.
-
- Possible Responses:
- +OK maildrop locked and ready
- -ERR invalid password
- -ERR unable to lock maildrop
-
- Examples:
- C: USER mrose
- S: +OK mrose is a real hoopy frood
- C: PASS secret
- S: -ERR maildrop already locked
- ...
- C: USER mrose
- S: +OK mrose is a real hoopy frood
- C: PASS secret
- S: +OK mrose's maildrop has 2 messages (320 octets)
-
-
-
-Myers & Rose Standards Track [Page 14]
-
-RFC 1939 POP3 May 1996
-
-
- APOP name digest
-
- Arguments:
- a string identifying a mailbox and a MD5 digest string
- (both required)
-
- Restrictions:
- may only be given in the AUTHORIZATION state after the POP3
- greeting or after an unsuccessful USER or PASS command
-
- Discussion:
- Normally, each POP3 session starts with a USER/PASS
- exchange. This results in a server/user-id specific
- password being sent in the clear on the network. For
- intermittent use of POP3, this may not introduce a sizable
- risk. However, many POP3 client implementations connect to
- the POP3 server on a regular basis -- to check for new
- mail. Further the interval of session initiation may be on
- the order of five minutes. Hence, the risk of password
- capture is greatly enhanced.
-
- An alternate method of authentication is required which
- provides for both origin authentication and replay
- protection, but which does not involve sending a password
- in the clear over the network. The APOP command provides
- this functionality.
-
- A POP3 server which implements the APOP command will
- include a timestamp in its banner greeting. The syntax of
- the timestamp corresponds to the `msg-id' in [RFC822], and
- MUST be different each time the POP3 server issues a banner
- greeting. For example, on a UNIX implementation in which a
- separate UNIX process is used for each instance of a POP3
- server, the syntax of the timestamp might be:
-
- <process-ID.clock@hostname>
-
- where `process-ID' is the decimal value of the process's
- PID, clock is the decimal value of the system clock, and
- hostname is the fully-qualified domain-name corresponding
- to the host where the POP3 server is running.
-
- The POP3 client makes note of this timestamp, and then
- issues the APOP command. The `name' parameter has
- identical semantics to the `name' parameter of the USER
- command. The `digest' parameter is calculated by applying
- the MD5 algorithm [RFC1321] to a string consisting of the
- timestamp (including angle-brackets) followed by a shared
-
-
-
-Myers & Rose Standards Track [Page 15]
-
-RFC 1939 POP3 May 1996
-
-
- secret. This shared secret is a string known only to the
- POP3 client and server. Great care should be taken to
- prevent unauthorized disclosure of the secret, as knowledge
- of the secret will allow any entity to successfully
- masquerade as the named user. The `digest' parameter
- itself is a 16-octet value which is sent in hexadecimal
- format, using lower-case ASCII characters.
-
- When the POP3 server receives the APOP command, it verifies
- the digest provided. If the digest is correct, the POP3
- server issues a positive response, and the POP3 session
- enters the TRANSACTION state. Otherwise, a negative
- response is issued and the POP3 session remains in the
- AUTHORIZATION state.
-
- Note that as the length of the shared secret increases, so
- does the difficulty of deriving it. As such, shared
- secrets should be long strings (considerably longer than
- the 8-character example shown below).
-
- Possible Responses:
- +OK maildrop locked and ready
- -ERR permission denied
-
- Examples:
- S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
- C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
- S: +OK maildrop has 1 message (369 octets)
-
- In this example, the shared secret is the string `tan-
- staaf'. Hence, the MD5 algorithm is applied to the string
-
- <1896.697170952@dbc.mtview.ca.us>tanstaaf
-
- which produces a digest value of
-
- c4c9334bac560ecc979e58001b3e22fb
-
-8. Scaling and Operational Considerations
-
- Since some of the optional features described above were added to the
- POP3 protocol, experience has accumulated in using them in large-
- scale commercial post office operations where most of the users are
- unrelated to each other. In these situations and others, users and
- vendors of POP3 clients have discovered that the combination of using
- the UIDL command and not issuing the DELE command can provide a weak
- version of the "maildrop as semi-permanent repository" functionality
- normally associated with IMAP. Of course the other capabilities of
-
-
-
-Myers & Rose Standards Track [Page 16]
-
-RFC 1939 POP3 May 1996
-
-
- IMAP, such as polling an existing connection for newly arrived
- messages and supporting multiple folders on the server, are not
- present in POP3.
-
- When these facilities are used in this way by casual users, there has
- been a tendency for already-read messages to accumulate on the server
- without bound. This is clearly an undesirable behavior pattern from
- the standpoint of the server operator. This situation is aggravated
- by the fact that the limited capabilities of the POP3 do not permit
- efficient handling of maildrops which have hundreds or thousands of
- messages.
-
- Consequently, it is recommended that operators of large-scale multi-
- user servers, especially ones in which the user's only access to the
- maildrop is via POP3, consider such options as:
-
- * Imposing a per-user maildrop storage quota or the like.
-
- A disadvantage to this option is that accumulation of messages may
- result in the user's inability to receive new ones into the
- maildrop. Sites which choose this option should be sure to inform
- users of impending or current exhaustion of quota, perhaps by
- inserting an appropriate message into the user's maildrop.
-
- * Enforce a site policy regarding mail retention on the server.
-
- Sites are free to establish local policy regarding the storage and
- retention of messages on the server, both read and unread. For
- example, a site might delete unread messages from the server after
- 60 days and delete read messages after 7 days. Such message
- deletions are outside the scope of the POP3 protocol and are not
- considered a protocol violation.
-
- Server operators enforcing message deletion policies should take
- care to make all users aware of the policies in force.
-
- Clients must not assume that a site policy will automate message
- deletions, and should continue to explicitly delete messages using
- the DELE command when appropriate.
-
- It should be noted that enforcing site message deletion policies
- may be confusing to the user community, since their POP3 client
- may contain configuration options to leave mail on the server
- which will not in fact be supported by the server.
-
- One special case of a site policy is that messages may only be
- downloaded once from the server, and are deleted after this has
- been accomplished. This could be implemented in POP3 server
-
-
-
-Myers & Rose Standards Track [Page 17]
-
-RFC 1939 POP3 May 1996
-
-
- software by the following mechanism: "following a POP3 login by a
- client which was ended by a QUIT, delete all messages downloaded
- during the session with the RETR command". It is important not to
- delete messages in the event of abnormal connection termination
- (ie, if no QUIT was received from the client) because the client
- may not have successfully received or stored the messages.
- Servers implementing a download-and-delete policy may also wish to
- disable or limit the optional TOP command, since it could be used
- as an alternate mechanism to download entire messages.
-
-9. POP3 Command Summary
-
- Minimal POP3 Commands:
-
- USER name valid in the AUTHORIZATION state
- PASS string
- QUIT
-
- STAT valid in the TRANSACTION state
- LIST [msg]
- RETR msg
- DELE msg
- NOOP
- RSET
- QUIT
-
- Optional POP3 Commands:
-
- APOP name digest valid in the AUTHORIZATION state
-
- TOP msg n valid in the TRANSACTION state
- UIDL [msg]
-
- POP3 Replies:
-
- +OK
- -ERR
-
- Note that with the exception of the STAT, LIST, and UIDL commands,
- the reply given by the POP3 server to any command is significant
- only to "+OK" and "-ERR". Any text occurring after this reply
- may be ignored by the client.
-
-
-
-
-
-
-
-
-
-Myers & Rose Standards Track [Page 18]
-
-RFC 1939 POP3 May 1996
-
-
-10. Example POP3 Session
-
- S: <wait for connection on TCP port 110>
- C: <open connection>
- S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
- C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
- S: +OK mrose's maildrop has 2 messages (320 octets)
- C: STAT
- S: +OK 2 320
- C: LIST
- S: +OK 2 messages (320 octets)
- S: 1 120
- S: 2 200
- S: .
- C: RETR 1
- S: +OK 120 octets
- S: <the POP3 server sends message 1>
- S: .
- C: DELE 1
- S: +OK message 1 deleted
- C: RETR 2
- S: +OK 200 octets
- S: <the POP3 server sends message 2>
- S: .
- C: DELE 2
- S: +OK message 2 deleted
- C: QUIT
- S: +OK dewey POP3 server signing off (maildrop empty)
- C: <close connection>
- S: <wait for next connection>
-
-11. Message Format
-
- All messages transmitted during a POP3 session are assumed to conform
- to the standard for the format of Internet text messages [RFC822].
-
- It is important to note that the octet count for a message on the
- server host may differ from the octet count assigned to that message
- due to local conventions for designating end-of-line. Usually,
- during the AUTHORIZATION state of the POP3 session, the POP3 server
- can calculate the size of each message in octets when it opens the
- maildrop. For example, if the POP3 server host internally represents
- end-of-line as a single character, then the POP3 server simply counts
- each occurrence of this character in a message as two octets. Note
- that lines in the message which start with the termination octet need
- not (and must not) be counted twice, since the POP3 client will
- remove all byte-stuffed termination characters when it receives a
- multi-line response.
-
-
-
-Myers & Rose Standards Track [Page 19]
-
-RFC 1939 POP3 May 1996
-
-
-12. References
-
- [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
- 821, USC/Information Sciences Institute, August 1982.
-
- [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text
- Messages", STD 11, RFC 822, University of Delaware, August 1982.
-
- [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
- MIT Laboratory for Computer Science, April 1992.
-
- [RFC1730] Crispin, M., "Internet Message Access Protocol - Version
- 4", RFC 1730, University of Washington, December 1994.
-
- [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,
- Carnegie Mellon, December 1994.
-
-13. Security Considerations
-
- It is conjectured that use of the APOP command provides origin
- identification and replay protection for a POP3 session.
- Accordingly, a POP3 server which implements both the PASS and APOP
- commands should not allow both methods of access for a given user;
- that is, for a given mailbox name, either the USER/PASS command
- sequence or the APOP command is allowed, but not both.
-
- Further, note that as the length of the shared secret increases, so
- does the difficulty of deriving it.
-
- Servers that answer -ERR to the USER command are giving potential
- attackers clues about which names are valid.
-
- Use of the PASS command sends passwords in the clear over the
- network.
-
- Use of the RETR and TOP commands sends mail in the clear over the
- network.
-
- Otherwise, security issues are not discussed in this memo.
-
-14. Acknowledgements
-
- The POP family has a long and checkered history. Although primarily
- a minor revision to RFC 1460, POP3 is based on the ideas presented in
- RFCs 918, 937, and 1081.
-
- In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff
- provided significant comments on the APOP command.
-
-
-
-Myers & Rose Standards Track [Page 20]
-
-RFC 1939 POP3 May 1996
-
-
-15. Authors' Addresses
-
- John G. Myers
- Carnegie-Mellon University
- 5000 Forbes Ave
- Pittsburgh, PA 15213
-
- EMail: jgm+@cmu.edu
-
-
- Marshall T. Rose
- Dover Beach Consulting, Inc.
- 420 Whisman Court
- Mountain View, CA 94043-2186
-
- EMail: mrose@dbc.mtview.ca.us
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Myers & Rose Standards Track [Page 21]
-
-RFC 1939 POP3 May 1996
-
-
-Appendix A. Differences from RFC 1725
-
- This memo is a revision to RFC 1725, a Draft Standard. It makes the
- following changes from that document:
-
- - clarifies that command keywords are case insensitive.
-
- - specifies that servers must send "+OK" and "-ERR" in
- upper case.
-
- - specifies that the initial greeting is a positive response,
- instead of any string which should be a positive response.
-
- - clarifies behavior for unimplemented commands.
-
- - makes the USER and PASS commands optional.
-
- - clarified the set of possible responses to the USER command.
-
- - reverses the order of the examples in the USER and PASS
- commands, to reduce confusion.
-
- - clarifies that the PASS command may only be given immediately
- after a successful USER command.
-
- - clarified the persistence requirements of UIDs and added some
- implementation notes.
-
- - specifies a UID length limitation of one to 70 octets.
-
- - specifies a status indicator length limitation
- of 512 octets, including the CRLF.
-
- - clarifies that LIST with no arguments on an empty mailbox
- returns success.
-
- - adds a reference from the LIST command to the Message Format
- section
-
- - clarifies the behavior of QUIT upon failure
-
- - clarifies the security section to not imply the use of the
- USER command with the APOP command.
-
- - adds references to RFCs 1730 and 1734
-
- - clarifies the method by which a UA may enter mail into the
- transport system.
-
-
-
-Myers & Rose Standards Track [Page 22]
-
-RFC 1939 POP3 May 1996
-
-
- - clarifies that the second argument to the TOP command is a
- number of lines.
-
- - changes the suggestion in the Security Considerations section
- for a server to not accept both PASS and APOP for a given user
- from a "must" to a "should".
-
- - adds a section on scaling and operational considerations
-
-Appendix B. Command Index
-
- APOP ....................................................... 15
- DELE ....................................................... 8
- LIST ....................................................... 6
- NOOP ....................................................... 9
- PASS ....................................................... 14
- QUIT ....................................................... 5
- QUIT ....................................................... 10
- RETR ....................................................... 8
- RSET ....................................................... 9
- STAT ....................................................... 6
- TOP ........................................................ 11
- UIDL ....................................................... 12
- USER ....................................................... 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Myers & Rose Standards Track [Page 23]
-
diff --git a/doc/src/rfc2045.txt b/doc/src/rfc2045.txt
@@ -1,1739 +0,0 @@
-
-
-
-
-
-
-Network Working Group N. Freed
-Request for Comments: 2045 Innosoft
-Obsoletes: 1521, 1522, 1590 N. Borenstein
-Category: Standards Track First Virtual
- November 1996
-
-
- Multipurpose Internet Mail Extensions
- (MIME) Part One:
- Format of Internet Message Bodies
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- STD 11, RFC 822, defines a message representation protocol specifying
- considerable detail about US-ASCII message headers, and leaves the
- message content, or message body, as flat US-ASCII text. This set of
- documents, collectively called the Multipurpose Internet Mail
- Extensions, or MIME, redefines the format of messages to allow for
-
- (1) textual message bodies in character sets other than
- US-ASCII,
-
- (2) an extensible set of different formats for non-textual
- message bodies,
-
- (3) multi-part message bodies, and
-
- (4) textual header information in character sets other than
- US-ASCII.
-
- These documents are based on earlier work documented in RFC 934, STD
- 11, and RFC 1049, but extends and revises them. Because RFC 822 said
- so little about message bodies, these documents are largely
- orthogonal to (rather than a revision of) RFC 822.
-
- This initial document specifies the various headers used to describe
- the structure of MIME messages. The second document, RFC 2046,
- defines the general structure of the MIME media typing system and
- defines an initial set of media types. The third document, RFC 2047,
- describes extensions to RFC 822 to allow non-US-ASCII text data in
-
-
-
-Freed & Borenstein Standards Track [Page 1]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- Internet mail header fields. The fourth document, RFC 2048, specifies
- various IANA registration procedures for MIME-related facilities. The
- fifth and final document, RFC 2049, describes MIME conformance
- criteria as well as providing some illustrative examples of MIME
- message formats, acknowledgements, and the bibliography.
-
- These documents are revisions of RFCs 1521, 1522, and 1590, which
- themselves were revisions of RFCs 1341 and 1342. An appendix in RFC
- 2049 describes differences and changes from previous versions.
-
-Table of Contents
-
- 1. Introduction ......................................... 3
- 2. Definitions, Conventions, and Generic BNF Grammar .... 5
- 2.1 CRLF ................................................ 5
- 2.2 Character Set ....................................... 6
- 2.3 Message ............................................. 6
- 2.4 Entity .............................................. 6
- 2.5 Body Part ........................................... 7
- 2.6 Body ................................................ 7
- 2.7 7bit Data ........................................... 7
- 2.8 8bit Data ........................................... 7
- 2.9 Binary Data ......................................... 7
- 2.10 Lines .............................................. 7
- 3. MIME Header Fields ................................... 8
- 4. MIME-Version Header Field ............................ 8
- 5. Content-Type Header Field ............................ 10
- 5.1 Syntax of the Content-Type Header Field ............. 12
- 5.2 Content-Type Defaults ............................... 14
- 6. Content-Transfer-Encoding Header Field ............... 14
- 6.1 Content-Transfer-Encoding Syntax .................... 14
- 6.2 Content-Transfer-Encodings Semantics ................ 15
- 6.3 New Content-Transfer-Encodings ...................... 16
- 6.4 Interpretation and Use .............................. 16
- 6.5 Translating Encodings ............................... 18
- 6.6 Canonical Encoding Model ............................ 19
- 6.7 Quoted-Printable Content-Transfer-Encoding .......... 19
- 6.8 Base64 Content-Transfer-Encoding .................... 24
- 7. Content-ID Header Field .............................. 26
- 8. Content-Description Header Field ..................... 27
- 9. Additional MIME Header Fields ........................ 27
- 10. Summary ............................................. 27
- 11. Security Considerations ............................. 27
- 12. Authors' Addresses .................................. 28
- A. Collected Grammar .................................... 29
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 2]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-1. Introduction
-
- Since its publication in 1982, RFC 822 has defined the standard
- format of textual mail messages on the Internet. Its success has
- been such that the RFC 822 format has been adopted, wholly or
- partially, well beyond the confines of the Internet and the Internet
- SMTP transport defined by RFC 821. As the format has seen wider use,
- a number of limitations have proven increasingly restrictive for the
- user community.
-
- RFC 822 was intended to specify a format for text messages. As such,
- non-text messages, such as multimedia messages that might include
- audio or images, are simply not mentioned. Even in the case of text,
- however, RFC 822 is inadequate for the needs of mail users whose
- languages require the use of character sets richer than US-ASCII.
- Since RFC 822 does not specify mechanisms for mail containing audio,
- video, Asian language text, or even text in most European languages,
- additional specifications are needed.
-
- One of the notable limitations of RFC 821/822 based mail systems is
- the fact that they limit the contents of electronic mail messages to
- relatively short lines (e.g. 1000 characters or less [RFC-821]) of
- 7bit US-ASCII. This forces users to convert any non-textual data
- that they may wish to send into seven-bit bytes representable as
- printable US-ASCII characters before invoking a local mail UA (User
- Agent, a program with which human users send and receive mail).
- Examples of such encodings currently used in the Internet include
- pure hexadecimal, uuencode, the 3-in-4 base 64 scheme specified in
- RFC 1421, the Andrew Toolkit Representation [ATK], and many others.
-
- The limitations of RFC 822 mail become even more apparent as gateways
- are designed to allow for the exchange of mail messages between RFC
- 822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for the
- inclusion of non-textual material within electronic mail messages.
- The current standards for the mapping of X.400 messages to RFC 822
- messages specify either that X.400 non-textual material must be
- converted to (not encoded in) IA5Text format, or that they must be
- discarded, notifying the RFC 822 user that discarding has occurred.
- This is clearly undesirable, as information that a user may wish to
- receive is lost. Even though a user agent may not have the
- capability of dealing with the non-textual material, the user might
- have some mechanism external to the UA that can extract useful
- information from the material. Moreover, it does not allow for the
- fact that the message may eventually be gatewayed back into an X.400
- message handling system (i.e., the X.400 message is "tunneled"
- through Internet mail), where the non-textual information would
- definitely become useful again.
-
-
-
-
-Freed & Borenstein Standards Track [Page 3]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- This document describes several mechanisms that combine to solve most
- of these problems without introducing any serious incompatibilities
- with the existing world of RFC 822 mail. In particular, it
- describes:
-
- (1) A MIME-Version header field, which uses a version
- number to declare a message to be conformant with MIME
- and allows mail processing agents to distinguish
- between such messages and those generated by older or
- non-conformant software, which are presumed to lack
- such a field.
-
- (2) A Content-Type header field, generalized from RFC 1049,
- which can be used to specify the media type and subtype
- of data in the body of a message and to fully specify
- the native representation (canonical form) of such
- data.
-
- (3) A Content-Transfer-Encoding header field, which can be
- used to specify both the encoding transformation that
- was applied to the body and the domain of the result.
- Encoding transformations other than the identity
- transformation are usually applied to data in order to
- allow it to pass through mail transport mechanisms
- which may have data or character set limitations.
-
- (4) Two additional header fields that can be used to
- further describe the data in a body, the Content-ID and
- Content-Description header fields.
-
- All of the header fields defined in this document are subject to the
- general syntactic rules for header fields specified in RFC 822. In
- particular, all of these header fields except for Content-Disposition
- can include RFC 822 comments, which have no semantic content and
- should be ignored during MIME processing.
-
- Finally, to specify and promote interoperability, RFC 2049 provides a
- basic applicability statement for a subset of the above mechanisms
- that defines a minimal level of "conformance" with this document.
-
- HISTORICAL NOTE: Several of the mechanisms described in this set of
- documents may seem somewhat strange or even baroque at first reading.
- It is important to note that compatibility with existing standards
- AND robustness across existing practice were two of the highest
- priorities of the working group that developed this set of documents.
- In particular, compatibility was always favored over elegance.
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 4]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- Please refer to the current edition of the "Internet Official
- Protocol Standards" for the standardization state and status of this
- protocol. RFC 822 and STD 3, RFC 1123 also provide essential
- background for MIME since no conforming implementation of MIME can
- violate them. In addition, several other informational RFC documents
- will be of interest to the MIME implementor, in particular RFC 1344,
- RFC 1345, and RFC 1524.
-
-2. Definitions, Conventions, and Generic BNF Grammar
-
- Although the mechanisms specified in this set of documents are all
- described in prose, most are also described formally in the augmented
- BNF notation of RFC 822. Implementors will need to be familiar with
- this notation in order to understand this set of documents, and are
- referred to RFC 822 for a complete explanation of the augmented BNF
- notation.
-
- Some of the augmented BNF in this set of documents makes named
- references to syntax rules defined in RFC 822. A complete formal
- grammar, then, is obtained by combining the collected grammar
- appendices in each document in this set with the BNF of RFC 822 plus
- the modifications to RFC 822 defined in RFC 1123 (which specifically
- changes the syntax for `return', `date' and `mailbox').
-
- All numeric and octet values are given in decimal notation in this
- set of documents. All media type values, subtype values, and
- parameter names as defined are case-insensitive. However, parameter
- values are case-sensitive unless otherwise specified for the specific
- parameter.
-
- FORMATTING NOTE: Notes, such at this one, provide additional
- nonessential information which may be skipped by the reader without
- missing anything essential. The primary purpose of these non-
- essential notes is to convey information about the rationale of this
- set of documents, or to place these documents in the proper
- historical or evolutionary context. Such information may in
- particular be skipped by those who are focused entirely on building a
- conformant implementation, but may be of use to those who wish to
- understand why certain design choices were made.
-
-2.1. CRLF
-
- The term CRLF, in this set of documents, refers to the sequence of
- octets corresponding to the two US-ASCII characters CR (decimal value
- 13) and LF (decimal value 10) which, taken together, in this order,
- denote a line break in RFC 822 mail.
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 5]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-2.2. Character Set
-
- The term "character set" is used in MIME to refer to a method of
- converting a sequence of octets into a sequence of characters. Note
- that unconditional and unambiguous conversion in the other direction
- is not required, in that not all characters may be representable by a
- given character set and a character set may provide more than one
- sequence of octets to represent a particular sequence of characters.
-
- This definition is intended to allow various kinds of character
- encodings, from simple single-table mappings such as US-ASCII to
- complex table switching methods such as those that use ISO 2022's
- techniques, to be used as character sets. However, the definition
- associated with a MIME character set name must fully specify the
- mapping to be performed. In particular, use of external profiling
- information to determine the exact mapping is not permitted.
-
- NOTE: The term "character set" was originally to describe such
- straightforward schemes as US-ASCII and ISO-8859-1 which have a
- simple one-to-one mapping from single octets to single characters.
- Multi-octet coded character sets and switching techniques make the
- situation more complex. For example, some communities use the term
- "character encoding" for what MIME calls a "character set", while
- using the phrase "coded character set" to denote an abstract mapping
- from integers (not octets) to characters.
-
-2.3. Message
-
- The term "message", when not further qualified, means either a
- (complete or "top-level") RFC 822 message being transferred on a
- network, or a message encapsulated in a body of type "message/rfc822"
- or "message/partial".
-
-2.4. Entity
-
- The term "entity", refers specifically to the MIME-defined header
- fields and contents of either a message or one of the parts in the
- body of a multipart entity. The specification of such entities is
- the essence of MIME. Since the contents of an entity are often
- called the "body", it makes sense to speak about the body of an
- entity. Any sort of field may be present in the header of an entity,
- but only those fields whose names begin with "content-" actually have
- any MIME-related meaning. Note that this does NOT imply thay they
- have no meaning at all -- an entity that is also a message has non-
- MIME header fields whose meanings are defined by RFC 822.
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 6]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-2.5. Body Part
-
- The term "body part" refers to an entity inside of a multipart
- entity.
-
-2.6. Body
-
- The term "body", when not further qualified, means the body of an
- entity, that is, the body of either a message or of a body part.
-
- NOTE: The previous four definitions are clearly circular. This is
- unavoidable, since the overall structure of a MIME message is indeed
- recursive.
-
-2.7. 7bit Data
-
- "7bit data" refers to data that is all represented as relatively
- short lines with 998 octets or less between CRLF line separation
- sequences [RFC-821]. No octets with decimal values greater than 127
- are allowed and neither are NULs (octets with decimal value 0). CR
- (decimal value 13) and LF (decimal value 10) octets only occur as
- part of CRLF line separation sequences.
-
-2.8. 8bit Data
-
- "8bit data" refers to data that is all represented as relatively
- short lines with 998 octets or less between CRLF line separation
- sequences [RFC-821]), but octets with decimal values greater than 127
- may be used. As with "7bit data" CR and LF octets only occur as part
- of CRLF line separation sequences and no NULs are allowed.
-
-2.9. Binary Data
-
- "Binary data" refers to data where any sequence of octets whatsoever
- is allowed.
-
-2.10. Lines
-
- "Lines" are defined as sequences of octets separated by a CRLF
- sequences. This is consistent with both RFC 821 and RFC 822.
- "Lines" only refers to a unit of data in a message, which may or may
- not correspond to something that is actually displayed by a user
- agent.
-
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 7]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-3. MIME Header Fields
-
- MIME defines a number of new RFC 822 header fields that are used to
- describe the content of a MIME entity. These header fields occur in
- at least two contexts:
-
- (1) As part of a regular RFC 822 message header.
-
- (2) In a MIME body part header within a multipart
- construct.
-
- The formal definition of these header fields is as follows:
-
- entity-headers := [ content CRLF ]
- [ encoding CRLF ]
- [ id CRLF ]
- [ description CRLF ]
- *( MIME-extension-field CRLF )
-
- MIME-message-headers := entity-headers
- fields
- version CRLF
- ; The ordering of the header
- ; fields implied by this BNF
- ; definition should be ignored.
-
- MIME-part-headers := entity-headers
- [ fields ]
- ; Any field not beginning with
- ; "content-" can have no defined
- ; meaning and may be ignored.
- ; The ordering of the header
- ; fields implied by this BNF
- ; definition should be ignored.
-
- The syntax of the various specific MIME header fields will be
- described in the following sections.
-
-4. MIME-Version Header Field
-
- Since RFC 822 was published in 1982, there has really been only one
- format standard for Internet messages, and there has been little
- perceived need to declare the format standard in use. This document
- is an independent specification that complements RFC 822. Although
- the extensions in this document have been defined in such a way as to
- be compatible with RFC 822, there are still circumstances in which it
- might be desirable for a mail-processing agent to know whether a
- message was composed with the new standard in mind.
-
-
-
-Freed & Borenstein Standards Track [Page 8]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- Therefore, this document defines a new header field, "MIME-Version",
- which is to be used to declare the version of the Internet message
- body format standard in use.
-
- Messages composed in accordance with this document MUST include such
- a header field, with the following verbatim text:
-
- MIME-Version: 1.0
-
- The presence of this header field is an assertion that the message
- has been composed in compliance with this document.
-
- Since it is possible that a future document might extend the message
- format standard again, a formal BNF is given for the content of the
- MIME-Version field:
-
- version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
-
- Thus, future format specifiers, which might replace or extend "1.0",
- are constrained to be two integer fields, separated by a period. If
- a message is received with a MIME-version value other than "1.0", it
- cannot be assumed to conform with this document.
-
- Note that the MIME-Version header field is required at the top level
- of a message. It is not required for each body part of a multipart
- entity. It is required for the embedded headers of a body of type
- "message/rfc822" or "message/partial" if and only if the embedded
- message is itself claimed to be MIME-conformant.
-
- It is not possible to fully specify how a mail reader that conforms
- with MIME as defined in this document should treat a message that
- might arrive in the future with some value of MIME-Version other than
- "1.0".
-
- It is also worth noting that version control for specific media types
- is not accomplished using the MIME-Version mechanism. In particular,
- some formats (such as application/postscript) have version numbering
- conventions that are internal to the media format. Where such
- conventions exist, MIME does nothing to supersede them. Where no
- such conventions exist, a MIME media type might use a "version"
- parameter in the content-type field if necessary.
-
-
-
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 9]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- NOTE TO IMPLEMENTORS: When checking MIME-Version values any RFC 822
- comment strings that are present must be ignored. In particular, the
- following four MIME-Version fields are equivalent:
-
- MIME-Version: 1.0
-
- MIME-Version: 1.0 (produced by MetaSend Vx.x)
-
- MIME-Version: (produced by MetaSend Vx.x) 1.0
-
- MIME-Version: 1.(produced by MetaSend Vx.x)0
-
- In the absence of a MIME-Version field, a receiving mail user agent
- (whether conforming to MIME requirements or not) may optionally
- choose to interpret the body of the message according to local
- conventions. Many such conventions are currently in use and it
- should be noted that in practice non-MIME messages can contain just
- about anything.
-
- It is impossible to be certain that a non-MIME mail message is
- actually plain text in the US-ASCII character set since it might well
- be a message that, using some set of nonstandard local conventions
- that predate MIME, includes text in another character set or non-
- textual data presented in a manner that cannot be automatically
- recognized (e.g., a uuencoded compressed UNIX tar file).
-
-5. Content-Type Header Field
-
- The purpose of the Content-Type field is to describe the data
- contained in the body fully enough that the receiving user agent can
- pick an appropriate agent or mechanism to present the data to the
- user, or otherwise deal with the data in an appropriate manner. The
- value in this field is called a media type.
-
- HISTORICAL NOTE: The Content-Type header field was first defined in
- RFC 1049. RFC 1049 used a simpler and less powerful syntax, but one
- that is largely compatible with the mechanism given here.
-
- The Content-Type header field specifies the nature of the data in the
- body of an entity by giving media type and subtype identifiers, and
- by providing auxiliary information that may be required for certain
- media types. After the media type and subtype names, the remainder
- of the header field is simply a set of parameters, specified in an
- attribute=value notation. The ordering of parameters is not
- significant.
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 10]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- In general, the top-level media type is used to declare the general
- type of data, while the subtype specifies a specific format for that
- type of data. Thus, a media type of "image/xyz" is enough to tell a
- user agent that the data is an image, even if the user agent has no
- knowledge of the specific image format "xyz". Such information can
- be used, for example, to decide whether or not to show a user the raw
- data from an unrecognized subtype -- such an action might be
- reasonable for unrecognized subtypes of text, but not for
- unrecognized subtypes of image or audio. For this reason, registered
- subtypes of text, image, audio, and video should not contain embedded
- information that is really of a different type. Such compound
- formats should be represented using the "multipart" or "application"
- types.
-
- Parameters are modifiers of the media subtype, and as such do not
- fundamentally affect the nature of the content. The set of
- meaningful parameters depends on the media type and subtype. Most
- parameters are associated with a single specific subtype. However, a
- given top-level media type may define parameters which are applicable
- to any subtype of that type. Parameters may be required by their
- defining content type or subtype or they may be optional. MIME
- implementations must ignore any parameters whose names they do not
- recognize.
-
- For example, the "charset" parameter is applicable to any subtype of
- "text", while the "boundary" parameter is required for any subtype of
- the "multipart" media type.
-
- There are NO globally-meaningful parameters that apply to all media
- types. Truly global mechanisms are best addressed, in the MIME
- model, by the definition of additional Content-* header fields.
-
- An initial set of seven top-level media types is defined in RFC 2046.
- Five of these are discrete types whose content is essentially opaque
- as far as MIME processing is concerned. The remaining two are
- composite types whose contents require additional handling by MIME
- processors.
-
- This set of top-level media types is intended to be substantially
- complete. It is expected that additions to the larger set of
- supported types can generally be accomplished by the creation of new
- subtypes of these initial types. In the future, more top-level types
- may be defined only by a standards-track extension to this standard.
- If another top-level type is to be used for any reason, it must be
- given a name starting with "X-" to indicate its non-standard status
- and to avoid a potential conflict with a future official name.
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 11]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-5.1. Syntax of the Content-Type Header Field
-
- In the Augmented BNF notation of RFC 822, a Content-Type header field
- value is defined as follows:
-
- content := "Content-Type" ":" type "/" subtype
- *(";" parameter)
- ; Matching of media type and subtype
- ; is ALWAYS case-insensitive.
-
- type := discrete-type / composite-type
-
- discrete-type := "text" / "image" / "audio" / "video" /
- "application" / extension-token
-
- composite-type := "message" / "multipart" / extension-token
-
- extension-token := ietf-token / x-token
-
- ietf-token := <An extension token defined by a
- standards-track RFC and registered
- with IANA.>
-
- x-token := <The two characters "X-" or "x-" followed, with
- no intervening white space, by any token>
-
- subtype := extension-token / iana-token
-
- iana-token := <A publicly-defined extension token. Tokens
- of this form must be registered with IANA
- as specified in RFC 2048.>
-
- parameter := attribute "=" value
-
- attribute := token
- ; Matching of attributes
- ; is ALWAYS case-insensitive.
-
- value := token / quoted-string
-
- token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
- or tspecials>
-
- tspecials := "(" / ")" / "<" / ">" / "@" /
- "," / ";" / ":" / "\" / <">
- "/" / "[" / "]" / "?" / "="
- ; Must be in quoted-string,
- ; to use within parameter values
-
-
-
-Freed & Borenstein Standards Track [Page 12]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- Note that the definition of "tspecials" is the same as the RFC 822
- definition of "specials" with the addition of the three characters
- "/", "?", and "=", and the removal of ".".
-
- Note also that a subtype specification is MANDATORY -- it may not be
- omitted from a Content-Type header field. As such, there are no
- default subtypes.
-
- The type, subtype, and parameter names are not case sensitive. For
- example, TEXT, Text, and TeXt are all equivalent top-level media
- types. Parameter values are normally case sensitive, but sometimes
- are interpreted in a case-insensitive fashion, depending on the
- intended use. (For example, multipart boundaries are case-sensitive,
- but the "access-type" parameter for message/External-body is not
- case-sensitive.)
-
- Note that the value of a quoted string parameter does not include the
- quotes. That is, the quotation marks in a quoted-string are not a
- part of the value of the parameter, but are merely used to delimit
- that parameter value. In addition, comments are allowed in
- accordance with RFC 822 rules for structured header fields. Thus the
- following two forms
-
- Content-type: text/plain; charset=us-ascii (Plain text)
-
- Content-type: text/plain; charset="us-ascii"
-
- are completely equivalent.
-
- Beyond this syntax, the only syntactic constraint on the definition
- of subtype names is the desire that their uses must not conflict.
- That is, it would be undesirable to have two different communities
- using "Content-Type: application/foobar" to mean two different
- things. The process of defining new media subtypes, then, is not
- intended to be a mechanism for imposing restrictions, but simply a
- mechanism for publicizing their definition and usage. There are,
- therefore, two acceptable mechanisms for defining new media subtypes:
-
- (1) Private values (starting with "X-") may be defined
- bilaterally between two cooperating agents without
- outside registration or standardization. Such values
- cannot be registered or standardized.
-
- (2) New standard values should be registered with IANA as
- described in RFC 2048.
-
- The second document in this set, RFC 2046, defines the initial set of
- media types for MIME.
-
-
-
-Freed & Borenstein Standards Track [Page 13]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-5.2. Content-Type Defaults
-
- Default RFC 822 messages without a MIME Content-Type header are taken
- by this protocol to be plain text in the US-ASCII character set,
- which can be explicitly specified as:
-
- Content-type: text/plain; charset=us-ascii
-
- This default is assumed if no Content-Type header field is specified.
- It is also recommend that this default be assumed when a
- syntactically invalid Content-Type header field is encountered. In
- the presence of a MIME-Version header field and the absence of any
- Content-Type header field, a receiving User Agent can also assume
- that plain US-ASCII text was the sender's intent. Plain US-ASCII
- text may still be assumed in the absence of a MIME-Version or the
- presence of an syntactically invalid Content-Type header field, but
- the sender's intent might have been otherwise.
-
-6. Content-Transfer-Encoding Header Field
-
- Many media types which could be usefully transported via email are
- represented, in their "natural" format, as 8bit character or binary
- data. Such data cannot be transmitted over some transfer protocols.
- For example, RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII
- data with lines no longer than 1000 characters including any trailing
- CRLF line separator.
-
- It is necessary, therefore, to define a standard mechanism for
- encoding such data into a 7bit short line format. Proper labelling
- of unencoded material in less restrictive formats for direct use over
- less restrictive transports is also desireable. This document
- specifies that such encodings will be indicated by a new "Content-
- Transfer-Encoding" header field. This field has not been defined by
- any previous standard.
-
-6.1. Content-Transfer-Encoding Syntax
-
- The Content-Transfer-Encoding field's value is a single token
- specifying the type of encoding, as enumerated below. Formally:
-
- encoding := "Content-Transfer-Encoding" ":" mechanism
-
- mechanism := "7bit" / "8bit" / "binary" /
- "quoted-printable" / "base64" /
- ietf-token / x-token
-
- These values are not case sensitive -- Base64 and BASE64 and bAsE64
- are all equivalent. An encoding type of 7BIT requires that the body
-
-
-
-Freed & Borenstein Standards Track [Page 14]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- is already in a 7bit mail-ready representation. This is the default
- value -- that is, "Content-Transfer-Encoding: 7BIT" is assumed if the
- Content-Transfer-Encoding header field is not present.
-
-6.2. Content-Transfer-Encodings Semantics
-
- This single Content-Transfer-Encoding token actually provides two
- pieces of information. It specifies what sort of encoding
- transformation the body was subjected to and hence what decoding
- operation must be used to restore it to its original form, and it
- specifies what the domain of the result is.
-
- The transformation part of any Content-Transfer-Encodings specifies,
- either explicitly or implicitly, a single, well-defined decoding
- algorithm, which for any sequence of encoded octets either transforms
- it to the original sequence of octets which was encoded, or shows
- that it is illegal as an encoded sequence. Content-Transfer-
- Encodings transformations never depend on any additional external
- profile information for proper operation. Note that while decoders
- must produce a single, well-defined output for a valid encoding no
- such restrictions exist for encoders: Encoding a given sequence of
- octets to different, equivalent encoded sequences is perfectly legal.
-
- Three transformations are currently defined: identity, the "quoted-
- printable" encoding, and the "base64" encoding. The domains are
- "binary", "8bit" and "7bit".
-
- The Content-Transfer-Encoding values "7bit", "8bit", and "binary" all
- mean that the identity (i.e. NO) encoding transformation has been
- performed. As such, they serve simply as indicators of the domain of
- the body data, and provide useful information about the sort of
- encoding that might be needed for transmission in a given transport
- system. The terms "7bit data", "8bit data", and "binary data" are
- all defined in Section 2.
-
- The quoted-printable and base64 encodings transform their input from
- an arbitrary domain into material in the "7bit" range, thus making it
- safe to carry over restricted transports. The specific definition of
- the transformations are given below.
-
- The proper Content-Transfer-Encoding label must always be used.
- Labelling unencoded data containing 8bit characters as "7bit" is not
- allowed, nor is labelling unencoded non-line-oriented data as
- anything other than "binary" allowed.
-
- Unlike media subtypes, a proliferation of Content-Transfer-Encoding
- values is both undesirable and unnecessary. However, establishing
- only a single transformation into the "7bit" domain does not seem
-
-
-
-Freed & Borenstein Standards Track [Page 15]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- possible. There is a tradeoff between the desire for a compact and
- efficient encoding of largely- binary data and the desire for a
- somewhat readable encoding of data that is mostly, but not entirely,
- 7bit. For this reason, at least two encoding mechanisms are
- necessary: a more or less readable encoding (quoted-printable) and a
- "dense" or "uniform" encoding (base64).
-
- Mail transport for unencoded 8bit data is defined in RFC 1652. As of
- the initial publication of this document, there are no standardized
- Internet mail transports for which it is legitimate to include
- unencoded binary data in mail bodies. Thus there are no
- circumstances in which the "binary" Content-Transfer-Encoding is
- actually valid in Internet mail. However, in the event that binary
- mail transport becomes a reality in Internet mail, or when MIME is
- used in conjunction with any other binary-capable mail transport
- mechanism, binary bodies must be labelled as such using this
- mechanism.
-
- NOTE: The five values defined for the Content-Transfer-Encoding field
- imply nothing about the media type other than the algorithm by which
- it was encoded or the transport system requirements if unencoded.
-
-6.3. New Content-Transfer-Encodings
-
- Implementors may, if necessary, define private Content-Transfer-
- Encoding values, but must use an x-token, which is a name prefixed by
- "X-", to indicate its non-standard status, e.g., "Content-Transfer-
- Encoding: x-my-new-encoding". Additional standardized Content-
- Transfer-Encoding values must be specified by a standards-track RFC.
- The requirements such specifications must meet are given in RFC 2048.
- As such, all content-transfer-encoding namespace except that
- beginning with "X-" is explicitly reserved to the IETF for future
- use.
-
- Unlike media types and subtypes, the creation of new Content-
- Transfer-Encoding values is STRONGLY discouraged, as it seems likely
- to hinder interoperability with little potential benefit
-
-6.4. Interpretation and Use
-
- If a Content-Transfer-Encoding header field appears as part of a
- message header, it applies to the entire body of that message. If a
- Content-Transfer-Encoding header field appears as part of an entity's
- headers, it applies only to the body of that entity. If an entity is
- of type "multipart" the Content-Transfer-Encoding is not permitted to
- have any value other than "7bit", "8bit" or "binary". Even more
- severe restrictions apply to some subtypes of the "message" type.
-
-
-
-
-Freed & Borenstein Standards Track [Page 16]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- It should be noted that most media types are defined in terms of
- octets rather than bits, so that the mechanisms described here are
- mechanisms for encoding arbitrary octet streams, not bit streams. If
- a bit stream is to be encoded via one of these mechanisms, it must
- first be converted to an 8bit byte stream using the network standard
- bit order ("big-endian"), in which the earlier bits in a stream
- become the higher-order bits in a 8bit byte. A bit stream not ending
- at an 8bit boundary must be padded with zeroes. RFC 2046 provides a
- mechanism for noting the addition of such padding in the case of the
- application/octet-stream media type, which has a "padding" parameter.
-
- The encoding mechanisms defined here explicitly encode all data in
- US-ASCII. Thus, for example, suppose an entity has header fields
- such as:
-
- Content-Type: text/plain; charset=ISO-8859-1
- Content-transfer-encoding: base64
-
- This must be interpreted to mean that the body is a base64 US-ASCII
- encoding of data that was originally in ISO-8859-1, and will be in
- that character set again after decoding.
-
- Certain Content-Transfer-Encoding values may only be used on certain
- media types. In particular, it is EXPRESSLY FORBIDDEN to use any
- encodings other than "7bit", "8bit", or "binary" with any composite
- media type, i.e. one that recursively includes other Content-Type
- fields. Currently the only composite media types are "multipart" and
- "message". All encodings that are desired for bodies of type
- multipart or message must be done at the innermost level, by encoding
- the actual body that needs to be encoded.
-
- It should also be noted that, by definition, if a composite entity
- has a transfer-encoding value such as "7bit", but one of the enclosed
- entities has a less restrictive value such as "8bit", then either the
- outer "7bit" labelling is in error, because 8bit data are included,
- or the inner "8bit" labelling placed an unnecessarily high demand on
- the transport system because the actual included data were actually
- 7bit-safe.
-
- NOTE ON ENCODING RESTRICTIONS: Though the prohibition against using
- content-transfer-encodings on composite body data may seem overly
- restrictive, it is necessary to prevent nested encodings, in which
- data are passed through an encoding algorithm multiple times, and
- must be decoded multiple times in order to be properly viewed.
- Nested encodings add considerable complexity to user agents: Aside
- from the obvious efficiency problems with such multiple encodings,
- they can obscure the basic structure of a message. In particular,
- they can imply that several decoding operations are necessary simply
-
-
-
-Freed & Borenstein Standards Track [Page 17]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- to find out what types of bodies a message contains. Banning nested
- encodings may complicate the job of certain mail gateways, but this
- seems less of a problem than the effect of nested encodings on user
- agents.
-
- Any entity with an unrecognized Content-Transfer-Encoding must be
- treated as if it has a Content-Type of "application/octet-stream",
- regardless of what the Content-Type header field actually says.
-
- NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-TRANSFER-
- ENCODING: It may seem that the Content-Transfer-Encoding could be
- inferred from the characteristics of the media that is to be encoded,
- or, at the very least, that certain Content-Transfer-Encodings could
- be mandated for use with specific media types. There are several
- reasons why this is not the case. First, given the varying types of
- transports used for mail, some encodings may be appropriate for some
- combinations of media types and transports but not for others. (For
- example, in an 8bit transport, no encoding would be required for text
- in certain character sets, while such encodings are clearly required
- for 7bit SMTP.)
-
- Second, certain media types may require different types of transfer
- encoding under different circumstances. For example, many PostScript
- bodies might consist entirely of short lines of 7bit data and hence
- require no encoding at all. Other PostScript bodies (especially
- those using Level 2 PostScript's binary encoding mechanism) may only
- be reasonably represented using a binary transport encoding.
- Finally, since the Content-Type field is intended to be an open-ended
- specification mechanism, strict specification of an association
- between media types and encodings effectively couples the
- specification of an application protocol with a specific lower-level
- transport. This is not desirable since the developers of a media
- type should not have to be aware of all the transports in use and
- what their limitations are.
-
-6.5. Translating Encodings
-
- The quoted-printable and base64 encodings are designed so that
- conversion between them is possible. The only issue that arises in
- such a conversion is the handling of hard line breaks in quoted-
- printable encoding output. When converting from quoted-printable to
- base64 a hard line break in the quoted-printable form represents a
- CRLF sequence in the canonical form of the data. It must therefore be
- converted to a corresponding encoded CRLF in the base64 form of the
- data. Similarly, a CRLF sequence in the canonical form of the data
- obtained after base64 decoding must be converted to a quoted-
- printable hard line break, but ONLY when converting text data.
-
-
-
-
-Freed & Borenstein Standards Track [Page 18]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-6.6. Canonical Encoding Model
-
- There was some confusion, in the previous versions of this RFC,
- regarding the model for when email data was to be converted to
- canonical form and encoded, and in particular how this process would
- affect the treatment of CRLFs, given that the representation of
- newlines varies greatly from system to system, and the relationship
- between content-transfer-encodings and character sets. A canonical
- model for encoding is presented in RFC 2049 for this reason.
-
-6.7. Quoted-Printable Content-Transfer-Encoding
-
- The Quoted-Printable encoding is intended to represent data that
- largely consists of octets that correspond to printable characters in
- the US-ASCII character set. It encodes the data in such a way that
- the resulting octets are unlikely to be modified by mail transport.
- If the data being encoded are mostly US-ASCII text, the encoded form
- of the data remains largely recognizable by humans. A body which is
- entirely US-ASCII may also be encoded in Quoted-Printable to ensure
- the integrity of the data should the message pass through a
- character-translating, and/or line-wrapping gateway.
-
- In this encoding, octets are to be represented as determined by the
- following rules:
-
- (1) (General 8bit representation) Any octet, except a CR or
- LF that is part of a CRLF line break of the canonical
- (standard) form of the data being encoded, may be
- represented by an "=" followed by a two digit
- hexadecimal representation of the octet's value. The
- digits of the hexadecimal alphabet, for this purpose,
- are "0123456789ABCDEF". Uppercase letters must be
- used; lowercase letters are not allowed. Thus, for
- example, the decimal value 12 (US-ASCII form feed) can
- be represented by "=0C", and the decimal value 61 (US-
- ASCII EQUAL SIGN) can be represented by "=3D". This
- rule must be followed except when the following rules
- allow an alternative encoding.
-
- (2) (Literal representation) Octets with decimal values of
- 33 through 60 inclusive, and 62 through 126, inclusive,
- MAY be represented as the US-ASCII characters which
- correspond to those octets (EXCLAMATION POINT through
- LESS THAN, and GREATER THAN through TILDE,
- respectively).
-
- (3) (White Space) Octets with values of 9 and 32 MAY be
- represented as US-ASCII TAB (HT) and SPACE characters,
-
-
-
-Freed & Borenstein Standards Track [Page 19]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- respectively, but MUST NOT be so represented at the end
- of an encoded line. Any TAB (HT) or SPACE characters
- on an encoded line MUST thus be followed on that line
- by a printable character. In particular, an "=" at the
- end of an encoded line, indicating a soft line break
- (see rule #5) may follow one or more TAB (HT) or SPACE
- characters. It follows that an octet with decimal
- value 9 or 32 appearing at the end of an encoded line
- must be represented according to Rule #1. This rule is
- necessary because some MTAs (Message Transport Agents,
- programs which transport messages from one user to
- another, or perform a portion of such transfers) are
- known to pad lines of text with SPACEs, and others are
- known to remove "white space" characters from the end
- of a line. Therefore, when decoding a Quoted-Printable
- body, any trailing white space on a line must be
- deleted, as it will necessarily have been added by
- intermediate transport agents.
-
- (4) (Line Breaks) A line break in a text body, represented
- as a CRLF sequence in the text canonical form, must be
- represented by a (RFC 822) line break, which is also a
- CRLF sequence, in the Quoted-Printable encoding. Since
- the canonical representation of media types other than
- text do not generally include the representation of
- line breaks as CRLF sequences, no hard line breaks
- (i.e. line breaks that are intended to be meaningful
- and to be displayed to the user) can occur in the
- quoted-printable encoding of such types. Sequences
- like "=0D", "=0A", "=0A=0D" and "=0D=0A" will routinely
- appear in non-text data represented in quoted-
- printable, of course.
-
- Note that many implementations may elect to encode the
- local representation of various content types directly
- rather than converting to canonical form first,
- encoding, and then converting back to local
- representation. In particular, this may apply to plain
- text material on systems that use newline conventions
- other than a CRLF terminator sequence. Such an
- implementation optimization is permissible, but only
- when the combined canonicalization-encoding step is
- equivalent to performing the three steps separately.
-
- (5) (Soft Line Breaks) The Quoted-Printable encoding
- REQUIRES that encoded lines be no more than 76
- characters long. If longer lines are to be encoded
- with the Quoted-Printable encoding, "soft" line breaks
-
-
-
-Freed & Borenstein Standards Track [Page 20]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- must be used. An equal sign as the last character on a
- encoded line indicates such a non-significant ("soft")
- line break in the encoded text.
-
- Thus if the "raw" form of the line is a single unencoded line that
- says:
-
- Now's the time for all folk to come to the aid of their country.
-
- This can be represented, in the Quoted-Printable encoding, as:
-
- Now's the time =
- for all folk to come=
- to the aid of their country.
-
- This provides a mechanism with which long lines are encoded in such a
- way as to be restored by the user agent. The 76 character limit does
- not count the trailing CRLF, but counts all other characters,
- including any equal signs.
-
- Since the hyphen character ("-") may be represented as itself in the
- Quoted-Printable encoding, care must be taken, when encapsulating a
- quoted-printable encoded body inside one or more multipart entities,
- to ensure that the boundary delimiter does not appear anywhere in the
- encoded body. (A good strategy is to choose a boundary that includes
- a character sequence such as "=_" which can never appear in a
- quoted-printable body. See the definition of multipart messages in
- RFC 2046.)
-
- NOTE: The quoted-printable encoding represents something of a
- compromise between readability and reliability in transport. Bodies
- encoded with the quoted-printable encoding will work reliably over
- most mail gateways, but may not work perfectly over a few gateways,
- notably those involving translation into EBCDIC. A higher level of
- confidence is offered by the base64 Content-Transfer-Encoding. A way
- to get reasonably reliable transport through EBCDIC gateways is to
- also quote the US-ASCII characters
-
- !"#$@[\]^`{|}~
-
- according to rule #1.
-
- Because quoted-printable data is generally assumed to be line-
- oriented, it is to be expected that the representation of the breaks
- between the lines of quoted-printable data may be altered in
- transport, in the same manner that plain text mail has always been
- altered in Internet mail when passing between systems with differing
- newline conventions. If such alterations are likely to constitute a
-
-
-
-Freed & Borenstein Standards Track [Page 21]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- corruption of the data, it is probably more sensible to use the
- base64 encoding rather than the quoted-printable encoding.
-
- NOTE: Several kinds of substrings cannot be generated according to
- the encoding rules for the quoted-printable content-transfer-
- encoding, and hence are formally illegal if they appear in the output
- of a quoted-printable encoder. This note enumerates these cases and
- suggests ways to handle such illegal substrings if any are
- encountered in quoted-printable data that is to be decoded.
-
- (1) An "=" followed by two hexadecimal digits, one or both
- of which are lowercase letters in "abcdef", is formally
- illegal. A robust implementation might choose to
- recognize them as the corresponding uppercase letters.
-
- (2) An "=" followed by a character that is neither a
- hexadecimal digit (including "abcdef") nor the CR
- character of a CRLF pair is illegal. This case can be
- the result of US-ASCII text having been included in a
- quoted-printable part of a message without itself
- having been subjected to quoted-printable encoding. A
- reasonable approach by a robust implementation might be
- to include the "=" character and the following
- character in the decoded data without any
- transformation and, if possible, indicate to the user
- that proper decoding was not possible at this point in
- the data.
-
- (3) An "=" cannot be the ultimate or penultimate character
- in an encoded object. This could be handled as in case
- (2) above.
-
- (4) Control characters other than TAB, or CR and LF as
- parts of CRLF pairs, must not appear. The same is true
- for octets with decimal values greater than 126. If
- found in incoming quoted-printable data by a decoder, a
- robust implementation might exclude them from the
- decoded data and warn the user that illegal characters
- were discovered.
-
- (5) Encoded lines must not be longer than 76 characters,
- not counting the trailing CRLF. If longer lines are
- found in incoming, encoded data, a robust
- implementation might nevertheless decode the lines, and
- might report the erroneous encoding to the user.
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 22]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- WARNING TO IMPLEMENTORS: If binary data is encoded in quoted-
- printable, care must be taken to encode CR and LF characters as "=0D"
- and "=0A", respectively. In particular, a CRLF sequence in binary
- data should be encoded as "=0D=0A". Otherwise, if CRLF were
- represented as a hard line break, it might be incorrectly decoded on
- platforms with different line break conventions.
-
- For formalists, the syntax of quoted-printable data is described by
- the following grammar:
-
- quoted-printable := qp-line *(CRLF qp-line)
-
- qp-line := *(qp-segment transport-padding CRLF)
- qp-part transport-padding
-
- qp-part := qp-section
- ; Maximum length of 76 characters
-
- qp-segment := qp-section *(SPACE / TAB) "="
- ; Maximum length of 76 characters
-
- qp-section := [*(ptext / SPACE / TAB) ptext]
-
- ptext := hex-octet / safe-char
-
- safe-char := <any octet with decimal value of 33 through
- 60 inclusive, and 62 through 126>
- ; Characters not listed as "mail-safe" in
- ; RFC 2049 are also not recommended.
-
- hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
- ; Octet must be used for characters > 127, =,
- ; SPACEs or TABs at the ends of lines, and is
- ; recommended for any character not listed in
- ; RFC 2049 as "mail-safe".
-
- transport-padding := *LWSP-char
- ; Composers MUST NOT generate
- ; non-zero length transport
- ; padding, but receivers MUST
- ; be able to handle padding
- ; added by message transports.
-
- IMPORTANT: The addition of LWSP between the elements shown in this
- BNF is NOT allowed since this BNF does not specify a structured
- header field.
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 23]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-6.8. Base64 Content-Transfer-Encoding
-
- The Base64 Content-Transfer-Encoding is designed to represent
- arbitrary sequences of octets in a form that need not be humanly
- readable. The encoding and decoding algorithms are simple, but the
- encoded data are consistently only about 33 percent larger than the
- unencoded data. This encoding is virtually identical to the one used
- in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421.
-
- A 65-character subset of US-ASCII is used, enabling 6 bits to be
- represented per printable character. (The extra 65th character, "=",
- is used to signify a special processing function.)
-
- NOTE: This subset has the important property that it is represented
- identically in all versions of ISO 646, including US-ASCII, and all
- characters in the subset are also represented identically in all
- versions of EBCDIC. Other popular encodings, such as the encoding
- used by the uuencode utility, Macintosh binhex 4.0 [RFC-1741], and
- the base85 encoding specified as part of Level 2 PostScript, do not
- share these properties, and thus do not fulfill the portability
- requirements a binary transport encoding for mail must meet.
-
- The encoding process represents 24-bit groups of input bits as output
- strings of 4 encoded characters. Proceeding from left to right, a
- 24-bit input group is formed by concatenating 3 8bit input groups.
- These 24 bits are then treated as 4 concatenated 6-bit groups, each
- of which is translated into a single digit in the base64 alphabet.
- When encoding a bit stream via the base64 encoding, the bit stream
- must be presumed to be ordered with the most-significant-bit first.
- That is, the first bit in the stream will be the high-order bit in
- the first 8bit byte, and the eighth bit will be the low-order bit in
- the first 8bit byte, and so on.
-
- Each 6-bit group is used as an index into an array of 64 printable
- characters. The character referenced by the index is placed in the
- output string. These characters, identified in Table 1, below, are
- selected so as to be universally representable, and the set excludes
- characters with particular significance to SMTP (e.g., ".", CR, LF)
- and to the multipart boundary delimiters defined in RFC 2046 (e.g.,
- "-").
-
-
-
-
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 24]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- Table 1: The Base64 Alphabet
-
- Value Encoding Value Encoding Value Encoding Value Encoding
- 0 A 17 R 34 i 51 z
- 1 B 18 S 35 j 52 0
- 2 C 19 T 36 k 53 1
- 3 D 20 U 37 l 54 2
- 4 E 21 V 38 m 55 3
- 5 F 22 W 39 n 56 4
- 6 G 23 X 40 o 57 5
- 7 H 24 Y 41 p 58 6
- 8 I 25 Z 42 q 59 7
- 9 J 26 a 43 r 60 8
- 10 K 27 b 44 s 61 9
- 11 L 28 c 45 t 62 +
- 12 M 29 d 46 u 63 /
- 13 N 30 e 47 v
- 14 O 31 f 48 w (pad) =
- 15 P 32 g 49 x
- 16 Q 33 h 50 y
-
- The encoded output stream must be represented in lines of no more
- than 76 characters each. All line breaks or other characters not
- found in Table 1 must be ignored by decoding software. In base64
- data, characters other than those in Table 1, line breaks, and other
- white space probably indicate a transmission error, about which a
- warning message or even a message rejection might be appropriate
- under some circumstances.
-
- Special processing is performed if fewer than 24 bits are available
- at the end of the data being encoded. A full encoding quantum is
- always completed at the end of a body. When fewer than 24 input bits
- are available in an input group, zero bits are added (on the right)
- to form an integral number of 6-bit groups. Padding at the end of
- the data is performed using the "=" character. Since all base64
- input is an integral number of octets, only the following cases can
- arise: (1) the final quantum of encoding input is an integral
- multiple of 24 bits; here, the final unit of encoded output will be
- an integral multiple of 4 characters with no "=" padding, (2) the
- final quantum of encoding input is exactly 8 bits; here, the final
- unit of encoded output will be two characters followed by two "="
- padding characters, or (3) the final quantum of encoding input is
- exactly 16 bits; here, the final unit of encoded output will be three
- characters followed by one "=" padding character.
-
- Because it is used only for padding at the end of the data, the
- occurrence of any "=" characters may be taken as evidence that the
- end of the data has been reached (without truncation in transit). No
-
-
-
-Freed & Borenstein Standards Track [Page 25]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
- such assurance is possible, however, when the number of octets
- transmitted was a multiple of three and no "=" characters are
- present.
-
- Any characters outside of the base64 alphabet are to be ignored in
- base64-encoded data.
-
- Care must be taken to use the proper octets for line breaks if base64
- encoding is applied directly to text material that has not been
- converted to canonical form. In particular, text line breaks must be
- converted into CRLF sequences prior to base64 encoding. The
- important thing to note is that this may be done directly by the
- encoder rather than in a prior canonicalization step in some
- implementations.
-
- NOTE: There is no need to worry about quoting potential boundary
- delimiters within base64-encoded bodies within multipart entities
- because no hyphen characters are used in the base64 encoding.
-
-7. Content-ID Header Field
-
- In constructing a high-level user agent, it may be desirable to allow
- one body to make reference to another. Accordingly, bodies may be
- labelled using the "Content-ID" header field, which is syntactically
- identical to the "Message-ID" header field:
-
- id := "Content-ID" ":" msg-id
-
- Like the Message-ID values, Content-ID values must be generated to be
- world-unique.
-
- The Content-ID value may be used for uniquely identifying MIME
- entities in several contexts, particularly for caching data
- referenced by the message/external-body mechanism. Although the
- Content-ID header is generally optional, its use is MANDATORY in
- implementations which generate data of the optional MIME media type
- "message/external-body". That is, each message/external-body entity
- must have a Content-ID field to permit caching of such data.
-
- It is also worth noting that the Content-ID value has special
- semantics in the case of the multipart/alternative media type. This
- is explained in the section of RFC 2046 dealing with
- multipart/alternative.
-
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 26]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-8. Content-Description Header Field
-
- The ability to associate some descriptive information with a given
- body is often desirable. For example, it may be useful to mark an
- "image" body as "a picture of the Space Shuttle Endeavor." Such text
- may be placed in the Content-Description header field. This header
- field is always optional.
-
- description := "Content-Description" ":" *text
-
- The description is presumed to be given in the US-ASCII character
- set, although the mechanism specified in RFC 2047 may be used for
- non-US-ASCII Content-Description values.
-
-9. Additional MIME Header Fields
-
- Future documents may elect to define additional MIME header fields
- for various purposes. Any new header field that further describes
- the content of a message should begin with the string "Content-" to
- allow such fields which appear in a message header to be
- distinguished from ordinary RFC 822 message header fields.
-
- MIME-extension-field := <Any RFC 822 header field which
- begins with the string
- "Content-">
-
-10. Summary
-
- Using the MIME-Version, Content-Type, and Content-Transfer-Encoding
- header fields, it is possible to include, in a standardized way,
- arbitrary types of data with RFC 822 conformant mail messages. No
- restrictions imposed by either RFC 821 or RFC 822 are violated, and
- care has been taken to avoid problems caused by additional
- restrictions imposed by the characteristics of some Internet mail
- transport mechanisms (see RFC 2049).
-
- The next document in this set, RFC 2046, specifies the initial set of
- media types that can be labelled and transported using these headers.
-
-11. Security Considerations
-
- Security issues are discussed in the second document in this set, RFC
- 2046.
-
-
-
-
-
-
-
-
-Freed & Borenstein Standards Track [Page 27]
-
-RFC 2045 Internet Message Bodies November 1996
-
-
-12. Authors' Addresses
-
- For more information, the authors of this document are best contacted
- via Internet mail:
-
- Ned Freed
- Innosoft International, Inc.
- 1050 East Garvey Avenue South
- West Covina, CA 91790
- USA
-
- Phone: +1 818 919 3600
- Fax: +1 818 919 3614
- EMail: ned@innosoft.com
-
-
- Nathaniel S. Borenstein
- First Virtual Holdings
- 25 Washington Avenue
- Morristown, NJ 07960
- USA
-
- Phone: +1 201 540 8967
- Fax: +1 201 993 3032
- EMail: nsb@nsb.fv.com
-
-
- 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: Greg.Vaudreuil@Octel.Com
-
-
-
-
-
-
-
-
-
-
-
-
-
-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/src/rfc2046.txt b/doc/src/rfc2046.txt
@@ -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 <nsb@bellcore.com>
- To: Ned Freed <ned@innosoft.com>
- 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 <nsb@bellcore.com>
- To: Ned Freed <ned@innosoft.com>
- 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="oc=jpbe0M2Yt4s@thumper.bellcore.com"
-
- Content-Type: Message/Partial;
- id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
- number=2
-
- But the third piece MUST specify the total number of fragments:
-
- Content-Type: Message/Partial; number=3; total=3;
- id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
-
- 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: Bill@host.com
- To: joe@otherhost.com
- Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
- Subject: Audio mail (part 1 of 2)
- Message-ID: <id1@host.com>
- MIME-Version: 1.0
- Content-type: message/partial; id="ABC@host.com";
-
-
-
-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: <anotherid@foo.com>
- 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: Bill@host.com
- To: joe@otherhost.com
- Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
- Subject: Audio mail (part 2 of 2)
- MIME-Version: 1.0
- Message-ID: <id2@host.com>
- Content-type: message/partial;
- id="ABC@host.com"; number=2; total=2
-
- ... second half of encoded audio data goes here ...
-
- Then, when the fragmented message is reassembled, the resulting
- message to be displayed to the user should look something like this:
-
- X-Weird-Header-1: Foo
- From: Bill@host.com
- To: joe@otherhost.com
- Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
- Subject: Audio mail
- Message-ID: <anotherid@foo.com>
- 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: <id42@guppylake.bellcore.com>
- 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: <id1@host.com>
- Content-Type: multipart/alternative; boundary=42
- Content-ID: <id001@guppylake.bellcore.com>
-
- --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: <id42@guppylake.bellcore.com>
-
- --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: <id42@guppylake.bellcore.com>
-
- --42
- Content-Type: message/external-body;
- access-type=mail-server
- server="listserv@bogus.bitnet";
- expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
-
- Content-type: application/postscript
- Content-ID: <id42@guppylake.bellcore.com>
-
- 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: ned@innosoft.com
-
-
- Nathaniel S. Borenstein
- First Virtual Holdings
- 25 Washington Avenue
- Morristown, NJ 07960
- USA
-
- Phone: +1 201 540 8967
- Fax: +1 201 993 3032
- EMail: nsb@nsb.fv.com
-
-
- 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: Greg.Vaudreuil@Octel.Com
-
-
-
-
-
-
-
-
-
-
-
-
-
-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/src/rfc2047.txt b/doc/src/rfc2047.txt
@@ -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?= <moore@cs.utk.edu>
- To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <keld@dkuug.dk>
- CC: =?ISO-8859-1?Q?Andr=E9?= Pirard <PIRARD@vm1.ulg.ac.be>
- 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?= <ojarnef@admin.kth.se>
- To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se
- Subject: Time for ISO 10646?
-
- To: Dave Crocker <dcrocker@mordor.stanford.edu>
- Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se
- From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@nada.kth.se>
- Subject: Re: RFC-HDR care and feeding
-
-
-
-
-
-Moore Standards Track [Page 11]
-
-RFC 2047 Message Header Extensions November 1996
-
-
- From: Nathaniel Borenstein <nsb@thumper.bellcore.com>
- (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=)
- To: Greg Vaudreuil <gvaudre@NRI.Reston.VA.US>, Ned Freed
- <ned@innosoft.com>, Keith Moore <moore@cs.utk.edu>
- 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: moore@cs.utk.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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/src/rfc2048.txt b/doc/src/rfc2048.txt
@@ -1,1180 +0,0 @@
-
-
-
-
-
-
-Network Working Group N. Freed
-Request for Comments: 2048 Innosoft
-BCP: 13 J. Klensin
-Obsoletes: 1521, 1522, 1590 MCI
-Category: Best Current Practice J. Postel
- ISI
- November 1996
-
-
- Multipurpose Internet Mail Extensions
- (MIME) Part Four:
- Registration Procedures
-
-Status of this Memo
-
- This document specifies an Internet Best Current Practices for the
- Internet Community, and requests discussion and suggestions for
- improvements. 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.
-
-
-
-
-
-
-
-
-
-Freed, et. al. Best Current Practice [Page 1]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
- This fourth document, RFC 2048, specifies various IANA registration
- procedures for the following MIME facilities:
-
- (1) media types,
-
- (2) external body access types,
-
- (3) content-transfer-encodings.
-
- Registration of character sets for use in MIME is covered elsewhere
- and is no longer addressed by this document.
-
- 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. Media Type Registration .............................. 4
- 2.1 Registration Trees and Subtype Names ................ 4
- 2.1.1 IETF Tree ......................................... 4
- 2.1.2 Vendor Tree ....................................... 4
- 2.1.3 Personal or Vanity Tree ........................... 5
- 2.1.4 Special `x.' Tree ................................. 5
- 2.1.5 Additional Registration Trees ..................... 6
- 2.2 Registration Requirements ........................... 6
- 2.2.1 Functionality Requirement ......................... 6
- 2.2.2 Naming Requirements ............................... 6
- 2.2.3 Parameter Requirements ............................ 7
- 2.2.4 Canonicalization and Format Requirements .......... 7
- 2.2.5 Interchange Recommendations ....................... 8
- 2.2.6 Security Requirements ............................. 8
- 2.2.7 Usage and Implementation Non-requirements ......... 9
- 2.2.8 Publication Requirements .......................... 10
- 2.2.9 Additional Information ............................ 10
- 2.3 Registration Procedure .............................. 11
- 2.3.1 Present the Media Type to the Community for Review 11
- 2.3.2 IESG Approval ..................................... 12
- 2.3.3 IANA Registration ................................. 12
- 2.4 Comments on Media Type Registrations ................ 12
- 2.5 Location of Registered Media Type List .............. 12
- 2.6 IANA Procedures for Registering Media Types ......... 12
- 2.7 Change Control ...................................... 13
- 2.8 Registration Template ............................... 14
- 3. External Body Access Types ........................... 14
- 3.1 Registration Requirements ........................... 15
- 3.1.1 Naming Requirements ............................... 15
-
-
-
-Freed, et. al. Best Current Practice [Page 2]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
- 3.1.2 Mechanism Specification Requirements .............. 15
- 3.1.3 Publication Requirements .......................... 15
- 3.1.4 Security Requirements ............................. 15
- 3.2 Registration Procedure .............................. 15
- 3.2.1 Present the Access Type to the Community .......... 16
- 3.2.2 Access Type Reviewer .............................. 16
- 3.2.3 IANA Registration ................................. 16
- 3.3 Location of Registered Access Type List ............. 16
- 3.4 IANA Procedures for Registering Access Types ........ 16
- 4. Transfer Encodings ................................... 17
- 4.1 Transfer Encoding Requirements ...................... 17
- 4.1.1 Naming Requirements ............................... 17
- 4.1.2 Algorithm Specification Requirements .............. 18
- 4.1.3 Input Domain Requirements ......................... 18
- 4.1.4 Output Range Requirements ......................... 18
- 4.1.5 Data Integrity and Generality Requirements ........ 18
- 4.1.6 New Functionality Requirements .................... 18
- 4.2 Transfer Encoding Definition Procedure .............. 19
- 4.3 IANA Procedures for Transfer Encoding Registration... 19
- 4.4 Location of Registered Transfer Encodings List ...... 19
- 5. Authors' Addresses ................................... 20
- A. Grandfathered Media Types ............................ 21
-
-1. Introduction
-
- Recent Internet protocols have been carefully designed to be easily
- extensible in certain areas. In particular, MIME [RFC 2045] is an
- open-ended framework and can accommodate additional object types,
- character sets, and access methods without any changes to the basic
- protocol. A registration process is needed, however, to ensure that
- the set of such values is developed in an orderly, well-specified,
- and public manner.
-
- This document defines registration procedures which use the Internet
- Assigned Numbers Authority (IANA) as a central registry for such
- values.
-
- Historical Note: The registration process for media types was
- initially defined in the context of the asynchronous Internet mail
- environment. In this mail environment there is a need to limit the
- number of possible media types to increase the likelihood of
- interoperability when the capabilities of the remote mail system are
- not known. As media types are used in new environments, where the
- proliferation of media types is not a hindrance to interoperability,
- the original procedure was excessively restrictive and had to be
- generalized.
-
-
-
-
-
-Freed, et. al. Best Current Practice [Page 3]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
-2. Media Type Registration
-
- Registration of a new media type or types starts with the
- construction of a registration proposal. Registration may occur in
- several different registration trees, which have different
- requirements as discussed below. In general, the new registration
- proposal is circulated and reviewed in a fashion appropriate to the
- tree involved. The media type is then registered if the proposal is
- acceptable. The following sections describe the requirements and
- procedures used for each of the different registration trees.
-
-2.1. Registration Trees and Subtype Names
-
- In order to increase the efficiency and flexibility of the
- registration process, different structures of subtype names may be
- registered to accomodate the different natural requirements for,
- e.g., a subtype that will be recommended for wide support and
- implementation by the Internet Community or a subtype that is used to
- move files associated with proprietary software. The following
- subsections define registration "trees", distinguished by the use of
- faceted names (e.g., names of the form "tree.subtree...type"). Note
- that some media types defined prior to this document do not conform
- to the naming conventions described below. See Appendix A for a
- discussion of them.
-
-2.1.1. IETF Tree
-
- The IETF tree is intended for types of general interest to the
- Internet Community. Registration in the IETF tree requires approval
- by the IESG and publication of the media type registration as some
- form of RFC.
-
- Media types in the IETF tree are normally denoted by names that are
- not explicitly faceted, i.e., do not contain period (".", full stop)
- characters.
-
- The "owner" of a media type registration in the IETF tree is assumed
- to be the IETF itself. Modification or alteration of the
- specification requires the same level of processing (e.g. standards
- track) required for the initial registration.
-
-2.1.2. Vendor Tree
-
- The vendor tree is used for media types associated with commercially
- available products. "Vendor" or "producer" are construed as
- equivalent and very broadly in this context.
-
-
-
-
-
-Freed, et. al. Best Current Practice [Page 4]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
- A registration may be placed in the vendor tree by anyone who has
- need to interchange files associated with the particular product.
- However, the registration formally belongs to the vendor or
- organization producing the software or file format. Changes to the
- specification will be made at their request, as discussed in
- subsequent sections.
-
- Registrations in the vendor tree will be distinguished by the leading
- facet "vnd.". That may be followed, at the discretion of the
- registration, by either a media type name from a well-known producer
- (e.g., "vnd.mudpie") or by an IANA-approved designation of the
- producer's name which is then followed by a media type or product
- designation (e.g., vnd.bigcompany.funnypictures).
-
- While public exposure and review of media types to be registered in
- the vendor tree is not required, using the ietf-types list for review
- is strongly encouraged to improve the quality of those
- specifications. Registrations in the vendor tree may be submitted
- directly to the IANA.
-
-2.1.3. Personal or Vanity Tree
-
- Registrations for media types created experimentally or as part of
- products that are not distributed commercially may be registered in
- the personal or vanity tree. The registrations are distinguished by
- the leading facet "prs.".
-
- The owner of "personal" registrations and associated specifications
- is the person or entity making the registration, or one to whom
- responsibility has been transferred as described below.
-
- While public exposure and review of media types to be registered in
- the personal tree is not required, using the ietf-types list for
- review is strongly encouraged to improve the quality of those
- specifications. Registrations in the personl tree may be submitted
- directly to the IANA.
-
-2.1.4. Special `x.' Tree
-
- For convenience and symmetry with this registration scheme, media
- type names with "x." as the first facet may be used for the same
- purposes for which names starting in "x-" are normally used. These
- types are unregistered, experimental, and should be used only with
- the active agreement of the parties exchanging them.
-
-
-
-
-
-
-
-Freed, et. al. Best Current Practice [Page 5]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
- However, with the simplified registration procedures described above
- for vendor and personal trees, it should rarely, if ever, be
- necessary to use unregistered experimental types, and as such use of
- both "x-" and "x." forms is discouraged.
-
-2.1.5. Additional Registration Trees
-
- From time to time and as required by the community, the IANA may,
- with the advice and consent of the IESG, create new top-level
- registration trees. It is explicitly assumed that these trees may be
- created for external registration and management by well-known
- permanent bodies, such as scientific societies for media types
- specific to the sciences they cover. In general, the quality of
- review of specifications for one of these additional registration
- trees is expected to be equivalent to that which IETF would give to
- registrations in its own tree. Establishment of these new trees will
- be announced through RFC publication approved by the IESG.
-
-2.2. Registration Requirements
-
- Media type registration proposals are all expected to conform to
- various requirements laid out in the following sections. Note that
- requirement specifics sometimes vary depending on the registration
- tree, again as detailed in the following sections.
-
-2.2.1. Functionality Requirement
-
- Media types must function as an actual media format: Registration of
- things that are better thought of as a transfer encoding, as a
- character set, or as a collection of separate entities of another
- type, is not allowed. For example, although applications exist to
- decode the base64 transfer encoding [RFC 2045], base64 cannot be
- registered as a media type.
-
- This requirement applies regardless of the registration tree
- involved.
-
-2.2.2. Naming Requirements
-
- All registered media types must be assigned MIME type and subtype
- names. The combination of these names then serves to uniquely
- identify the media type and the format of the subtype name identifies
- the registration tree.
-
- The choice of top-level type name must take the nature of media type
- involved into account. For example, media normally used for
- representing still images should be a subtype of the image content
- type, whereas media capable of representing audio information belongs
-
-
-
-Freed, et. al. Best Current Practice [Page 6]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
- under the audio content type. See RFC 2046 for additional information
- on the basic set of top-level types and their characteristics.
-
- New subtypes of top-level types must conform to the restrictions of
- the top-level type, if any. For example, all subtypes of the
- multipart content type must use the same encapsulation syntax.
-
- In some cases a new media type may not "fit" under any currently
- defined top-level content type. Such cases are expected to be quite
- rare. However, if such a case arises a new top-level type can be
- defined to accommodate it. Such a definition must be done via
- standards-track RFC; no other mechanism can be used to define
- additional top-level content types.
-
- These requirements apply regardless of the registration tree
- involved.
-
-2.2.3. Parameter Requirements
-
- Media types may elect to use one or more MIME content type
- parameters, or some parameters may be automatically made available to
- the media type by virtue of being a subtype of a content type that
- defines a set of parameters applicable to any of its subtypes. In
- either case, the names, values, and meanings of any parameters must
- be fully specified when a media type is registered in the IETF tree,
- and should be specified as completely as possible when media types
- are registered in the vendor or personal trees.
-
- New parameters must not be defined as a way to introduce new
- functionality in types registered in the IETF tree, although new
- parameters may be added to convey additional information that does
- not otherwise change existing functionality. An example of this
- would be a "revision" parameter to indicate a revision level of an
- external specification such as JPEG. Similar behavior is encouraged
- for media types registered in the vendor or personal trees but is not
- required.
-
-2.2.4. Canonicalization and Format Requirements
-
- All registered media types must employ a single, canonical data
- format, regardless of registration tree.
-
- A precise and openly available specification of the format of each
- media type is required for all types registered in the IETF tree and
- must at a minimum be referenced by, if it isn't actually included in,
- the media type registration proposal itself.
-
-
-
-
-
-Freed, et. al. Best Current Practice [Page 7]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
- The specifications of format and processing particulars may or may
- not be publically available for media types registered in the vendor
- tree, and such registration proposals are explicitly permitted to
- include only a specification of which software and version produce or
- process such media types. References to or inclusion of format
- specifications in registration proposals is encouraged but not
- required.
-
- Format specifications are still required for registration in the
- personal tree, but may be either published as RFCs or otherwise
- deposited with IANA. The deposited specifications will meet the same
- criteria as those required to register a well-known TCP port and, in
- particular, need not be made public.
-
- Some media types involve the use of patented technology. The
- registration of media types involving patented technology is
- specifically permitted. However, the restrictions set forth in RFC
- 1602 on the use of patented technology in standards-track protocols
- must be respected when the specification of a media type is part of a
- standards-track protocol.
-
-2.2.5. Interchange Recommendations
-
- Media types should, whenever possible, interoperate across as many
- systems and applications as possible. However, some media types will
- inevitably have problems interoperating across different platforms.
- Problems with different versions, byte ordering, and specifics of
- gateway handling can and will arise.
-
- Universal interoperability of media types is not required, but known
- interoperability issues should be identified whenever possible.
- Publication of a media type does not require an exhaustive review of
- interoperability, and the interoperability considerations section is
- subject to continuing evaluation.
-
- These recommendations apply regardless of the registration tree
- involved.
-
-2.2.6. Security Requirements
-
- An analysis of security issues is required for for all types
- registered in the IETF Tree. (This is in accordance with the basic
- requirements for all IETF protocols.) A similar analysis for media
- types registered in the vendor or personal trees is encouraged but
- not required. However, regardless of what security analysis has or
- has not been done, all descriptions of security issues must be as
- accurate as possible regardless of registration tree. In particular,
- a statement that there are "no security issues associated with this
-
-
-
-Freed, et. al. Best Current Practice [Page 8]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
- type" must not be confused with "the security issues associates with
- this type have not been assessed".
-
- There is absolutely no requirement that media types registered in any
- tree be secure or completely free from risks. Nevertheless, all
- known security risks must be identified in the registration of a
- media type, again regardless of registration tree.
-
- The security considerations section of all registrations is subject
- to continuing evaluation and modification, and in particular may be
- extended by use of the "comments on media types" mechanism described
- in subsequent sections.
-
- Some of the issues that should be looked at in a security analysis of
- a media type are:
-
- (1) Complex media types may include provisions for
- directives that institute actions on a recipient's
- files or other resources. In many cases provision is
- made for originators to specify arbitrary actions in an
- unrestricted fashion which may then have devastating
- effects. See the registration of the
- application/postscript media type in RFC 2046 for
- an example of such directives and how to handle them.
-
- (2) Complex media types may include provisions for
- directives that institute actions which, while not
- directly harmful to the recipient, may result in
- disclosure of information that either facilitates a
- subsequent attack or else violates a recipient's
- privacy in some way. Again, the registration of the
- application/postscript media type illustrates how such
- directives can be handled.
-
- (3) A media type might be targeted for applications that
- require some sort of security assurance but not provide
- the necessary security mechanisms themselves. For
- example, a media type could be defined for storage of
- confidential medical information which in turn requires
- an external confidentiality service.
-
-2.2.7. Usage and Implementation Non-requirements
-
- In the asynchronous mail environment, where information on the
- capabilities of the remote mail agent is frequently not available to
- the sender, maximum interoperability is attained by restricting the
- number of media types used to those "common" formats expected to be
- widely implemented. This was asserted in the past as a reason to
-
-
-
-Freed, et. al. Best Current Practice [Page 9]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
- limit the number of possible media types and resulted in a
- registration process with a significant hurdle and delay for those
- registering media types.
-
- However, the need for "common" media types does not require limiting
- the registration of new media types. If a limited set of media types
- is recommended for a particular application, that should be asserted
- by a separate applicability statement specific for the application
- and/or environment.
-
- As such, universal support and implementation of a media type is NOT
- a requirement for registration. If, however, a media type is
- explicitly intended for limited use, this should be noted in its
- registration.
-
-2.2.8. Publication Requirements
-
- Proposals for media types registered in the IETF tree must be
- published as RFCs. RFC publication of vendor and personal media type
- proposals is encouraged but not required. In all cases IANA will
- retain copies of all media type proposals and "publish" them as part
- of the media types registration tree itself.
-
- Other than in the IETF tree, the registration of a data type does not
- imply endorsement, approval, or recommendation by IANA or IETF or
- even certification that the specification is adequate. To become
- Internet Standards, protocol, data objects, or whatever must go
- through the IETF standards process. This is too difficult and too
- lengthy a process for the convenient registration of media types.
-
- The IETF tree exists for media types that do require require a
- substantive review and approval process with the vendor and personal
- trees exist for those that do not. It is expected that applicability
- statements for particular applications will be published from time to
- time that recommend implementation of, and support for, media types
- that have proven particularly useful in those contexts.
-
- As discussed above, registration of a top-level type requires
- standards-track processing and, hence, RFC publication.
-
-2.2.9. Additional Information
-
- Various sorts of optional information may be included in the
- specification of a media type if it is available:
-
- (1) Magic number(s) (length, octet values). Magic numbers
- are byte sequences that are always present and thus can
- be used to identify entities as being of a given media
-
-
-
-Freed, et. al. Best Current Practice [Page 10]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
- type.
-
- (2) File extension(s) commonly used on one or more
- platforms to indicate that some file containing a given
- type of media.
-
- (3) Macintosh File Type code(s) (4 octets) used to label
- files containing a given type of media.
-
- Such information is often quite useful to implementors and if
- available should be provided.
-
-2.3. Registration Procedure
-
- The following procedure has been implemented by the IANA for review
- and approval of new media types. This is not a formal standards
- process, but rather an administrative procedure intended to allow
- community comment and sanity checking without excessive time delay.
- For registration in the IETF tree, the normal IETF processes should
- be followed, treating posting of an internet-draft and announcement
- on the ietf-types list (as described in the next subsection) as a
- first step. For registrations in the vendor or personal tree, the
- initial review step described below may be omitted and the type
- registered directly by submitting the template and an explanation
- directly to IANA (at iana@iana.org). However, authors of vendor or
- personal media type specifications are encouraged to seek community
- review and comment whenever that is feasible.
-
-2.3.1. Present the Media Type to the Community for Review
-
- Send a proposed media type registration to the "ietf-types@iana.org"
- mailing list for a two week review period. This mailing list has
- been established for the purpose of reviewing proposed media and
- access types. Proposed media types are not formally registered and
- must not be used; the "x-" prefix specified in RFC 2045 can be used
- until registration is complete.
-
- The intent of the public posting is to solicit comments and feedback
- on the choice of type/subtype name, the unambiguity of the references
- with respect to versions and external profiling information, and a
- review of any interoperability or security considerations. The
- submitter may submit a revised registration, or withdraw the
- registration completely, at any time.
-
-
-
-
-
-
-
-
-Freed, et. al. Best Current Practice [Page 11]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
-2.3.2. IESG Approval
-
- Media types registered in the IETF tree must be submitted to the IESG
- for approval.
-
-2.3.3. IANA Registration
-
- Provided that the media type meets the requirements for media types
- and has obtained approval that is necessary, the author may submit
- the registration request to the IANA, which will register the media
- type and make the media type registration available to the community.
-
-2.4. Comments on Media Type Registrations
-
- Comments on registered media types may be submitted by members of the
- community to IANA. These comments will be passed on to the "owner"
- of the media type if possible. Submitters of comments may request
- that their comment be attached to the media type registration itself,
- and if IANA approves of this the comment will be made accessible in
- conjunction with the type registration itself.
-
-2.5. Location of Registered Media Type List
-
- Media type registrations will be posted in the anonymous FTP
- directory "ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/"
- and all registered media types will be listed in the periodically
- issued "Assigned Numbers" RFC [currently STD 2, RFC 1700]. The media
- type description and other supporting material may also be published
- as an Informational RFC by sending it to "rfc-editor@isi.edu" (please
- follow the instructions to RFC authors [RFC-1543]).
-
-2.6. IANA Procedures for Registering Media Types
-
- The IANA will only register media types in the IETF tree in response
- to a communication from the IESG stating that a given registration
- has been approved. Vendor and personal types will be registered by
- the IANA automatically and without any formal review as long as the
- following minimal conditions are met:
-
- (1) Media types must function as an actual media format.
- In particular, character sets and transfer encodings
- may not be registered as media types.
-
- (2) All media types must have properly formed type and
- subtype names. All type names must be defined by a
- standards-track RFC. All subtype names must be unique,
- must conform to the MIME grammar for such names, and
- must contain the proper tree prefix.
-
-
-
-Freed, et. al. Best Current Practice [Page 12]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
- (3) Types registered in the personal tree must either
- provide a format specification or a pointer to one.
-
- (4) Any security considerations given must not be obviously
- bogus. (It is neither possible nor necessary for the
- IANA to conduct a comprehensive security review of
- media type registrations. Nevertheless, IANA has the
- authority to identify obviously incompetent material
- and exclude it.)
-
-2.7. Change Control
-
- Once a media type has been published by IANA, the author may request
- a change to its definition. The descriptions of the different
- registration trees above designate the "owners" of each type of
- registration. The change request follows the same procedure as the
- registration request:
-
- (1) Publish the revised template on the ietf-types list.
-
- (2) Leave at least two weeks for comments.
-
- (3) Publish using IANA after formal review if required.
-
- Changes should be requested only when there are serious omission or
- errors in the published specification. When review is required, a
- change request may be denied if it renders entities that were valid
- under the previous definition invalid under the new definition.
-
- The owner of a content type may pass responsibility for the content
- type to another person or agency by informing IANA and the ietf-types
- list; this can be done without discussion or review.
-
- The IESG may reassign responsibility for a media type. The most
- common case of this will be to enable changes to be made to types
- 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.
-
- Media type registrations may not be deleted; media types which are no
- longer believed appropriate for use can be declared OBSOLETE by a
- change to their "intended use" field; such media types will be
- clearly marked in the lists published by IANA.
-
-
-
-
-
-
-
-
-Freed, et. al. Best Current Practice [Page 13]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
-2.8. Registration Template
-
- To: ietf-types@iana.org
- Subject: Registration of MIME media type XXX/YYY
-
- MIME media type name:
-
- MIME subtype name:
-
- Required parameters:
-
- Optional parameters:
-
- Encoding considerations:
-
- Security considerations:
-
- Interoperability considerations:
-
- Published specification:
-
- Applications which use this media type:
-
- Additional information:
-
- Magic number(s):
- File extension(s):
- Macintosh File Type Code(s):
-
- 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.)
-
-3. External Body Access Types
-
- RFC 2046 defines the message/external-body media type, whereby a MIME
- entity can act as pointer to the actual body data in lieu of
- including the data directly in the entity body. Each
- message/external-body reference specifies an access type, which
- determines the mechanism used to retrieve the actual body data. RFC
- 2046 defines an initial set of access types, but allows for the
-
-
-
-Freed, et. al. Best Current Practice [Page 14]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
- registration of additional access types to accommodate new retrieval
- mechanisms.
-
-3.1. Registration Requirements
-
- New access type specifications must conform to a number of
- requirements as described below.
-
-3.1.1. Naming Requirements
-
- Each access type must have a unique name. This name appears in the
- access-type parameter in the message/external-body content-type
- header field, and must conform to MIME content type parameter syntax.
-
-3.1.2. Mechanism Specification Requirements
-
- All of the protocols, transports, and procedures used by a given
- access type must be described, either in the specification of the
- access type itself or in some other publicly available specification,
- in sufficient detail for the access type to be implemented by any
- competent implementor. Use of secret and/or proprietary methods in
- access types are expressly prohibited. The restrictions imposed by
- RFC 1602 on the standardization of patented algorithms must be
- respected as well.
-
-3.1.3. Publication Requirements
-
- All access types must be described by an RFC. The RFC may be
- informational rather than standards-track, although standard-track
- review and approval are encouraged for all access types.
-
-3.1.4. Security Requirements
-
- Any known security issues that arise from the use of the access type
- must be completely and fully described. It is not required that the
- access type be secure or that it be free from risks, but that the
- known risks be identified. Publication of a new access type does not
- require an exhaustive security review, and the security
- considerations section is subject to continuing evaluation.
- Additional security considerations should be addressed by publishing
- revised versions of the access type specification.
-
-3.2. Registration Procedure
-
- Registration of a new access type starts with the construction of a
- draft of an RFC.
-
-
-
-
-
-Freed, et. al. Best Current Practice [Page 15]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
-3.2.1. Present the Access Type to the Community
-
- Send a proposed access type specification to the "ietf-
- types@iana.org" mailing list for a two week review period. This
- mailing list has been established for the purpose of reviewing
- proposed access and media types. Proposed access types are not
- formally registered and must not be used.
-
- The intent of the public posting is to solicit comments and feedback
- on the access type specification and a review of any security
- considerations.
-
-3.2.2. Access Type Reviewer
-
- When the two week period has passed, the access type reviewer, who is
- appointed by the IETF Applications Area Director, either forwards the
- request to iana@isi.edu, or rejects it because of significant
- objections raised on the list.
-
- Decisions made by the reviewer must be posted to the ietf-types
- mailing list within 14 days. Decisions made by the reviewer may be
- appealed to the IESG.
-
-3.2.3. IANA Registration
-
- Provided that the access type has either passed review or has been
- successfully appealed to the IESG, the IANA will register the access
- type and make the registration available to the community. The
- specification of the access type must also be published as an RFC.
- Informational RFCs are published by sending them to "rfc-
- editor@isi.edu" (please follow the instructions to RFC authors [RFC-
- 1543]).
-
-3.3. Location of Registered Access Type List
-
- Access type registrations will be posted in the anonymous FTP
- directory "ftp://ftp.isi.edu/in-notes/iana/assignments/access-types/"
- and all registered access types will be listed in the periodically
- issued "Assigned Numbers" RFC [currently RFC-1700].
-
-3.4. IANA Procedures for Registering Access Types
-
- The identity of the access type reviewer is communicated to the IANA
- by the IESG. The IANA then only acts in response to access type
- definitions that either are approved by the access type reviewer and
- forwarded by the reviewer to the IANA for registration, or in
- response to a communication from the IESG that an access type
- definition appeal has overturned the access type reviewer's ruling.
-
-
-
-Freed, et. al. Best Current Practice [Page 16]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
-4. Transfer Encodings
-
- Transfer encodings are tranformations applied to MIME media types
- after conversion to the media type's canonical form. Transfer
- encodings are used for several purposes:
-
- (1) Many transports, especially message transports, can
- only handle data consisting of relatively short lines
- of text. There can also be severe restrictions on what
- characters can be used in these lines of text -- some
- transports are restricted to a small subset of US-ASCII
- and others cannot handle certain character sequences.
- Transfer encodings are used to transform binary data
- into textual form that can survive such transports.
- Examples of this sort of transfer encoding include the
- base64 and quoted-printable transfer encodings defined
- in RFC 2045.
-
- (2) Image, audio, video, and even application entities are
- sometimes quite large. Compression algorithms are often
- quite effective in reducing the size of large entities.
- Transfer encodings can be used to apply general-purpose
- non-lossy compression algorithms to MIME entities.
-
- (3) Transport encodings can be defined as a means of
- representing existing encoding formats in a MIME
- context.
-
- IMPORTANT: The standardization of a large numbers of different
- transfer encodings is seen as a significant barrier to widespread
- interoperability and is expressely discouraged. Nevertheless, the
- following procedure has been defined to provide a means of defining
- additional transfer encodings, should standardization actually be
- justified.
-
-4.1. Transfer Encoding Requirements
-
- Transfer encoding specifications must conform to a number of
- requirements as described below.
-
-4.1.1. Naming Requirements
-
- Each transfer encoding must have a unique name. This name appears in
- the Content-Transfer-Encoding header field and must conform to the
- syntax of that field.
-
-
-
-
-
-
-Freed, et. al. Best Current Practice [Page 17]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
-4.1.2. Algorithm Specification Requirements
-
- All of the algorithms used in a transfer encoding (e.g. conversion
- to printable form, compression) must be described in their entirety
- in the transfer encoding specification. Use of secret and/or
- proprietary algorithms in standardized transfer encodings are
- expressly prohibited. The restrictions imposed by RFC 1602 on the
- standardization of patented algorithms must be respected as well.
-
-4.1.3. Input Domain Requirements
-
- All transfer encodings must be applicable to an arbitrary sequence of
- octets of any length. Dependence on particular input forms is not
- allowed.
-
- It should be noted that the 7bit and 8bit encodings do not conform to
- this requirement. Aside from the undesireability of having
- specialized encodings, the intent here is to forbid the addition of
- additional encodings along the lines of 7bit and 8bit.
-
-4.1.4. Output Range Requirements
-
- There is no requirement that a particular tranfer encoding produce a
- particular form of encoded output. However, the output format for
- each transfer encoding must be fully and completely documented. In
- particular, each specification must clearly state whether the output
- format always lies within the confines of 7bit data, 8bit data, or is
- simply pure binary data.
-
-4.1.5. Data Integrity and Generality Requirements
-
- All transfer encodings must be fully invertible on any platform; it
- must be possible for anyone to recover the original data by
- performing the corresponding decoding operation. Note that this
- requirement effectively excludes all forms of lossy compression as
- well as all forms of encryption from use as a transfer encoding.
-
-4.1.6. New Functionality Requirements
-
- All transfer encodings must provide some sort of new functionality.
- Some degree of functionality overlap with previously defined transfer
- encodings is acceptable, but any new transfer encoding must also
- offer something no other transfer encoding provides.
-
-
-
-
-
-
-
-
-Freed, et. al. Best Current Practice [Page 18]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
-4.2. Transfer Encoding Definition Procedure
-
- Definition of a new transfer encoding starts with the construction of
- a draft of a standards-track RFC. The RFC must define the transfer
- encoding precisely and completely, and must also provide substantial
- justification for defining and standardizing a new transfer encoding.
- This specification must then be presented to the IESG for
- consideration. The IESG can
-
- (1) reject the specification outright as being
- inappropriate for standardization,
-
- (2) approve the formation of an IETF working group to work
- on the specification in accordance with IETF
- procedures, or,
-
- (3) accept the specification as-is and put it directly on
- the standards track.
-
- Transfer encoding specifications on the standards track follow normal
- IETF rules for standards track documents. A transfer encoding is
- considered to be defined and available for use once it is on the
- standards track.
-
-4.3. IANA Procedures for Transfer Encoding Registration
-
- There is no need for a special procedure for registering Transfer
- Encodings with the IANA. All legitimate transfer encoding
- registrations must appear as a standards-track RFC, so it is the
- IESG's responsibility to notify the IANA when a new transfer encoding
- has been approved.
-
-4.4. Location of Registered Transfer Encodings List
-
- Transfer encoding registrations will be posted in the anonymous FTP
- directory "ftp://ftp.isi.edu/in-notes/iana/assignments/transfer-
- encodings/" and all registered transfer encodings will be listed in
- the periodically issued "Assigned Numbers" RFC [currently RFC-1700].
-
-
-
-
-
-
-
-
-
-
-
-
-
-Freed, et. al. Best Current Practice [Page 19]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
-5. 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: ned@innosoft.com
-
-
- John Klensin
- MCI
- 2100 Reston Parkway
- Reston, VA 22091
-
- Phone: +1 703 715-7361
- Fax: +1 703 715-7436
- EMail: klensin@mci.net
-
-
- Jon Postel
- USC/Information Sciences Institute
- 4676 Admiralty Way
- Marina del Rey, CA 90292
- USA
-
-
- Phone: +1 310 822 1511
- Fax: +1 310 823 6714
- EMail: Postel@ISI.EDU
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Freed, et. al. Best Current Practice [Page 20]
-
-RFC 2048 MIME Registration Procedures November 1996
-
-
-Appendix A -- Grandfathered Media Types
-
- A number of media types, registered prior to 1996, would, if
- registered under the guidelines in this document, be placed into
- either the vendor or personal trees. Reregistration of those types
- to reflect the appropriate trees is encouraged, but not required.
- Ownership and change control principles outlined in this document
- apply to those types as if they had been registered in the trees
- described above.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Freed, et. al. Best Current Practice [Page 21]
-
diff --git a/doc/src/rfc2049.txt b/doc/src/rfc2049.txt
@@ -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: ned@innosoft.com
-
- Nathaniel S. Borenstein
- First Virtual Holdings
- 25 Washington Avenue
- Morristown, NJ 07960
- USA
-
- Phone: +1 201 540 8967
- Fax: +1 201 993 3032
- EMail: nsb@nsb.fv.com
-
- 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: Greg.Vaudreuil@Octel.Com
-
-
-
-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 <nsb@nsb.fv.com>
- To: Ned Freed <ned@innosoft.com>
- 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/src/rfc2183.txt b/doc/src/rfc2183.txt
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Troost
-Request for Comments: 2183 New Century Systems
-Updates: 1806 S. Dorner
-Category: Standards Track QUALCOMM Incorporated
- K. Moore, Editor
- University of Tennessee
- August 1997
-
-
- Communicating Presentation Information in
- Internet Messages:
- The Content-Disposition Header Field
-
-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 provides a mechanism whereby messages conforming to the
- MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC
- 2049] can convey presentational information. It specifies the
- "Content-Disposition" header field, which is optional and valid for
- any MIME entity ("message" or "body part"). Two values for this
- header field are described in this memo; one for the ordinary linear
- presentation of the body part, and another to facilitate the use of
- mail to transfer files. It is expected that more values will be
- defined in the future, and procedures are defined for extending this
- set of values.
-
- This document is intended as an extension to MIME. As such, the
- reader is assumed to be familiar with the MIME specifications, and
- [RFC 822]. The information presented herein supplements but does not
- replace that found in those documents.
-
- This document is a revision to the Experimental protocol defined in
- RFC 1806. As compared to RFC 1806, this document contains minor
- editorial updates, adds new parameters needed to support the File
- Transfer Body Part, and references a separate specification for the
- handling of non-ASCII and/or very long parameter values.
-
-
-
-
-
-
-
-Troost, et. al. Standards Track [Page 1]
-
-RFC 2183 Content-Disposition August 1997
-
-
-1. Introduction
-
- MIME specifies a standard format for encapsulating multiple pieces of
- data into a single Internet message. That document does not address
- the issue of presentation styles; it provides a framework for the
- interchange of message content, but leaves presentation issues solely
- in the hands of mail user agent (MUA) implementors.
-
- Two common ways of presenting multipart electronic messages are as a
- main document with a list of separate attachments, and as a single
- document with the various parts expanded (displayed) inline. The
- display of an attachment is generally construed to require positive
- action on the part of the recipient, while inline message components
- are displayed automatically when the message is viewed. A mechanism
- is needed to allow the sender to transmit this sort of presentational
- information to the recipient; the Content-Disposition header provides
- this mechanism, allowing each component of a message to be tagged
- with an indication of its desired presentation semantics.
-
- Tagging messages in this manner will often be sufficient for basic
- message formatting. However, in many cases a more powerful and
- flexible approach will be necessary. The definition of such
- approaches is beyond the scope of this memo; however, such approaches
- can benefit from additional Content-Disposition values and
- parameters, to be defined at a later date.
-
- In addition to allowing the sender to specify the presentational
- disposition of a message component, it is desirable to allow her to
- indicate a default archival disposition; a filename. The optional
- "filename" parameter provides for this. Further, the creation-date,
- modification-date, and read-date parameters allow preservation of
- those file attributes when the file is transmitted over MIME email.
-
- NB: The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
- SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
- document, are to be interpreted as described in [RFC 2119].
-
-2. The Content-Disposition Header Field
-
- Content-Disposition is an optional header field. In its absence, the
- MUA may use whatever presentation method it deems suitable.
-
- It is desirable to keep the set of possible disposition types small
- and well defined, to avoid needless complexity. Even so, evolving
- usage will likely require the definition of additional disposition
- types or parameters, so the set of disposition values is extensible;
- see below.
-
-
-
-
-Troost, et. al. Standards Track [Page 2]
-
-RFC 2183 Content-Disposition August 1997
-
-
- In the extended BNF notation of [RFC 822], the Content-Disposition
- header field is defined as follows:
-
- disposition := "Content-Disposition" ":"
- disposition-type
- *(";" disposition-parm)
-
- disposition-type := "inline"
- / "attachment"
- / extension-token
- ; values are not case-sensitive
-
- disposition-parm := filename-parm
- / creation-date-parm
- / modification-date-parm
- / read-date-parm
- / size-parm
- / parameter
-
- filename-parm := "filename" "=" value
-
- creation-date-parm := "creation-date" "=" quoted-date-time
-
- modification-date-parm := "modification-date" "=" quoted-date-time
-
- read-date-parm := "read-date" "=" quoted-date-time
-
- size-parm := "size" "=" 1*DIGIT
-
- quoted-date-time := quoted-string
- ; contents MUST be an RFC 822 `date-time'
- ; numeric timezones (+HHMM or -HHMM) MUST be used
-
-
-
- NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters)
- parameter value containing only non-`tspecials' characters SHOULD be
- represented as a single `token'. A short parameter value containing
- only ASCII characters, but including `tspecials' characters, SHOULD
- be represented as `quoted-string'. Parameter values longer than 78
- characters, or which contain non-ASCII characters, MUST be encoded as
- specified in [RFC 2184].
-
- `Extension-token', `parameter', `tspecials' and `value' are defined
- according to [RFC 2045] (which references [RFC 822] in the definition
- of some of these tokens). `quoted-string' and `DIGIT' are defined in
- [RFC 822].
-
-
-
-
-Troost, et. al. Standards Track [Page 3]
-
-RFC 2183 Content-Disposition August 1997
-
-
-2.1 The Inline Disposition Type
-
- A bodypart should be marked `inline' if it is intended to be
- displayed automatically upon display of the message. Inline
- bodyparts should be presented in the order in which they occur,
- subject to the normal semantics of multipart messages.
-
-2.2 The Attachment Disposition Type
-
- Bodyparts can be designated `attachment' to indicate that they are
- separate from the main body of the mail message, and that their
- display should not be automatic, but contingent upon some further
- action of the user. The MUA might instead present the user of a
- bitmap terminal with an iconic representation of the attachments, or,
- on character terminals, with a list of attachments from which the
- user could select for viewing or storage.
-
-2.3 The Filename Parameter
-
- The sender may want to suggest a filename to be used if the entity is
- detached and stored in a separate file. If the receiving MUA writes
- the entity to a file, the suggested filename should be used as a
- basis for the actual filename, where possible.
-
- It is important that the receiving MUA not blindly use the suggested
- filename. The suggested filename SHOULD be checked (and possibly
- changed) to see that it conforms to local filesystem conventions,
- does not overwrite an existing file, and does not present a security
- problem (see Security Considerations below).
-
- The receiving MUA SHOULD NOT respect any directory path information
- that may seem to be present in the filename parameter. The filename
- should be treated as a terminal component only. Portable
- specification of directory paths might possibly be done in the future
- via a separate Content-Disposition parameter, but no provision is
- made for it in this draft.
-
- Current [RFC 2045] grammar restricts parameter values (and hence
- Content-Disposition filenames) to US-ASCII. We recognize the great
- desirability of allowing arbitrary character sets in filenames, but
- it is beyond the scope of this document to define the necessary
- mechanisms. We expect that the basic [RFC 1521] `value'
- specification will someday be amended to allow use of non-US-ASCII
- characters, at which time the same mechanism should be used in the
- Content-Disposition filename parameter.
-
-
-
-
-
-
-Troost, et. al. Standards Track [Page 4]
-
-RFC 2183 Content-Disposition August 1997
-
-
- Beyond the limitation to US-ASCII, the sending MUA may wish to bear
- in mind the limitations of common filesystems. Many have severe
- length and character set restrictions. Short alphanumeric filenames
- are least likely to require modification by the receiving system.
-
- The presence of the filename parameter does not force an
- implementation to write the entity to a separate file. It is
- perfectly acceptable for implementations to leave the entity as part
- of the normal mail stream unless the user requests otherwise. As a
- consequence, the parameter may be used on any MIME entity, even
- `inline' ones. These will not normally be written to files, but the
- parameter could be used to provide a filename if the receiving user
- should choose to write the part to a file.
-
-2.4 The Creation-Date parameter
-
- The creation-date parameter MAY be used to indicate the date at which
- the file was created. If this parameter is included, the paramter
- value MUST be a quoted-string which contains a representation of the
- creation date of the file in [RFC 822] `date-time' format.
-
- UNIX and POSIX implementors are cautioned that the `st_ctime' file
- attribute of the `stat' structure is not the creation time of the
- file; it is thus not appropriate as a source for the creation-date
- parameter value.
-
-2.5 The Modification-Date parameter
-
- The modification-date parameter MAY be used to indicate the date at
- which the file was last modified. If the modification-date parameter
- is included, the paramter value MUST be a quoted-string which
- contains a representation of the last modification date of the file
- in [RFC 822] `date-time' format.
-
-2.6 The Read-Date parameter
-
- The read-date parameter MAY be used to indicate the date at which the
- file was last read. If the read-date parameter is included, the
- parameter value MUST be a quoted-string which contains a
- representation of the last-read date of the file in [RFC 822] `date-
- time' format.
-
-2.7 The Size parameter
-
- The size parameter indicates an approximate size of the file in
- octets. It can be used, for example, to pre-allocate space before
- attempting to store the file, or to determine whether enough space
- exists.
-
-
-
-Troost, et. al. Standards Track [Page 5]
-
-RFC 2183 Content-Disposition August 1997
-
-
-2.8 Future Extensions and Unrecognized Disposition Types
-
- In the likely event that new parameters or disposition types are
- needed, they should be registered with the Internet Assigned Numbers
- Authority (IANA), in the manner specified in Section 9 of this memo.
-
- Once new disposition types and parameters are defined, there is of
- course the likelihood that implementations will see disposition types
- and parameters they do not understand. Furthermore, since x-tokens
- are allowed, implementations may also see entirely unregistered
- disposition types and parameters.
-
- Unrecognized parameters should be ignored. Unrecognized disposition
- types should be treated as `attachment'. The choice of `attachment'
- for unrecognized types is made because a sender who goes to the
- trouble of producing a Content-Disposition header with a new
- disposition type is more likely aiming for something more elaborate
- than inline presentation.
-
- Unless noted otherwise in the definition of a parameter, Content-
- Disposition parameters are valid for all dispositions. (In contrast
- to MIME content-type parameters, which are defined on a per-content-
- type basis.) Thus, for example, the `filename' parameter still means
- the name of the file to which the part should be written, even if the
- disposition itself is unrecognized.
-
-2.9 Content-Disposition and Multipart
-
- If a Content-Disposition header is used on a multipart body part, it
- applies to the multipart as a whole, not the individual subparts.
- The disposition types of the subparts do not need to be consulted
- until the multipart itself is presented. When the multipart is
- displayed, then the dispositions of the subparts should be respected.
-
- If the `inline' disposition is used, the multipart should be
- displayed as normal; however, an `attachment' subpart should require
- action from the user to display.
-
- If the `attachment' disposition is used, presentation of the
- multipart should not proceed without explicit user action. Once the
- user has chosen to display the multipart, the individual subpart
- dispositions should be consulted to determine how to present the
- subparts.
-
-
-
-
-
-
-
-
-Troost, et. al. Standards Track [Page 6]
-
-RFC 2183 Content-Disposition August 1997
-
-
-2.10 Content-Disposition and the Main Message
-
- It is permissible to use Content-Disposition on the main body of an
- [RFC 822] message.
-
-3. Examples
-
- Here is a an example of a body part containing a JPEG image that is
- intended to be viewed by the user immediately:
-
- Content-Type: image/jpeg
- Content-Disposition: inline
- Content-Description: just a small picture of me
-
- <jpeg data>
-
- The following body part contains a JPEG image that should be
- displayed to the user only if the user requests it. If the JPEG is
- written to a file, the file should be named "genome.jpg". The
- recipient's user might also choose to set the last-modified date of
- the stored file to date in the modification-date parameter:
-
- Content-Type: image/jpeg
- Content-Disposition: attachment; filename=genome.jpeg;
- modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
- Content-Description: a complete map of the human genome
-
- <jpeg data>
-
- The following is an example of the use of the `attachment'
- disposition with a multipart body part. The user should see text-
- part-1 immediately, then take some action to view multipart-2. After
- taking action to view multipart-2, the user will see text-part-2
- right away, and be required to take action to view jpeg-1. Subparts
- are indented for clarity; they would not be so indented in a real
- message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Troost, et. al. Standards Track [Page 7]
-
-RFC 2183 Content-Disposition August 1997
-
-
- Content-Type: multipart/mixed; boundary=outer
- Content-Description: multipart-1
-
- --outer
- Content-Type: text/plain
- Content-Disposition: inline
- Content-Description: text-part-1
-
- Some text goes here
-
- --outer
- Content-Type: multipart/mixed; boundary=inner
- Content-Disposition: attachment
- Content-Description: multipart-2
-
- --inner
- Content-Type: text/plain
- Content-Disposition: inline
- Content-Description: text-part-2
-
- Some more text here.
-
- --inner
- Content-Type: image/jpeg
- Content-Disposition: attachment
- Content-Description: jpeg-1
-
- <jpeg data>
- --inner--
- --outer--
-
-4. Summary
-
- Content-Disposition takes one of two values, `inline' and
- `attachment'. `Inline' indicates that the entity should be
- immediately displayed to the user, whereas `attachment' means that
- the user should take additional action to view the entity.
-
- The `filename' parameter can be used to suggest a filename for
- storing the bodypart, if the user wishes to store it in an external
- file.
-
-
-
-
-
-
-
-
-
-
-Troost, et. al. Standards Track [Page 8]
-
-RFC 2183 Content-Disposition August 1997
-
-
-5. Security Considerations
-
- There are security issues involved any time users exchange data.
- While these are not to be minimized, neither does this memo change
- the status quo in that regard, except in one instance.
-
- Since this memo provides a way for the sender to suggest a filename,
- a receiving MUA must take care that the sender's suggested filename
- does not represent a hazard. Using UNIX as an example, some hazards
- would be:
-
- + Creating startup files (e.g., ".login").
-
- + Creating or overwriting system files (e.g., "/etc/passwd").
-
- + Overwriting any existing file.
-
- + Placing executable files into any command search path
- (e.g., "~/bin/more").
-
- + Sending the file to a pipe (e.g., "| sh").
-
- In general, the receiving MUA should not name or place the file such
- that it will get interpreted or executed without the user explicitly
- initiating the action.
-
- It is very important to note that this is not an exhaustive list; it
- is intended as a small set of examples only. Implementors must be
- alert to the potential hazards on their target systems.
-
-6. References
-
- [RFC 2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119, March 1997.
-
- [RFC 2184]
- Freed, N. and K. Moore, "MIME Parameter value and Encoded Words:
- Character Sets, Lanaguage, and Continuations", RFC 2184, August
- 1997.
-
- [RFC 2045]
- Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
- Extensions) Part One: Format of Internet Message Bodies", RFC
- 2045, December 1996.
-
-
-
-
-
-
-Troost, et. al. Standards Track [Page 9]
-
-RFC 2183 Content-Disposition August 1997
-
-
- [RFC 2046]
- Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
- Extensions) Part Two: Media Types", RFC 2046, December 1996.
-
- [RFC 2047]
- Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
- Three: Message Header Extensions for non-ASCII Text", RFC 2047,
- December 1996.
-
- [RFC 2048]
- Freed, N., Klensin, J. and J. Postel, "MIME (Multipurpose
- Internet Mail Extensions) Part Four: Registration Procedures",
- RFC 2048, December 1996.
-
- [RFC 2049]
- Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
- Extensions) Part Five: Conformance Criteria and Examples", RFC
- 2049, December 1996.
-
- [RFC 822]
- Crocker, D., "Standard for the Format of ARPA Internet Text
- Messages", STD 11, RFC 822, UDEL, August 1982.
-
-7. Acknowledgements
-
- We gratefully acknowledge the help these people provided during the
- preparation of this draft:
-
- Nathaniel Borenstein
- Ned Freed
- Keith Moore
- Dave Crocker
- Dan Pritchett
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Troost, et. al. Standards Track [Page 10]
-
-RFC 2183 Content-Disposition August 1997
-
-
-8. Authors' Addresses
-
- You should blame the editor of this version of the document for any
- changes since RFC 1806:
-
- Keith Moore
- Department of Computer Science
- University of Tennessee, Knoxville
- 107 Ayres Hall
- Knoxville TN 37996-1301
- USA
-
- Phone: +1 (423) 974-5067
- Fax: +1 (423) 974-8296
- Email: moore@cs.utk.edu
-
-
- The authors of RFC 1806 are:
-
- Rens Troost
- New Century Systems
- 324 East 41st Street #804
- New York, NY, 10017 USA
-
- Phone: +1 (212) 557-2050
- Fax: +1 (212) 557-2049
- EMail: rens@century.com
-
-
- Steve Dorner
- QUALCOMM Incorporated
- 6455 Lusk Boulevard
- San Diego, CA 92121
- USA
-
- EMail: sdorner@qualcomm.com
-
-
-9. Registration of New Content-Disposition Values and Parameters
-
- New Content-Disposition values (besides "inline" and "attachment")
- may be defined only by Internet standards-track documents, or in
- Experimental documents approved by the Internet Engineering Steering
- Group.
-
-
-
-
-
-
-
-Troost, et. al. Standards Track [Page 11]
-
-RFC 2183 Content-Disposition August 1997
-
-
- New content-disposition parameters may be registered by supplying the
- information in the following template and sending it via electronic
- mail to IANA@IANA.ORG:
-
- To: IANA@IANA.ORG
- Subject: Registration of new Content-Disposition parameter
-
- Content-Disposition parameter name:
-
- Allowable values for this parameter:
- (If the parameter can only assume a small number of values,
- list each of those values. Otherwise, describe the values
- that the parameter can assume.)
- Description:
- (What is the purpose of this parameter and how is it used?)
-
-10. Changes since RFC 1806
-
- The following changes have been made since the earlier version of
- this document, published in RFC 1806 as an Experimental protocol:
-
- + Updated references to MIME documents. In some cases this
- involved substituting a reference to one of the current MIME
- RFCs for a reference to RFC 1521; in other cases, a reference to
- RFC 1521 was simply replaced with the word "MIME".
-
- + Added a section on registration procedures, since none of the
- procedures in RFC 2048 seemed to be appropriate.
-
- + Added new parameter types: creation-date, modification-date,
- read-date, and size.
-
-
- + Incorporated a reference to draft-freed-pvcsc-* for encoding
- long or non-ASCII parameter values.
-
- + Added reference to RFC 2119 to define MUST, SHOULD, etc.
- keywords.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Troost, et. al. Standards Track [Page 12]
-
diff --git a/doc/src/rfc2231.txt b/doc/src/rfc2231.txt
@@ -1,563 +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?= <moore@cs.utk.edu>
-
-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: ned.freed@innosoft.com
-
-
- Keith Moore
- Computer Science Dept.
- University of Tennessee
- 107 Ayres Hall
- Knoxville, TN 37996-1301
- USA
-
- EMail: moore@cs.utk.edu
-
-
-
-
-
-
-
-
-
-
-
-
-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/src/rfc2342.txt b/doc/src/rfc2342.txt
@@ -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: mikega@microsoft.com
-
-
- Chris Newman
- Innosoft International, Inc.
- 1050 East Garvey Ave. South
- West Covina, CA, 91790, USA
-
- EMail: chris.newman@innosoft.com
-
-
-
-
-
-
-
-
-
-
-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/src/rfc2359.txt b/doc/src/rfc2359.txt
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Myers
-Request for Comments: 2359 Netscape Communications
-Category: Standards Track June 1998
-
-
- IMAP4 UIDPLUS 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 (1998). All Rights Reserved.
-
-IESG NOTE
-
- The IMAP extension described here assumes a particular means of using
- IMAP to support disconnected operation. However, this means of
- supporting disconnected operation is not yet documented. Also, there
- are multiple theories about how best to do disconnected operation in
- IMAP, and as yet, there is no consensus on which one should be
- adopted as a standard.
-
- This document is being approved as a Proposed Standard because it
- does not appear to have technical flaws in itelf. However, approval
- of this document as a Proposed Standard should not be considered an
- IETF endorsement of any particular means of doing disconnected
- operation in IMAP.
-
-Table of Contents
-
- 1. Abstract .............................................. 2
- 2. Conventions Used in this Document ..................... 2
- 3. Introduction and Overview ............................. 2
- 4. Features .............................................. 2
- 4.1. UID EXPUNGE Command ................................... 2
- 4.2. APPENDUID response code ............................... 3
- 4.3. COPYUID response code ................................. 4
- 5. Formal Syntax ......................................... 4
- 6. References ............................................ 4
- 7. Security Considerations ............................... 5
- 8. Author's Address ...................................... 5
- 9. Full Copyright Statement .............................. 6
-
-
-
-Myers Standards Track [Page 1]
-
-RFC 2359 IMAP4 UIDPLUS extension June 1998
-
-
-1. Abstract
-
- The UIDPLUS extension of the Internet Message Access Protocol [IMAP4]
- provides a set of features intended to reduce the amount of time and
- resources used by some client operations. The features in UIDPLUS
- are primarily intended for disconnected-use clients.
-
-2. Conventions Used in this Document
-
- In examples, "C:" and "S:" indicate lines sent by the client and
- server respectively.
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
- in this document are to be interpreted as defined in "Key words for
- use in RFCs to Indicate Requirement Levels" [KEYWORDS].
-
-3. Introduction and Overview
-
- The UIDPLUS extension is present in any IMAP4 server implementation
- which returns "UIDPLUS" as one of the supported capabilities to the
- CAPABILITY command. The UIDPLUS extension contains one additional
- command and additional data returned with successful APPEND and COPY
- commands.
-
- Clients that wish to use the new command in UIDPLUS must of course
- first test for the presence of the extension by issuing a CAPABILITY
- command. Each of the features in UIDPLUS are optimizations; clients
- can provide the same functionality, albeit more slowly, by using
- commands in the base protocol. With each feature, this document
- recommends a fallback approach to take when the UIDPLUS extension is
- not supported by the server.
-
-4. Features
-
-4.1. UID EXPUNGE Command
-
- Arguments: message set
-
- Data: untagged responses: EXPUNGE
-
- Result: OK - expunge completed
- NO - expunge failure (e.g. permission denied)
- BAD - command unknown or arguments invalid
-
-
-
-
-
-
-
-
-Myers Standards Track [Page 2]
-
-RFC 2359 IMAP4 UIDPLUS extension June 1998
-
-
- The UID EXPUNGE command permanently removes from the currently
- selected mailbox all messages that both have the \Deleted flag set
- and have a UID that is included in the specified message set. If
- a message either does not have the \Deleted flag set or is has a
- UID that is not included in the specified message set, it is not
- affected.
-
- This command may be used to ensure that a replayed EXPUNGE command
- does not remove any messages that have been marked as \Deleted
- between the time that the user requested the expunge operation and
- the time the server processes the command.
-
- If the server does not support the UIDPLUS capability, the client
- should fall back to using the STORE command to temporarily remove
- the \Deleted flag from messages it does not want to remove. The
- client could alternatively fall back to using the EXPUNGE command,
- risking the unintended removal of some messages.
-
- Example: C: A003 UID EXPUNGE 3000:3002
- S: * 3 EXPUNGE
- S: * 3 EXPUNGE
- S: * 3 EXPUNGE
- S: A003 OK UID EXPUNGE completed
-
-4.2. APPENDUID response code
-
- Successful APPEND commands return an APPENDUID response code in the
- tagged OK response. The APPENDUID response code contains as
- arguments the UIDVALIDITY of the destination mailbox and the UID
- assigned to the appended message.
-
- If the server does not support the UIDPLUS capability, the client can
- only discover this information by selecting the destination mailbox
- and issuing FETCH commands.
-
- Example: C: A003 APPEND saved-messages (\Seen) {310}
- C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
- C: From: Fred Foobar <foobar@Blurdybloop.COM>
- C: Subject: afternoon meeting
- C: To: mooch@owatagu.siam.edu
- C: Message-Id: <B27397-0100000@Blurdybloop.COM>
- 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 [APPENDUID 38505 3955] APPEND completed
-
-
-
-
-Myers Standards Track [Page 3]
-
-RFC 2359 IMAP4 UIDPLUS extension June 1998
-
-
-4.3. COPYUID response code
-
- Successful COPY and UID COPY commands return a COPYUID response code
- in the tagged OK response whenever at least one message was copied.
- The COPYUID response code contains as an argument the UIDVALIDITY of
- the appended-to mailbox, a message set containing the UIDs of the
- messages copied to the destination mailbox, in the order they were
- copied, and a message containing the UIDs assigned to the copied
- messages, in the order they were assigned. Neither of the message
- sets may contain extraneous UIDs or the symbol '*'.
-
- If the server does not support the UIDPLUS capability, the client can
- only discover this information by selecting the destination mailbox
- and issuing FETCH commands.
-
- Example: C: A003 COPY 2:4 MEETING
- S: A003 OK [COPYUID 38505 304,319:320 3956:3958] Done
- C: A003 UID COPY 305:310 MEETING
- S: A003 OK Done
-
-5. 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].
-
- 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.
-
- resp_code_apnd ::= "APPENDUID" SPACE nz_number SPACE uniqueid
-
- resp_code_copy ::= "COPYUID" SPACE nz_number SPACE set SPACE set
-
- uid_expunge ::= "UID" SPACE "EXPUNGE" SPACE set
-
-6. References
-
- [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.
-
- [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
- Text Messages", STD 11, RFC 822, August 1982.
-
-
-
-Myers Standards Track [Page 4]
-
-RFC 2359 IMAP4 UIDPLUS extension June 1998
-
-
-7. Security Considerations
-
- There are no known security issues with this extension.
-
-8. Author's Address
-
- John Gardiner Myers
- Netscape Communications
- 501 East Middlefield Road
- Mail Stop MV-029
- Mountain View, CA 94043
-
- EMail: jgmyers@netscape.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Myers Standards Track [Page 5]
-
-RFC 2359 IMAP4 UIDPLUS extension June 1998
-
-
-9. 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Myers Standards Track [Page 6]
-
diff --git a/doc/src/rfc2368.txt b/doc/src/rfc2368.txt
@@ -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:chris@example.com>
-
- A URL for a mail response system that requires the name of the file
- in the subject:
-
- <mailto:infobot@example.com?subject=current-issue>
-
- A mail response system that requires a "send" request in the body:
-
- <mailto:infobot@example.com?body=send%20current-issue>
-
- 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:infobot@example.com?body=send%20current-
- 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:foobar@example.com?In-Reply-
- To=%3c3469A91.D10AF4C@example.com>
-
- A request to subscribe to a mailing list:
-
- <mailto:majordomo@example.com?body=subscribe%20bamboo-l>
-
- A URL for a single user which includes a CC of another user:
-
- <mailto:joe@example.com?cc=bob@example.com&body=hello>
-
- Another way of expressing the same thing:
-
- <mailto:?to=joe@example.com&cc=bob@example.com&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:joe@example.com?cc=bob@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 "gorby%kremvax@example.com" one would do:
-
- <mailto:gorby%25kremvax@example.com>
-
- To indicate the address "unlikely?address@example.com", and include
- another header, one would do:
-
- <mailto:unlikely%3Faddress@example.com?blat=foop>
-
- 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:?to=joe@xyz.com&cc=bob@xyz.com&body=hello">
- mailto:?to=joe@xyz.com&cc=bob@xyz.com&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: phoffman@imc.org
-
-
- Larry Masinter
- Xerox Corporation
- 3333 Coyote Hill Road
- Palo Alto, CA 94304 USA
-
- EMail: masinter@parc.xerox.com
-
-
- Jamie Zawinski
- Netscape Communications Corp.
- 501 East Middlefield Road
- Mountain View, CA 94043 USA
-
- EMail: jwz@netscape.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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/src/rfc2487.txt b/doc/src/rfc2487.txt
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group P. Hoffman
-Request for Comments: 2487 Internet Mail Consortium
-Category: Standards Track January 1999
-
-
- SMTP Service Extension for Secure SMTP over TLS
-
-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. Abstract
-
- This document describes an extension to the SMTP service that allows
- an SMTP server and client to use transport-layer security to provide
- private, authenticated communication over the Internet. This gives
- SMTP agents the ability to protect some or all of their
- communications from eavesdroppers and attackers.
-
-2. Introduction
-
- SMTP [RFC-821] servers and clients normally communicate in the clear
- over the Internet. In many cases, this communication goes through one
- or more router that is not controlled or trusted by either entity.
- Such an untrusted router might allow a third party to monitor or
- alter the communications between the server and client.
-
- Further, there is often a desire for two SMTP agents to be able to
- authenticate each others' identities. For example, a secure SMTP
- server might only allow communications from other SMTP agents it
- knows, or it might act differently for messages received from an
- agent it knows than from one it doesn't know.
-
- TLS [TLS], more commonly known as SSL, is a popular mechanism for
- enhancing TCP communications with privacy and authentication. TLS is
- in wide use with the HTTP protocol, and is also being used for adding
- security to many other common protocols that run over TCP.
-
-
-
-
-
-
-Hoffman Standards Track [Page 1]
-
-RFC 2487 SMTP Service Extension January 1999
-
-
-2.1 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 in [RFC-2119].
-
-3. STARTTLS Extension
-
- The STARTTLS extension to SMTP is laid out as follows:
-
- (1) the name of the SMTP service defined here is STARTTLS;
-
- (2) the EHLO keyword value associated with the extension is STARTTLS;
-
- (3) the STARTTLS keyword has no parameters;
-
- (4) a new SMTP verb, "STARTTLS", is defined;
-
- (5) no additional parameters are added to any SMTP command.
-
-4. The STARTTLS Keyword
-
- The STARTTLS keyword is used to tell the SMTP client that the SMTP
- server allows use of TLS. It takes no parameters.
-
-5. The STARTTLS Command
-
- The format for the STARTTLS command is:
-
- STARTTLS
-
- with no parameters.
-
- After the client gives the STARTTLS command, the server responds with
- one of the following reply codes:
-
- 220 Ready to start TLS
- 501 Syntax error (no parameters allowed)
- 454 TLS not available due to temporary reason
-
- A publicly-referenced SMTP server MUST NOT require use of the
- STARTTLS extension in order to deliver mail locally. This rule
- prevents the STARTTLS extension from damaging the interoperability of
- the Internet's SMTP infrastructure. A publicly-referenced SMTP server
- is an SMTP server which runs on port 25 of an Internet host listed in
- the MX record (or A record if an MX record is not present) for the
- domain name on the right hand side of an Internet mail address.
-
-
-
-
-Hoffman Standards Track [Page 2]
-
-RFC 2487 SMTP Service Extension January 1999
-
-
- Any SMTP server may refuse to accept messages for relay based on
- authentication supplied during the TLS negotiation. An SMTP server
- that is not publicly referenced may refuse to accept any messages for
- relay or local delivery based on authentication supplied during the
- TLS negotiation.
-
- A SMTP server that is not publicly referenced may choose to require
- that the client perform a TLS negotiation before accepting any
- commands. In this case, the server SHOULD return the reply code:
-
- 530 Must issue a STARTTLS command first
-
- to every command other than NOOP, EHLO, STARTTLS, or QUIT. If the
- client and server are using the ENHANCEDSTATUSCODES ESMTP extension
- [RFC-2034], the status code to be returned SHOULD be 5.7.0.
-
- After receiving a 220 response to a STARTTLS command, the client
- SHOULD start the TLS negotiation before giving any other SMTP
- commands.
-
- If the SMTP client is using pipelining as defined in RFC 1854, the
- STARTTLS command must be the last command in a group.
-
-5.1 Processing After the STARTTLS Command
-
- After the TLS handshake has been completed, both parties MUST
- immediately decide whether or not to continue based on the
- authentication and privacy achieved. The SMTP client and server may
- decide to move ahead even if the TLS negotiation ended with no
- authentication and/or no privacy because most SMTP services are
- performed with no authentication and no privacy, but some SMTP
- clients or servers may want to continue only if a particular level of
- authentication and/or privacy was achieved.
-
- If the SMTP client decides that the level of authentication or
- privacy is not high enough for it to continue, it SHOULD issue an
- SMTP QUIT command immediately after the TLS negotiation is complete.
- If the SMTP server decides that the level of authentication or
- privacy is not high enough for it to continue, it SHOULD reply to
- every SMTP command from the client (other than a QUIT command) with
- the 554 reply code (with a possible text string such as "Command
- refused due to lack of security").
-
- The decision of whether or not to believe the authenticity of the
- other party in a TLS negotiation is a local matter. However, some
- general rules for the decisions are:
-
-
-
-
-
-Hoffman Standards Track [Page 3]
-
-RFC 2487 SMTP Service Extension January 1999
-
-
- - A SMTP client would probably only want to authenticate an SMTP
- server whose server certificate has a domain name that is the
- domain name that the client thought it was connecting to.
- - A publicly-referenced SMTP server would probably want to accept
- any certificate from an SMTP client, and would possibly want to
- put distinguishing information about the certificate in the
- Received header of messages that were relayed or submitted from
- the client.
-
-5.2 Result of the STARTTLS Command
-
- Upon completion of the TLS handshake, the SMTP protocol is reset to
- the initial state (the state in SMTP after a server issues a 220
- service ready greeting). The server MUST discard any knowledge
- obtained from the client, such as the argument to the EHLO command,
- which was not obtained from the TLS negotiation itself. The client
- MUST discard any knowledge obtained from the server, such as the list
- of SMTP service extensions, which was not obtained from the TLS
- negotiation itself. The client SHOULD send an EHLO command as the
- first command after a successful TLS negotiation.
-
- The list of SMTP service extensions returned in response to an EHLO
- command received after the TLS handshake MAY be different than the
- list returned before the TLS handshake. For example, an SMTP server
- might not want to advertise support for a particular SASL mechanism
- [SASL] unless a client has sent an appropriate client certificate
- during a TLS handshake.
-
- Both the client and the server MUST know if there is a TLS session
- active. A client MUST NOT attempt to start a TLS session if a TLS
- session is already active. A server MUST NOT return the TLS extension
- in response to an EHLO command received after a TLS handshake has
- completed.
-
-6. Usage Example
-
- The following dialog illustrates how a client and server can start a
- TLS session:
-
- S: <waits for connection on TCP port 25>
- C: <opens connection>
- S: 220 mail.imc.org SMTP service ready
- C: EHLO mail.ietf.org
- S: 250-mail.imc.org offers a warm hug of welcome
- S: 250 STARTTLS
- C: STARTTLS
- S: 220 Go ahead
- C: <starts TLS negotiation>
-
-
-
-Hoffman Standards Track [Page 4]
-
-RFC 2487 SMTP Service Extension January 1999
-
-
- C & S: <negotiate a TLS session>
- C & S: <check result of negotiation>
- C: <continues by sending an SMTP command>
- . . .
-
-7. Security Considerations
-
- It should be noted that SMTP is not an end-to-end mechanism. Thus, if
- an SMTP client/server pair decide to add TLS privacy, they are not
- securing the transport from the originating mail user agent to the
- recipient. Further, because delivery of a single piece of mail may
- go between more than two SMTP servers, adding TLS privacy to one pair
- of servers does not mean that the entire SMTP chain has been made
- private. Further, just because an SMTP server can authenticate an
- SMTP client, it does not mean that the mail from the SMTP client was
- authenticated by the SMTP client when the client received it.
-
- Both the STMP client and server must check the result of the 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-dependant,
- and is beyond the scope of this document.
-
- The SMTP client and server should note carefully the result of the
- TLS negotiation. If the negotiation results in no privacy, or if it
- results in privacy using algorithms or key lengths that are deemed
- not strong enough, or if the authentication is not good enough for
- either party, the client may choose to end the SMTP session with an
- immediate QUIT command, or the server may choose to not accept any
- more SMTP commands.
-
- A server announcing in an EHLO response that it uses a particular TLS
- protocol should not pose any security issues, since any use of TLS
- will be at least as secure as no use of TLS.
-
- A man-in-the-middle attack can be launched by deleting the "250
- STARTTLS" response from the server. This would cause the client not
- to try to start a TLS session. An SMTP client can protect against
- this attack by recording the fact that a particular SMTP server
- offers TLS during one session and generating an alarm if it does not
- appear in the EHLO response for a later session. The lack of TLS
- during a session SHOULD NOT result in the bouncing of email, although
- it could result in delayed processing.
-
-
-
-
-
-
-
-Hoffman Standards Track [Page 5]
-
-RFC 2487 SMTP Service Extension January 1999
-
-
- Before the TLS handshake has begun, any protocol interactions are
- performed in the clear and may be modified by an active attacker. For
- this reason, clients and servers MUST discard any knowledge obtained
- prior to the start of the TLS handshake upon completion of the TLS
- handshake.
-
- The STARTTLS extension is not suitable for authenticating the author
- of an email message unless every hop in the delivery chain, including
- the submission to the first SMTP server, is authenticated. Another
- proposal [SMTP-AUTH] can be used to authenticate delivery and MIME
- security multiparts [MIME-SEC] can be used to authenticate the author
- of an email message. In addition, the [SMTP-AUTH] proposal offers
- simpler and more flexible options to authenticate an SMTP client and
- the SASL EXTERNAL mechanism [SASL] MAY be used in conjunction with
- the STARTTLS command to provide an authorization identity.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman Standards Track [Page 6]
-
-RFC 2487 SMTP Service Extension January 1999
-
-
-A. References
-
- [RFC-821] Postel, J., "Simple Mail Transfer Protocol", RFC 821,
- August 1982.
-
- [RFC-1869] Klensin, J., Freed, N, Rose, M, Stefferud, E. and D.
- Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
- November 1995.
-
- [RFC-2034] Freed, N., "SMTP Service Extension for Returning Enhanced
- Error Codes", RFC 2034, October 1996.
-
- [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [SASL] Myers, J., "Simple Authentication and Security Layer
- (SASL)", RFC 2222, October 1997.
-
- [SMTP-AUTH] "SMTP Service Extension for Authentication", Work in
- Progress.
-
- [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
- RFC 2246, January 1999.
-
-B. Author's Address
-
- Paul Hoffman
- Internet Mail Consortium
- 127 Segre Place
- Santa Cruz, CA 95060
-
- Phone: (831) 426-9827
- EMail: phoffman@imc.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman Standards Track [Page 7]
-
-RFC 2487 SMTP Service Extension January 1999
-
-
-C. 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman Standards Track [Page 8]
-
diff --git a/doc/src/rfc2554.txt b/doc/src/rfc2554.txt
@@ -1,620 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Myers
-Request for Comments: 2554 Netscape Communications
-Category: Standards Track March 1999
-
-
- SMTP Service Extension
- for Authentication
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
-
-1. Introduction
-
- This document defines an SMTP service extension [ESMTP] whereby an
- SMTP client may indicate an authentication mechanism to the server,
- perform an authentication protocol exchange, and optionally negotiate
- a security layer for subsequent protocol interactions. This
- extension is a profile of the Simple Authentication and Security
- Layer [SASL].
-
-
-2. Conventions Used in this Document
-
- In examples, "C:" and "S:" indicate lines sent by the client and
- server respectively.
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
- in this document are to be interpreted as defined in "Key words for
- use in RFCs to Indicate Requirement Levels" [KEYWORDS].
-
-
-3. The Authentication service extension
-
-
- (1) the name of the SMTP service extension is "Authentication"
-
- (2) the EHLO keyword value associated with this extension is "AUTH"
-
-
-
-
-Myers Standards Track [Page 1]
-
-RFC 2554 SMTP Authentication March 1999
-
-
- (3) The AUTH EHLO keyword contains as a parameter a space separated
- list of the names of supported SASL mechanisms.
-
- (4) a new SMTP verb "AUTH" is defined
-
- (5) an optional parameter using the keyword "AUTH" is added to the
- MAIL FROM command, and extends the maximum line length of the
- MAIL FROM command by 500 characters.
-
- (6) this extension is appropriate for the submission protocol
- [SUBMIT].
-
-
-4. The AUTH command
-
- AUTH mechanism [initial-response]
-
- Arguments:
- a string identifying a SASL authentication mechanism.
- an optional base64-encoded response
-
- Restrictions:
- After an AUTH command has successfully completed, no more AUTH
- commands may be issued in the same session. After a successful
- AUTH command completes, a server MUST reject any further AUTH
- commands with a 503 reply.
-
- The AUTH command is not permitted during a mail transaction.
-
- Discussion:
- The AUTH command indicates an authentication mechanism to the
- server. If the server supports the requested authentication
- mechanism, it performs an authentication protocol exchange to
- authenticate and identify the user. Optionally, it also
- negotiates a security layer for subsequent protocol
- interactions. If the requested authentication mechanism is not
- supported, the server rejects the AUTH command with a 504
- reply.
-
- The authentication protocol exchange consists of a series of
- server challenges and client answers that are specific to the
- authentication mechanism. A server challenge, otherwise known
- as a ready response, is a 334 reply with the text part
- containing a BASE64 encoded string. The client answer consists
- of a line containing a BASE64 encoded string. If the client
- wishes to cancel an authentication exchange, it issues a line
- with a single "*". If the server receives such an answer, it
- MUST reject the AUTH command by sending a 501 reply.
-
-
-
-Myers Standards Track [Page 2]
-
-RFC 2554 SMTP Authentication March 1999
-
-
- The optional initial-response argument to the AUTH command is
- used to save a round trip when using authentication mechanisms
- that are defined to send no data in the initial challenge.
- When the initial-response argument is used with such a
- mechanism, the initial empty challenge is not sent to the
- client and the server uses the data in the initial-response
- argument as if it were sent in response to the empty challenge.
- Unlike a zero-length client answer to a 334 reply, a zero-
- length initial response is sent as a single equals sign ("=").
- If the client uses an initial-response argument to the AUTH
- command with a mechanism that sends data in the initial
- challenge, the server rejects the AUTH command with a 535
- reply.
-
- If the server cannot BASE64 decode the argument, it rejects the
- AUTH command with a 501 reply. If the server rejects the
- authentication data, it SHOULD reject the AUTH command with a
- 535 reply unless a more specific error code, such as one listed
- in section 6, is appropriate. Should the client successfully
- complete the authentication exchange, the SMTP server issues a
- 235 reply.
-
- The service name specified by this protocol's profile of SASL
- is "smtp".
-
- If a security layer is negotiated through the SASL
- authentication exchange, it takes effect immediately following
- the CRLF that concludes the authentication exchange for the
- client, and the CRLF of the success reply for the server. Upon
- a security layer's taking effect, the SMTP protocol is reset to
- the initial state (the state in SMTP after a server issues a
- 220 service ready greeting). The server MUST discard any
- knowledge obtained from the client, such as the argument to the
- EHLO command, which was not obtained from the SASL negotiation
- itself. The client MUST discard any knowledge obtained from
- the server, such as the list of SMTP service extensions, which
- was not obtained from the SASL negotiation itself (with the
- exception that a client MAY compare the list of advertised SASL
- mechanisms before and after authentication in order to detect
- an active down-negotiation attack). The client SHOULD send an
- EHLO command as the first command after a successful SASL
- negotiation which results in the enabling of a security layer.
-
- The server is not required to support any particular
- authentication mechanism, nor are authentication mechanisms
- required to support any security layers. If an AUTH command
- fails, the client may try another authentication mechanism by
- issuing another AUTH command.
-
-
-
-Myers Standards Track [Page 3]
-
-RFC 2554 SMTP Authentication March 1999
-
-
- If an AUTH command fails, the server MUST behave the same as if
- the client had not issued the AUTH command.
-
- The BASE64 string may in general be arbitrarily long. Clients
- and servers MUST be able to support challenges and responses
- that are as long as are generated by the authentication
- mechanisms they support, independent of any line length
- limitations the client or server may have in other parts of its
- protocol implementation.
-
- Examples:
- S: 220 smtp.example.com ESMTP server ready
- C: EHLO jgm.example.com
- S: 250-smtp.example.com
- S: 250 AUTH CRAM-MD5 DIGEST-MD5
- C: AUTH FOOBAR
- S: 504 Unrecognized authentication type.
- C: AUTH CRAM-MD5
- S: 334
- PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
- C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
- S: 235 Authentication successful.
-
-
-
-5. The AUTH parameter to the MAIL FROM command
-
- AUTH=addr-spec
-
- Arguments:
- An addr-spec containing the identity which submitted the message
- to the delivery system, or the two character sequence "<>"
- indicating such an identity is unknown or insufficiently
- authenticated. To comply with the restrictions imposed on ESMTP
- parameters, the addr-spec is encoded inside an xtext. The syntax
- of an xtext is described in section 5 of [ESMTP-DSN].
-
- Discussion:
- The optional AUTH parameter to the MAIL FROM command allows
- cooperating agents in a trusted environment to communicate the
- authentication of individual messages.
-
- If the server trusts the authenticated identity of the client to
- assert that the message was originally submitted by the supplied
- addr-spec, then the server SHOULD supply the same addr-spec in an
- AUTH parameter when relaying the message to any server which
- supports the AUTH extension.
-
-
-
-
-Myers Standards Track [Page 4]
-
-RFC 2554 SMTP Authentication March 1999
-
-
- A MAIL FROM parameter of AUTH=<> indicates that the original
- submitter of the message is not known. The server MUST NOT treat
- the message as having been originally submitted by the client.
-
- If the AUTH parameter to the MAIL FROM is not supplied, the
- client has authenticated, and the server believes the message is
- an original submission by the client, the server MAY supply the
- client's identity in the addr-spec in an AUTH parameter when
- relaying the message to any server which supports the AUTH
- extension.
-
- If the server does not sufficiently trust the authenticated
- identity of the client, or if the client is not authenticated,
- then the server MUST behave as if the AUTH=<> parameter was
- supplied. The server MAY, however, write the value of the AUTH
- parameter to a log file.
-
- If an AUTH=<> parameter was supplied, either explicitly or due to
- the requirement in the previous paragraph, then the server MUST
- supply the AUTH=<> parameter when relaying the message to any
- server which it has authenticated to using the AUTH extension.
-
- A server MAY treat expansion of a mailing list as a new
- submission, setting the AUTH parameter to the mailing list
- address or mailing list administration address when relaying the
- message to list subscribers.
-
- It is conforming for an implementation to be hard-coded to treat
- all clients as being insufficiently trusted. In that case, the
- implementation does nothing more than parse and discard
- syntactically valid AUTH parameters to the MAIL FROM command and
- supply AUTH=<> parameters to any servers to which it
- authenticates using the AUTH extension.
-
- Examples:
- C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com
- S: 250 OK
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Myers Standards Track [Page 5]
-
-RFC 2554 SMTP Authentication March 1999
-
-
-6. Error Codes
-
- The following error codes may be used to indicate various conditions
- as described.
-
- 432 A password transition is needed
-
- This response to the AUTH command indicates that the user needs to
- transition to the selected authentication mechanism. This typically
- done by authenticating once using the PLAIN authentication mechanism.
-
- 534 Authentication mechanism is too weak
-
- This response to the AUTH command indicates that the selected
- authentication mechanism is weaker than server policy permits for
- that user.
-
- 538 Encryption required for requested authentication mechanism
-
- This response to the AUTH command indicates that the selected
- authentication mechanism may only be used when the underlying SMTP
- connection is encrypted.
-
- 454 Temporary authentication failure
-
- This response to the AUTH command indicates that the authentication
- failed due to a temporary server failure.
-
- 530 Authentication required
-
- This response may be returned by any command other than AUTH, EHLO,
- HELO, NOOP, RSET, or QUIT. It indicates that server policy requires
- authentication in order to perform the requested action.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Myers Standards Track [Page 6]
-
-RFC 2554 SMTP Authentication March 1999
-
-
-7. Formal Syntax
-
- The following syntax specification uses the augmented Backus-Naur
- Form (BNF) notation as specified in [ABNF].
-
- Except as noted otherwise, all alphabetic characters are case-
- insensitive. The use of upper or lower case characters to define
- token strings is for editorial clarity only. Implementations MUST
- accept these strings in a case-insensitive fashion.
-
- UPALPHA = %x41-5A ;; Uppercase: A-Z
-
- LOALPHA = %x61-7A ;; Lowercase: a-z
-
- ALPHA = UPALPHA / LOALPHA ;; case insensitive
-
- DIGIT = %x30-39 ;; Digits 0-9
-
- HEXDIGIT = %x41-46 / DIGIT ;; hexidecimal digit (uppercase)
-
- hexchar = "+" HEXDIGIT HEXDIGIT
-
- xchar = %x21-2A / %x2C-3C / %x3E-7E
- ;; US-ASCII except for "+", "=", SPACE and CTL
-
- xtext = *(xchar / hexchar)
-
- AUTH_CHAR = ALPHA / DIGIT / "-" / "_"
-
- auth_type = 1*20AUTH_CHAR
-
- auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")]
- *(CRLF [base64]) CRLF
-
- auth_param = "AUTH=" xtext
- ;; The decoded form of the xtext MUST be either
- ;; an addr-spec or the two characters "<>"
-
- base64 = base64_terminal /
- ( 1*(4base64_CHAR) [base64_terminal] )
-
- base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
- ;; Case-sensitive
-
- base64_terminal = (2base64_char "==") / (3base64_char "=")
-
- continue_req = "334" SPACE [base64] CRLF
-
-
-
-
-Myers Standards Track [Page 7]
-
-RFC 2554 SMTP Authentication March 1999
-
-
- CR = %x0C ;; ASCII CR, carriage return
-
- CRLF = CR LF
-
- CTL = %x00-1F / %x7F ;; any ASCII control character and DEL
-
- LF = %x0A ;; ASCII LF, line feed
-
- SPACE = %x20 ;; ASCII SP, space
-
-
-
-
-8. References
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
- AUTHorize Extension for Simple Challenge/Response", RFC
- 2195, September 1997.
-
- [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
- Crocker, "SMTP Service Extensions", RFC 1869, November
- 1995.
-
- [ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status
- Notifications", RFC 1891, January 1996.
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [SASL] Myers, J., "Simple Authentication and Security Layer
- (SASL)", RFC 2222, October 1997.
-
- [SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC
- 2476, December 1998.
-
- [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
- 821, August 1982.
-
- [RFC822] Crocker, D., "Standard for the Format of ARPA Internet
- Text Messages", STD 11, RFC 822, August 1982.
-
-
-
-
-
-
-
-
-Myers Standards Track [Page 8]
-
-RFC 2554 SMTP Authentication March 1999
-
-
-9. Security Considerations
-
- Security issues are discussed throughout this memo.
-
- If a client uses this extension to get an encrypted tunnel through an
- insecure network to a cooperating server, it needs to be configured
- to never send mail to that server when the connection is not mutually
- authenticated and encrypted. Otherwise, an attacker could steal the
- client's mail by hijacking the SMTP connection and either pretending
- the server does not support the Authentication extension or causing
- all AUTH commands to fail.
-
- Before the SASL negotiation has begun, any protocol interactions are
- performed in the clear and may be modified by an active attacker.
- For this reason, clients and servers MUST discard any knowledge
- obtained prior to the start of the SASL negotiation upon completion
- of a SASL negotiation which results in a security layer.
-
- This mechanism does not protect the TCP port, so an active attacker
- may redirect a relay connection attempt to the submission port
- [SUBMIT]. The AUTH=<> parameter prevents such an attack from causing
- an relayed message without an envelope authentication to pick up the
- authentication of the relay client.
-
- A message submission client may require the user to authenticate
- whenever a suitable SASL mechanism is advertised. Therefore, it may
- not be desirable for a submission server [SUBMIT] to advertise a SASL
- mechanism when use of that mechanism grants the client no benefits
- over anonymous submission.
-
- This extension is not intended to replace or be used instead of end-
- to-end message signature and encryption systems such as S/MIME or
- PGP. This extension addresses a different problem than end-to-end
- systems; it has the following key differences:
-
- (1) it is generally useful only within a trusted enclave
-
- (2) it protects the entire envelope of a message, not just the
- message's body.
-
- (3) it authenticates the message submission, not authorship of the
- message content
-
- (4) it can give the sender some assurance the message was
- delivered to the next hop in the case where the sender
- mutually authenticates with the next hop and negotiates an
- appropriate security layer.
-
-
-
-
-Myers Standards Track [Page 9]
-
-RFC 2554 SMTP Authentication March 1999
-
-
- Additional security considerations are mentioned in the SASL
- specification [SASL].
-
-
-
-10. Author's Address
-
- John Gardiner Myers
- Netscape Communications
- 501 East Middlefield Road
- Mail Stop MV-029
- Mountain View, CA 94043
-
- EMail: jgmyers@netscape.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Myers Standards Track [Page 10]
-
-RFC 2554 SMTP Authentication March 1999
-
-
-11. Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Myers Standards Track [Page 11]
-
-
diff --git a/doc/src/rfc2683.txt b/doc/src/rfc2683.txt
@@ -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: leiba@watson.ibm.com
-
-
-
-
-
-Leiba Informational [Page 22]
-
-RFC 2683 IMAP4 Implementation Recommendations September 1999
-
-
-7. Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Leiba Informational [Page 23]
-
diff --git a/doc/src/rfc2821.txt b/doc/src/rfc2821.txt
@@ -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-
- part@domain": 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 <local-part@domain>
- local-part@domain
-
- 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 <jsmith@foo.com>
- 553-Harry Smith <hsmith@foo.com>
- 553 Melvin Smith <dweep@foo.com>
-
- or
-
- 553-Ambiguous; Possibilities
- 553- <jsmith@foo.com>
- 553- <hsmith@foo.com>
- 553 <dweep@foo.com>
-
- 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 "local-part@domain" 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 <Postel@isi.edu>
- S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
- S: 250 Sam Q. Smith <SQSmith@specific.generic.com>
-
- 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.,
- "<local-part@domain>", 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:<userx@y.foo.org>
- RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
-
- will normally be sent directly on to host d.bar.org with envelope
- commands
-
- MAIL FROM:<userx@y.foo.org>
- RCPT TO:<userc@d.bar.org>
-
- As provided in appendix C, xyz.com MAY also choose to relay the
- message to hosta.int, using the envelope commands
-
- MAIL FROM:<userx@y.foo.org>
- RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
-
- or to jkl.org, using the envelope commands
-
- MAIL FROM:<userx@y.foo.org>
- RCPT TO:<@jkl.org:userc@d.bar.org>
-
- 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:user@d>
-
- The notification message MUST be sent using:
-
- RCPT TO:<user@d>
-
- 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: klensin@research.att.com
-
-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:JOE@THREE", 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:<Smith@bar.com>
- S: 250 OK
- C: RCPT TO:<Jones@foo.com>
- S: 250 OK
- C: RCPT TO:<Green@foo.com>
- S: 550 No such user here
- C: RCPT TO:<Brown@foo.com>
-
-
-
-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:<Smith@bar.com>
- S: 250 OK
- C: RCPT TO:<Jones@foo.com>
- S: 250 OK
- C: RCPT TO:<Green@foo.com>
- 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:<JQP@bar.com>
- S: 250 OK
- C: RCPT TO:<@foo.com:Jones@XYZ.COM>
- 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 <JQP@bar.com>
- C: Subject: The Next Meeting of the Board
- C: To: Jones@xyz.com
- 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:JQP@bar.com>
- S: 250 OK
- C: RCPT TO:<Jones@XYZ.COM>
- 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 <JQP@bar.com>
- C: Subject: The Next Meeting of the Board
- C: To: Jones@xyz.com
- 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 <Admin.MRC@foo.com>
- C: SEND FROM:<EAK@bar.com>
- S: 250 OK
- C: RCPT TO:<Admin.MRC@foo.com>
- 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/src/rfc2822.txt b/doc/src/rfc2822.txt
@@ -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: presnick@qualcomm.com
-
-
-
-
-
-
-
-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 <jdoe@machine.example>
-To: Mary Smith <mary@example.net>
-Subject: Saying Hello
-Date: Fri, 21 Nov 1997 09:55:06 -0600
-Message-ID: <1234@local.machine.example>
-
-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 <jdoe@machine.example>
-Sender: Michael Jones <mjones@machine.example>
-To: Mary Smith <mary@example.net>
-Subject: Saying Hello
-Date: Fri, 21 Nov 1997 09:55:06 -0600
-Message-ID: <1234@local.machine.example>
-
-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" <john.q.public@example.com>
-To: Mary Smith <mary@x.test>, jdoe@example.org, Who? <one@y.test>
-Cc: <boss@nil.test>, "Giant; \"Big\" Box" <sysservices@example.net>
-Date: Tue, 1 Jul 2003 10:52:37 +0200
-Message-ID: <5678.21-Nov-1997@example.com>
-
-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 jdoe@example.org and boss@nil.test have no display names
- associated with them at all, and jdoe@example.org 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 <pete@silly.example>
-To: A Group:Chris Jones <c@a.test>,joe@where.test,John <jdoe@one.test>;
-Cc: Undisclosed recipients:;
-Date: Thu, 13 Feb 1969 23:32:54 -0330
-Message-ID: <testabcd.1234@silly.example>
-
-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 <jdoe@machine.example>
-To: Mary Smith <mary@example.net>
-Subject: Saying Hello
-Date: Fri, 21 Nov 1997 09:55:06 -0600
-Message-ID: <1234@local.machine.example>
-
-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 <mary@example.net>
-To: John Doe <jdoe@machine.example>
-Reply-To: "Mary Smith: Personal Account" <smith@home.example>
-Subject: Re: Saying Hello
-Date: Fri, 21 Nov 1997 10:01:10 -0600
-Message-ID: <3456@example.net>
-In-Reply-To: <1234@local.machine.example>
-References: <1234@local.machine.example>
-
-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" <smith@home.example>
-From: John Doe <jdoe@machine.example>
-Subject: Re: Saying Hello
-Date: Fri, 21 Nov 1997 11:00:00 -0600
-Message-ID: <abcd.1234@local.machine.tld>
-In-Reply-To: <3456@example.net>
-References: <1234@local.machine.example> <3456@example.net>
-
-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 <jdoe@machine.example>
-To: Mary Smith <mary@example.net>
-Subject: Saying Hello
-Date: Fri, 21 Nov 1997 09:55:06 -0600
-Message-ID: <1234@local.machine.example>
-
-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 <mary@example.net>
-Resent-To: Jane Brown <j-brown@other.example>
-Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800
-Resent-Message-ID: <78910@example.net>
-From: John Doe <jdoe@machine.example>
-To: Mary Smith <mary@example.net>
-Subject: Saying Hello
-Date: Fri, 21 Nov 1997 09:55:06 -0600
-Message-ID: <1234@local.machine.example>
-
-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 <mary@example.net>; 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 <jdoe@machine.example>
-To: Mary Smith <mary@example.net>
-Subject: Saying Hello
-Date: Fri, 21 Nov 1997 09:55:06 -0600
-Message-ID: <1234@local.machine.example>
-
-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>,
- joe@example.org,
- John <jdoe@one.test> (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: <testabcd.1234@silly.test>
-
-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 "joe@example.org,"; (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 <john.q.public@example.com>
-To: Mary Smith <@machine.tld:mary@example.net>, , jdoe@test . example
-Date: Tue, 1 Jul 2003 10:52:37 +0200
-Message-ID: <5678.21-Nov-1997@example.com>
-
-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 <jdoe@machine.example>
-To: Mary Smith <mary@example.net>
-Subject: Saying Hello
-Date: 21 Nov 97 09:55:06 GMT
-Message-ID: <1234@local.machine.example>
-
-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 <jdoe@machine(comment). example>
-To : Mary Smith
-__
- <mary@example.net>
-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/src/rfc2980.txt b/doc/src/rfc2980.txt
@@ -1,1515 +0,0 @@
-
-
-
-
-
-
-Network Working Group S. Barber
-Request for Comments: 2980 Academ Consulting Services
-Category: Informational October 2000
-
-
- Common NNTP Extensions
-
-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
-
- In this document, a number of popular extensions to the Network News
- Transfer Protocol (NNTP) protocol defined in RFC 977 are documented
- and discussed. While this document is not intended to serve as a
- standard of any kind, it will hopefully serve as a reference document
- for future implementers of the NNTP protocol. In the role, this
- document would hopefully create the possibility for some level of
- interoperability among implementations that make use of extensions.
-
-Introduction
-
- RFC 977 [1] defines the NNTP protocol and was released over a decade
- ago. Since then, NNTP has become one of the most popular protocols
- in use on the Internet. Many implementations of the protocol have
- been created on many different platforms and operating systems. With
- the growth in use of the protocol, work began on a revision to NNTP
- in 1991, but that work did not result in a new standard protocol
- specification. However, many ideas from that working group did find
- their way into many implementations of NNTP. Additionally, many
- other extensions, often created by newsreader authors, are also in
- use. This document will capture and define all known extensions to
- NNTP available in official NNTP server releases of some type as of
- this writing. Where possible, the server software first implementing
- a particular extension will be noted. It is the hope of the author
- that using this document in tandem with RFC 977 will limit the
- addition of new extensions that essentially do the same thing.
- Software developers may wish to use this document and others [2] as a
- resource for the development of new software.
-
-
-
-
-
-Barber Informational [Page 1]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
- This document does not specify an Internet Standard of any kind. It
- only attempts to document current practices. While this document may
- clarify some ambiguity in RFC 977, RFC 977 should be regarded as
- authoritative in all cases. There are some implementations that are
- not strictly RFC 977 compliant and where necessary, these deviations
- from the standard will be noted. This document does reflect the work
- of the IETF NNTP-EXT working group chaired by Ned Freed and Stan
- Barber.
-
- This document is provided to help implementers have a uniform source
- of information about extensions, however, it is important for any
- prospective implementer to understand that the extensions listed here
- are NOT part of any current standard for NNTP. In fact, some of the
- ones listed in this document should not be included in new NNTP
- implementations as they should no longer be used modern NNTP
- environments. Such commands should be considered historic and are
- documented as such in this document.
-
- Extensions fall into three categories: transport, newsreader and
- other. Transport extensions are additions to the NNTP specification
- that were made specifically to move news articles from one server to
- another server. Newsreader extensions are additions to the NNTP
- specification that were made to assist NNTP clients in selecting and
- retrieving news articles from servers. Other extensions to the NNTP
- specification are those which did not specifically fall into either
- of the other two categories. Examples of other extensions include
- authentication and time-of-day extensions. For each command, the
- format of section 3 of RFC 977 will be used.
-
-1. Transport Extensions
-
- A transport extension is one which is primarily used in inter-server
- communications. Following are the descriptions of each transport
- extension commands and the responses which will be returned by those
- commands.
-
- Each command is shown in upper case for clarity, although case is
- ignored in the interpretation of commands by the NNTP server. Any
- parameters are shown in lower case. A parameter shown in [square
- brackets] is optional. For example, [GMT] indicates that the
- triglyph GMT may present or omitted. A parameter that may be
- repeated is followed by an ellipsis.
-
-
-
-
-
-
-
-
-
-Barber Informational [Page 2]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
-1.1.1 The CHECK command
-
- CHECK <message-id>
-
- CHECK is used by a peer to discover if the article with the specified
- message-id should be sent to the server using the TAKETHIS command.
- The peer does not have to wait for a response from the server before
- sending the next command.
-
- From using the responses to the sequence of CHECK commands, a list of
- articles to be sent can be constructed for subsequent use by the
- TAKETHIS command.
-
- The use of the CHECK command for streaming is optional. Some
- implementations will directly use the TAKETHIS command and send all
- articles in the send queue on that peer for the server.
-
- On some implementations, the use of the CHECK command is not
- permitted when the server is in slave mode (via the SLAVE command).
-
- Responses that are of the form X3X must specify the message-id in the
- response.
-
-1.1.2. Responses
-
- 238 no such article found, please send it to me
- 400 not accepting articles
- 431 try sending it again later
- 438 already have it, please don't send it to me
- 480 Transfer permission denied
- 500 Command not understood
-
-1.2.1 The MODE STREAM command
-
- MODE STREAM
-
- MODE STREAM is used by a peer to indicate to the server that it would
- like to suspend the lock step conversational nature of NNTP and send
- commands in streams. This command should be used before TAKETHIS and
- CHECK. See the section on the commands TAKETHIS and CHECK for more
- details.
-
-1.2.2. Responses
-
- 203 Streaming is OK
- 500 Command not understood
-
-
-
-
-
-Barber Informational [Page 3]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
-1.3.1 The TAKETHIS command
-
- TAKETHIS <message-id>
-
- TAKETHIS is used to send articles to a server when in streaming mode.
- The entire article (header and body, in that sequence) is sent
- immediately after the peer sends the TAKETHIS command. The peer does
- not have to wait for a response from the server before sending the
- next command and the associated article.
-
- During transmission of the article, the peer should send the entire
- article, including header and body, in the manner specified for text
- transmission from the server. See RFC 977, Section 2.4.1 for
- details.
-
- Responses that are of the form X3X must specify the message-id in the
- response.
-
-1.3.2. Responses
-
- 239 article transferred ok
- 400 not accepting articles
- 439 article transfer failed
- 480 Transfer permission denied
- 500 Command not understood
-
-1.4.1 The XREPLIC command
-
- XREPLIC ggg:nnn[,ggg:nnn...]
-
- The XREPLIC command makes is possible to exactly duplicate the news
- spool structure of one server in another server. It first appeared
- in INN.
-
- This command works similarly to the IHAVE command as specified in RFC
- 977. The same response codes are used. The command line arguments
- consist of entries separated by a single comma. Each entry consists
- of a news group name, a colon, and an article number. If the server
- responds with a 335 response, the article should be filed in the news
- group(s) and article number(s) specified in the XREPLIC command line.
- If the server cannot do successfully install the article once it has
- accepted it, a 436 or 437 response code can be used to indicate the
- failure.
-
- This command should only be used when the receiving server is being
- fed by only one other server. It is likely that when used with
- servers that have multiple feeds that this command will frequently
- fail.
-
-
-
-Barber Informational [Page 4]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
- XREPLIC slaving has been deprecated in INN version 1.7.2 and later.
- INN now has the ability to slave servers via transparent means,
- simply by having the article's Xref header transferred. (In previous
- versions, this header was generated locally and stripped off on
- outgoing feeds.)
-
- It is likely that future versions of INN will no longer support
- XREPLIC.
-
-1.4.2. Responses
-
- 235 article transferred ok
- 335 send article to be transferred. End with <CR-LF>.<CR-LF>
- 435 article not wanted - do not send it
- 436 transfer failed - try again later
- 437 article rejected - do not try again
-
-2. Newsreader Extensions
-
- Newsreader extensions are those which are primarily used by
- newsreading clients. Following are the descriptions of each
- newsreader extension commands and the responses which will be
- returned by those commands.
-
- Each command is shown in upper case for clarity, although case is
- ignored in the interpretation of commands by the NNTP server. Any
- parameters are shown in lower case. A parameter shown in [square
- brackets] is optional. For example, [GMT] indicates that the
- triglyph GMT may present or omitted. A parameter that may be
- repeated is followed by an ellipsis. Mutually exclusive parameters
- are separated by a vertical bar (|) character. For example,
- ggg|<message-id> indicates that a group name or a <message-id> may
- be specified, but not both. Some parameters, notably <message-id>,
- is case specific. See RFC 1036 for these details.
-
- Also, certain commands make use of a pattern for selection of
- multiple news groups. The pattern in all cases is based on the
- wildmat [4] format introduced by Rich Salz in 1986. Arguments
- expected to be in wildmat format will be represented by the string
- wildmat. This format is discussed in detail in section 3.3 of this
- document.
-
-2.1.1 Extensions to the LIST command
-
- The original LIST command took no arguments in RFC 977 and returned
- the contents of the active file in a specific format. Since the
- original newsreaders made use of other information available in the
- news transport software in addition to the active file, extensions to
-
-
-
-Barber Informational [Page 5]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
- the LIST command were created to make that information available to
- NNTP newsreaders. There may be other extensions to the LIST command
- that simply return the contents of a file. This approach is
- suggested over the addition of over verbs. For example, LIST MOTD
- could be used instead of adding XMOTD.
-
-2.1.2 LIST ACTIVE
-
- LIST ACTIVE [wildmat]
-
- LIST ACTIVE is exactly the same as the LIST command specified in RFC
- 977. The responses and the format should exactly match the LIST
- command without arguments. If the optional matching parameter is
- specified, the list is limited to only the groups that match the
- pattern. Specifying a single group is usually very efficient for the
- server, and multiple groups may be specified by using wildmat
- patterns (described later in this document), not regular expressions.
- If nothing is matched an empty list is returned, not an error. This
- command first appeared in the UNIX reference version.
-
-2.1.3 LIST ACTIVE.TIMES
-
- LIST ACTIVE.TIMES
-
- The active.times file is maintained by some news transports systems
- to contain information about the when and who created a particular
- news group. The format of this file generally include three fields.
- The first field is the name of the news group. The second is the
- time when this group was created on this news server measured in
- seconds since January 1, 1970. The third is the email address of the
- entity that created the news group. When executed, the information
- is displayed following the 215 response. When display is completed,
- the server will send a period on a line by itself. If the
- information is not available, the server will return the 503 error
- response. This command first appeared in the UNIX reference version.
-
-2.1.3.1 Responses
-
- 215 information follows
- 503 program error, function not performed
-
-2.1.4 LIST DISTRIBUTIONS
-
- LIST DISTRIBUTIONS
-
- The distributions file is maintained by some news transport systems
- to contain information about valid values for the Distribution: line
- in a news article header and about what the values mean. Each line
-
-
-
-Barber Informational [Page 6]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
- contains two fields, the value and a short explanation on the meaning
- of the value. When executed, the information is displayed following
- the 215 response. When display is completed, the server will send a
- period on a line by itself. If the information is not available, the
- server will return the 503 error response. This command first
- appeared in the UNIX reference version.
-
-2.1.4.1 Responses
-
- 215 information follows
- 503 program error, function not performed
-
-2.1.5 LIST DISTRIB.PATS
-
- LIST DISTRIB.PATS
-
- The distrib.pats file is maintained by some news transport systems to
- contain default values for the Distribution: line in a news article
- header when posting to particular news groups. This information
- could be used to provide a default value for the Distribution: line
- in the header when posting an article. The information returned
- involves three fields separated by colons. The first column is a
- weight. The second is a group name or a pattern that can be used to
- match a group name in the wildmat format. The third is the value of
- the Distribution: line that should be used when the group name
- matches and the weight value is the highest. All this processing is
- done by the news posting client and not by the server itself. The
- server just provides this information to the client for it to use or
- ignore as it chooses. When executed, the information is displayed
- following the 215 response. When display is completed, the server
- will send a period on a line by itself. If the information is not
- available, the server will return the 503 error response. This
- command first appeared in INN.
-
-2.1.5.1 Responses
-
- 215 information follows
- 503 program error, function not performed
-
-2.1.6 LIST NEWSGROUPS
-
- LIST NEWSGROUPS [wildmat]
-
- The newsgroups file is maintained by some news transport systems to
- contain the name of each news group which is active on the server and
- a short description about the purpose of each news group. Each line
- in the file contains two fields, the news group name and a short
- explanation of the purpose of that news group. When executed, the
-
-
-
-Barber Informational [Page 7]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
- information is displayed following the 215 response. When display is
- completed, the server will send a period on a line by itself. If the
- information is not available, the server will return the 503
- response. If the optional matching parameter is specified, the list
- is limited to only the groups that match the pattern (no matching is
- done on the group descriptions). Specifying a single group is
- usually very efficient for the server, and multiple groups may be
- specified by using wildmat patterns (similar to file globbing), not
- regular expressions. If nothing is matched an empty list is
- returned, not an error.
-
- When the optional parameter is specified, this command is equivalent
- to the XGTITLE command, though the response code are different.
-
- 215 information follows
- 503 program error, function not performed
-
-2.1.7 LIST OVERVIEW.FMT
-
- LIST OVERVIEW.FMT
-
- The overview.fmt file is maintained by some news transport systems to
- contain the order in which header information is stored in the
- overview databases for each news group. When executed, news article
- header fields are displayed one line at a time in the order in which
- they are stored in the overview database [5] following the 215
- response. When display is completed, the server will send a period
- on a line by itself. If the information is not available, the server
- will return the 503 response.
-
- Please note that if the header has the word "full" (without quotes)
- after the colon, the header's name is prepended to its field in the
- output returned by the server.
-
- Many newsreaders work better if Xref: is one of the optional fields.
-
- It is STRONGLY recommended that this command be implemented in any
- server that implements the XOVER command. See section 2.8 for more
- details about the XOVER command.
-
-2.1.7.1 Responses
-
- 215 information follows
- 503 program error, function not performed
-
-
-
-
-
-
-
-Barber Informational [Page 8]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
-2.1.8 LIST SUBSCRIPTIONS
-
- LIST SUBSCRIPTIONS
-
- This command is used to get a default subscription list for new users
- of this server. The order of groups is significant.
-
- When this list is available, it is preceded by the 215 response and
- followed by a period on a line by itself. When this list is not
- available, the server returns a 503 response code.
-
-2.1.8.1 Responses
-
- 215 information follows
- 503 program error, function not performed
-
-2.2 LISTGROUP
-
- LISTGROUP [ggg]
-
- The LISTGROUP command is used to get a listing of all the article
- numbers in a particular news group.
-
- The optional parameter ggg is the name of the news group to be
- selected (e.g. "news.software.b"). A list of valid news groups may
- be obtained from the LIST command. If no group is specified, the
- current group is used as the default argument.
-
- The successful selection response will be a list of the article
- numbers in the group followed by a period on a line by itself.
-
- When a valid group is selected by means of this command, the
- internally maintained "current article pointer" is set to the first
- article in the group. If an invalid group is specified, the
- previously selected group and article remain selected. If an empty
- news group is selected, the "current article pointer" is in an
- indeterminate state and should not be used.
-
- Note that the name of the news group is not case-dependent. It must
- otherwise match a news group obtained from the LIST command or an
- error will result.
-
-2.2.1 Responses
-
- 211 list of article numbers follow
- 412 Not currently in newsgroup
- 502 no permission
-
-
-
-
-Barber Informational [Page 9]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
-2.3 MODE READER
-
- MODE READER is used by the client to indicate to the server that it
- is a news reading client. Some implementations make use of this
- information to reconfigure themselves for better performance in
- responding to news reader commands. This command can be contrasted
- with the SLAVE command in RFC 977, which was not widely implemented.
- MODE READER was first available in INN.
-
-2.3.1 Responses
-
- 200 Hello, you can post
- 201 Hello, you can't post
-
-2.4 XGTITLE
-
- XGTITLE [wildmat]
-
- The XGTITLE command is used to retrieve news group descriptions for
- specific news groups.
-
- This extension first appeared in ANU-NEWS, an NNTP implementation for
- DEC's VMS. The optional parameter is a pattern in wildmat format.
- When executed, a 282 response is given followed by lines that have
- two fields, the news group name (which matches the pattern in the
- argument) and a short explanation of the purpose of the news group.
- When no argument is specified, the default argument is the current
- group name. When display is completed, the server sends a period on
- a line by itself.
-
- Please note that this command and the LIST NEWSGROUP command provide
- the same functionality with different response codes.
-
- Since this command provides the same functionality as LIST NEWSGROUP
- it is suggested that this extension be deprecated and no longer be
- used in newsreading clients.
-
- Note that there is a conflict in one of the response codes from
- XGTITLE and some of the authentication extensions.
-
-2.5.1 Responses
-
- 481 Groups and descriptions unavailable
- 282 list of groups and descriptions follows
-
-
-
-
-
-
-
-Barber Informational [Page 10]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
-2.6 XHDR
-
- XHDR header [range|<message-id>]
-
- The XHDR command is used to retrieve specific headers from specific
- articles.
-
- The required parameter is the name of a header line (e.g. "subject")
- in a news group article. See RFC 1036 for a list of valid header
- lines. The optional range argument may be any of the following:
-
- an article number
- an article number followed by a dash to indicate
- all following
- an article number followed by a dash followed by
- another article number
-
- The optional message-id argument indicates a specific article. The
- range and message-id arguments are mutually exclusive. If no
- argument is specified, then information from the current article is
- displayed. Successful responses start with a 221 response followed
- by a the matched headers from all matched messages. Each line
- containing matched headers returned by the server has an article
- number (or message ID, if a message ID was specified in the command),
- then one or more spaces, then the value of the requested header in
- that article. Once the output is complete, a period is sent on a
- line by itself. If the optional argument is a message-id and no such
- article exists, the 430 error response is returned. If a range is
- specified, a news group must have been selected earlier, else a 412
- error response is returned. If no articles are in the range
- specified, a 420 error response is returned by the server. A 502
- response will be returned if the client only has permission to
- transfer articles.
-
- Some implementations will return "(none)" followed by a period on a
- line by itself if no headers match in any of the articles searched.
- Others return the 221 response code followed by a period on a line by
- itself.
-
- The XHDR command has been available in the UNIX reference
- implementation from its first release. However, until now, it has
- been documented only in the source for the server.
-
-
-
-
-
-
-
-
-
-Barber Informational [Page 11]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
-2.6.1 Responses
-
- 221 Header follows
- 412 No news group current selected
- 420 No current article selected
- 430 no such article
- 502 no permission
-
-2.7 XINDEX
-
- XINDEX ggg
-
- The XINDEX command is used to retrieve an index file in the format of
- originally created for use by the TIN [6] news reader.
-
- The required parameter ggg is the name of the news group to be
- selected (e.g. "news.software.b"). A list of valid news groups may
- be obtained from the LIST command.
-
- The successful selection response will return index file in the
- format used by the TIN news reader followed by a period on a line by
- itself.
-
- When a valid group is selected by means of this command, the
- internally maintained "current article pointer" is set to the first
- article in the group. If an invalid group is specified, the
- previously selected group and article remain selected. If an empty
- news group is selected, the "current article pointer" is in an
- indeterminate state and should not be used.
-
- Note that the name of the news group is not case-dependent. It must
- otherwise match a news group obtained from the LIST command or an
- error will result.
-
- The format of the tin-style index file is discussed in the
- documentation for the TIN newsreader. Since more recent versions of
- TIN support the news overview (NOV) format, it is recommended that
- this extension become historic and no longer be used in current
- servers or future implementations.
-
-2.7.1 Responses
-
- 218 tin-style index follows
- 418 no tin-style index is available for this news group
-
-
-
-
-
-
-
-Barber Informational [Page 12]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
-2.8 XOVER
-
- XOVER [range]
-
- The XOVER command returns information from the overview database for
- the article(s) specified. This command was originally suggested as
- part of the OVERVIEW work described in "The Design of a Common
- Newsgroup Overview Database for Newsreaders" by Geoff Collyer. This
- document is distributed in the Cnews distribution. The optional
- range argument may be any of the following:
-
- an article number
- an article number followed by a dash to indicate
- all following
- an article number followed by a dash followed by
- another article number
-
- If no argument is specified, then information from the current
- article is displayed. Successful responses start with a 224 response
- followed by the overview information for all matched messages. Once
- the output is complete, a period is sent on a line by itself. If no
- argument is specified, the information for the current article is
- returned. A news group must have been selected earlier, else a 412
- error response is returned. If no articles are in the range
- specified, a 420 error response is returned by the server. A 502
- response will be returned if the client only has permission to
- transfer articles.
-
- Each line of output will be formatted with the article number,
- followed by each of the headers in the overview database or the
- article itself (when the data is not available in the overview
- database) for that article separated by a tab character. The
- sequence of fields must be in this order: subject, author, date,
- message-id, references, byte count, and line count. Other optional
- fields may follow line count. Other optional fields may follow line
- count. These fields are specified by examining the response to the
- LIST OVERVIEW.FMT command. Where no data exists, a null field must
- be provided (i.e. the output will have two tab characters adjacent to
- each other). Servers should not output fields for articles that have
- been removed since the XOVER database was created.
-
- The LIST OVERVIEW.FMT command should be implemented if XOVER is
- implemented. A client can use LIST OVERVIEW.FMT to determine what
- optional fields and in which order all fields will be supplied by
- the XOVER command. See Section 2.1.7 for more details about the LIST
- OVERVIEW.FMT command.
-
-
-
-
-
-Barber Informational [Page 13]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
- Note that any tab and end-of-line characters in any header data that
- is returned will be converted to a space character.
-
-2.8.1 Responses
-
- 224 Overview information follows
- 412 No news group current selected
- 420 No article(s) selected
- 502 no permission
-
-2.9 XPAT
-
- XPAT header range|<message-id> pat [pat...]
-
- The XPAT command is used to retrieve specific headers from specific
- articles, based on pattern matching on the contents of the header.
- This command was first available in INN.
-
- The required header parameter is the name of a header line (e.g.
- "subject") in a news group article. See RFC 1036 for a list of valid
- header lines. The required range argument may be any of the
- following:
-
- an article number
- an article number followed by a dash to indicate
- all following
- an article number followed by a dash followed by
- another article number
-
- The required message-id argument indicates a specific article. The
- range and message-id arguments are mutually exclusive. At least one
- pattern in wildmat must be specified as well. If there are
- additional arguments the are joined together separated by a single
- space to form one complete pattern. Successful responses start with
- a 221 response followed by a the headers from all messages in which
- the pattern matched the contents of the specified header line. This
- includes an empty list. Once the output is complete, a period is
- sent on a line by itself. If the optional argument is a message-id
- and no such article exists, the 430 error response is returned. A
- 502 response will be returned if the client only has permission to
- transfer articles.
-
-2.9.1 Responses
-
- 221 Header follows
- 430 no such article
- 502 no permission
-
-
-
-
-Barber Informational [Page 14]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
-2.10 The XPATH command
-
- XPATH <message-id>
-
- The XPATH command is used to determine the filenames in which an
- article is filed. It first appeared in INN.
-
- The required parameter message-id is the message id of an article as
- shown in that article's message-id header. According to RFC 1036
- [3], all message ids for all articles within the netnews environment
- are unique, but articles may be crossposted to multiple groups. The
- response to an XPATH command will include a listing of all filenames
- in which an article is stored separated by spaces or a response
- indicating that no article with the specified message-id exists. The
- returned data is only useful if the news client knows the
- implementation details of the server. Because of this, it is
- recommended that client avoid using this command.
-
-2.10.1 Responses
-
- 223 path1[ path2 ...]
- 430 no such article on server
-
-2.11 The XROVER command
-
- XROVER [range]
-
- The XROVER command returns reference information from the overview
- database for the article(s) specified. This command first appeared
- in the Unix reference implementation. The optional range argument
- may be any of the following:
-
- an article number
- an article number followed by a dash to indicate
- all following
- an article number followed by a dash followed by
- another article number
-
- Successful responses start with a 224 response followed by the
- contents of reference information for all matched messages. Once the
- output is complete, a period is sent on a line by itself. If no
- argument is specified, the information for the current article is
- returned. A news group must have been selected earlier, else a 412
- error response is returned. If no articles are in the range
- specified, a 420 error response is returned by the server. A 502
- response will be returned if the client only has permission to
- transfer articles.
-
-
-
-
-Barber Informational [Page 15]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
- The output will be formatted with the article number, followed by the
- contents of the References: line for that article, but does not
- contain the field name itself.
-
- This command provides the same basic functionality as using the XHDR
- command and "references" as the header argument.
-
-2.11.1 Responses
-
- 224 Overview information follows
- 412 No news group current selected
- 420 No article(s) selected
- 502 no permission
-
-2.12 XTHREAD
-
- XTHREAD [DBINIT|THREAD]
-
- The XTHREAD command is used to retrieve threading information
- in format of originally created for use by the TRN [6] news
- reader.
-
- The command XTHREAD DBINIT may be issued prior to entering
- any groups to see if a thread database exists. If it does,
- the database's byte order and version number are returned
- as binary data.
-
- If no parameter is given, XTHREAD THREAD is assumed.
-
- To use XTHREAD THREAD, a news group must have been selected
- earlier, else a 412 error response is returned.
-
- A 502 response will be returned if the client only has
- permission to transfer articles. A 503 response is returned
- if the threading files are not available.
-
- The format of the trn-style thread format is discussed in
- the documentation for the TRN newsreader. Since more recent
- versions of TRN support the news overview (NOV) format, it
- is recommended that this extension become historic and no
- longer be used in current servers or future implementations.
-
-2.12.1 Responses
-
- 288 Binary data to follow
- 412 No newsgroup current selected
- 502 No permission
- 503 program error, function not performed
-
-
-
-Barber Informational [Page 16]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
-3. Other Extensions
-
-3.1 AUTHINFO
-
- AUTHINFO is used to inform a server about the identity of a user of
- the server. In all cases, clients must provide this information when
- requested by the server. Servers are not required to accept
- authentication information that is volunteered by the client.
- Clients must accommodate servers that reject any authentication
- information volunteered by the client.
-
- There are three forms of AUTHINFO in use. The original version, an
- NNTP v2 revision called AUTHINFO SIMPLE and a more recent version
- which is called AUTHINFO GENERIC.
-
-3.1.1 Original AUTHINFO
-
- AUTHINFO USER username
- AUTHINFO PASS password
-
- The original AUTHINFO is used to identify a specific entity to the
- server using a simple username/password combination. It first
- appeared in the UNIX reference implementation.
-
- When authorization is required, the server will send a 480 response
- requesting authorization from the client. The client must enter
- AUTHINFO USER followed by the username. Once sent, the server will
- cache the username and may send a 381 response requesting the
- password associated with that username. Should the server request a
- password using the 381 response, the client must enter AUTHINFO PASS
- followed by a password and the server will then check the
- authentication database to see if the username/password combination
- is valid. If the combination is valid or if no password is required,
- the server will return a 281 response. The client should then retry
- the original command to which the server responded with the 480
- response. The command should then be processed by the server
- normally. If the combination is not valid, the server will return a
- 502 response.
-
- Clients must provide authentication when requested by the server. It
- is possible that some implementations will accept authentication
- information at the beginning of a session, but this was not the
- original intent of the specification. If a client attempts to
- reauthenticate, the server may return 482 response indicating that
- the new authentication data is rejected by the server. The 482 code
- will also be returned when the AUTHINFO commands are not entered in
- the correct sequence (like two AUTHINFO USERs in a row, or AUTHINFO
- PASS preceding AUTHINFO USER).
-
-
-
-Barber Informational [Page 17]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
- All information is passed in cleartext.
-
- When authentication succeeds, the server will create an email address
- for the client from the user name supplied in the AUTHINFO USER
- command and the hostname generated by a reverse lookup on the IP
- address of the client. If the reverse lookup fails, the IP address,
- represented in dotted-quad format, will be used. Once authenticated,
- the server shall generate a Sender: line using the email address
- provided by authentication if it does not match the client-supplied
- From: line. Additionally, the server should log the event, including
- the email address. This will provide a means by which subsequent
- statistics generation can associate newsgroup references with unique
- entities - not necessarily by name.
-
-3.1.1.1 Responses
-
- 281 Authentication accepted
- 381 More authentication information required
- 480 Authentication required
- 482 Authentication rejected
- 502 No permission
-
-3.1.2 AUTHINFO SIMPLE
-
- AUTHINFO SIMPLE
- user password
-
- This version of AUTHINFO was part of a proposed NNTP V2
- specification, which was started in 1991 but never completed, and is
- implemented in some servers and clients. It is a refinement of the
- original AUTHINFO and provides the same basic functionality, but the
- sequence of commands is much simpler.
-
- When authorization is required, the server sends a 450 response
- requesting authorization from the client. The client must enter
- AUTHINFO SIMPLE. If the server will accept this form of
- authentication, the server responds with a 350 response. The client
- must then send the username followed by one or more space characters
- followed by the password. If accepted, the server returns a 250
- response and the client should then retry the original command to
- which the server responded with the 450 response. The command should
- then be processed by the server normally. If the combination is not
- valid, the server will return a 452 response.
-
- Note that the response codes used here were part of the proposed NNTP
- V2 specification and are violations of RFC 977. It is recommended
- that this command not be implemented, but use either or both of the
- other forms of AUTHINFO if such functionality if required.
-
-
-
-Barber Informational [Page 18]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
-3.1.2.1 Responses
-
- 250 Authorization accepted
- 350 Continue with authorization sequence
- 450 Authorization required for this command
- 452 Authorization rejected
-
-3.1.3 AUTHINFO GENERIC
-
- AUTHINFO GENERIC authenticator arguments...
-
- AUTHINFO GENERIC is used to identify a specific entity to the server
- using arbitrary authentication or identification protocols. The
- desired protocol is indicated by the authenticator parameter, and any
- number of parameters can be passed to the authenticator.
-
- When authorization is required, the server will send a 480 response
- requesting authorization from the client. The client should enter
- AUTHINFO GENERIC followed by the authenticator name, and the
- arguments if any. The authenticator and arguments must not contain
- the sequence "..".
-
- The server will attempt to engage the server end authenticator,
- similarly, the client should engage the client end authenticator.
- The server end authenticator will then initiate authentication using
- the NNTP sockets (if appropriate for that authentication protocol),
- using the protocol specified by the authenticator name. These
- authentication protocols are not included in this document, but are
- similar in structure to those referenced in RFC 1731 [8] for the
- IMAP-4 protocol.
-
- If the server returns 501, this means that the authenticator
- invocation was syntactically incorrect, or that AUTHINFO GENERIC is
- not supported. The client should retry using the AUTHINFO USER
- command.
-
- If the requested authenticator capability is not found, the server
- returns the 503 response code.
-
- If there is some other unspecified server program error, the server
- returns the 500 response code.
-
- The authenticators converse using their protocol until complete. If
- the authentication succeeds, the server authenticator will terminate
- with a 281, and the client can continue by reissuing the command that
- prompted the 380. If the authentication fails, the server will
- respond with a 502.
-
-
-
-
-Barber Informational [Page 19]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
- The client must provide authentication when requested by the server.
- The server may request authentication at any time. Servers may
- request authentication more than once during a single session.
-
- When the server authenticator completes, it provides to the server
- (by a mechanism herein undefined) the email address of the user, and
- potentially what the user is allowed to access. Once authenticated,
- the server shall generate a Sender: line using the email address
- provided by the authenticator if it does not match the user-supplied
- From: line. Additionally, the server should log the event, including
- the user's authenticated email address (if available). This will
- provide a means by which subsequent statistics generation can
- associate newsgroup references with unique entities - not necessarily
- by name.
-
- Some implementations make it possible to obtain a list of
- authentication procedures available by sending the server AUTHINFO
- GENERIC with no arguments. The server then returns a list of
- supported mechanisms followed by a period on a line by itself.
-
-3.1.3.1 Responses
-
- 281 Authentication succeeded
- 480 Authentication required
- 500 Command not understood
- 501 Command not supported
- 502 No permission
- 503 Program error, function not performed
- nnn authenticator-specific protocol.
-
-3.2 DATE
-
- DATE
-
- The first NNTP working group discussed and proposed a syntax for this
- command to help clients find out the current time from the server's
- perspective. At the time this command was discussed (1991-1992), the
- Network Time Protocol [9] (NTP) was not yet in wide use and there was
- also some concern that small systems may not be able to make
- effective use of NTP.
-
- This command returns a one-line response code of 111 followed by the
- GMT date and time on the server in the form YYYYMMDDhhmmss.
-
-3.2.1 Responses
-
- 111 YYYYMMDDhhmmss
-
-
-
-
-Barber Informational [Page 20]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
-3.3 The WILDMAT format
-
- The WILDMAT format was first developed by Rich Salz based on the
- format used in the UNIX "find" command to articulate file names. It
- was developed to provide a uniform mechanism for matching patterns in
- the same manner that the UNIX shell matches filenames. Patterns are
- implicitly anchored at the beginning and end of each string when
- testing for a match. There are five pattern matching operations
- other than a strict one-to-one match between the pattern and the
- source to be checked for a match. The first is an asterisk (*) to
- match any sequence of zero or more characters. The second is a
- question mark (?) to match any single character. The third specifies
- a specific set of characters. The set is specified as a list of
- characters, or as a range of characters where the beginning and end
- of the range are separated by a minus (or dash) character, or as any
- combination of lists and ranges. The dash can also be included in
- the set as a character it if is the beginning or end of the set.
- This set is enclosed in square brackets. The close square bracket
- (]) may be used in a set if it is the first character in the set.
- The fourth operation is the same as the logical not of the third
- operation and is specified the same way as the third with the
- addition of a caret character (^) at the beginning of the test string
- just inside the open square bracket. The final operation uses the
- backslash character to invalidate the special meaning of the a open
- square bracket ([), the asterisk, backslash or the question mark.
- Two backslashes in sequence will result in the evaluation of the
- backslash as a character with no special meaning.
-
-3.3.1 Examples
-
- a. [^]-] -- matches any single character other than a close square
- bracket or a minus sign/dash.
-
- b. *bdc -- matches any string that ends with the string "bdc"
- including the string "bdc" (without quotes).
-
- c. [0-9a-zA-Z] -- matches any single printable alphanumeric ASCII
- character.
-
- d. a??d -- matches any four character string which begins
- with a and ends with d.
-
-
-
-
-
-
-
-
-
-
-Barber Informational [Page 21]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
-3.4 Additional Headers
-
- Many NNTP implementations add headers to Usenet articles when then
- are POSTed via NNTP. These headers are discussed in this section.
- None of these headers conflict with those specified in RFC 1036 and
- should be passed unchanged by Usenet transports conforming to RFC
- 1036.
-
-3.4.1 NNTP-Posting-Host
-
- This line is added to the header of a posted article by the server.
- The contents of the header is either the IP address or the fully
- qualified domain name of the client host posting the article. The
- fully qualified domain name should be determined by doing a reverse
- lookup in the DNS on the IP address of the client. If the client
- article contains this line, it is removed by the server before
- acceptance of the article by the Usenet transport system.
-
- This header provides some idea of the actual host posting the article
- as opposed to information in the Sender or From lines that may be
- present in the article. This is not a fool-proof methodology since
- reverse lookups in the DNS are vulnerable to certain types of
- spoofing, but such discussions are outside the scope of this
- document.
-
-3.4.2 X-Newsreader and others
-
-
- There are other lines that are added by clients as well. Most of
- these indicate the type of newsreader software that is posting the
- article.
-
-4.0 Common Implementation Issues
-
- Many NNTP implementations do not follow the specifications in RFC
- 977. In this section, some common implementation issues are
- summarized.
-
-4.1 The Response to the LIST command
-
- RFC 977 says that the fourth field of the "list of valid newsgroups
- associated information" returned must be "either 'y' or 'n'
- indicating whether posting to this newsgroup is allowed ('y') or
- prohibited ('n'). Most implementations simply output the exact
- contents of the transport system's active newsgroup list. For more
- implementations, the fourth field usually has more values that 'y' or
- 'n'.
-
-
-
-
-Barber Informational [Page 22]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
-4.2 The Required Headers in an Article and the POST command
-
- RFC 977 notes in section 3.10.1 that articles presented "should
- include all required header lines." In fact, modern implementations
- only require From, Subject, and Newsgroups header lines and will
- supply the rest; further, many implementers believe that it is best
- for clients to generate as few headers as possible, since clients
- often do not format other headers correctly.
-
- This implementation behavior is consistent with both Bnews and Cnews
- which would supply missing headers for articles directly submitted to
- them.
-
-4.3 Article Numbering
-
- RFC 977 does not directly address the rules concerning articles
- number. However, the current practice is simple: article numbers are
- monotonically increasing, articles may disappear, and therefore the
- high and low water marks returned in a GROUP command should be
- treated as maximum minima, and minimum maxima, respectively.
-
-4.4 Availability of commands defined in RFC 977
-
- Some implementations permit administrators to disable commands
- defined RFC 977. Some implementations have some set of commands
- disabled by default. This means that client implementations cannot
- depend on the availability of the disabled set of commands. This
- increases the complexity of the client and does not encourage
- implementors to optimize the implementation of commands that don't
- perform well.
-
- NEWNEWS is one of the commands frequently disabled.
-
-4.5 The Distribution header and NEWNEWS
-
- In section 12.4 of RFC 977, the optional distributions argument is
- described. This argument, according to RFC 977, would limit the
- responses to articles that were in newsgroups with prefixes that
- matched the optional distributions argument.
-
- Some implementations implement this by matching the Distributions
- header in articles to the distribution argument. Others do the match
- against segments of the newsgroup's name.
-
- This variation is probably best explained by the evolution of the
- USENET article format. At the time RFC 977 was specified, the
- newsgroup name defined how the group was distributed throughout
- USENET. RFC 1036 changed this convention. So, those that are
-
-
-
-Barber Informational [Page 23]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
- strictly implementing RFC 977 would match the newsgroup name prefix
- against the distribution argument and only display matches. Those
- that implement against the intent of the command (as modified by the
- redefinition of the article format)would match the Distributions
- header against the distribution argument and only display those
- matches.
-
-5.0 Further Work
-
- With the continued use of NNTP on the Internet, there remains an
- interest in creating an optimized transport protocol for server-to-
- server transfers and an optimized client protocol for client-to-
- server interactions. There is also considerable interest is building
- better mechanisms to provide audit information on which news groups
- are being read by which users.
-
- An IETF working group has been formed and it is the hope of this
- author that these issues will be addressed in that forum.
-
-6.0 Security Considerations
-
- The use of the AUTHINFO is optional. This command as documented has
- a number of security implications. In the original and simple forms,
- all passwords are passed in plaintext and could be discovered by
- various forms of network or system surveillance. The AUTHINFO
- GENERIC command has the potential for the same problems if a
- mechanism is used that also passes cleartext passwords. RFC 1731 [8]
- discusses these issues in greater detail.
-
-7.0 References
-
- [1] Kantor, B and P. Lapsley, "Network News Transfer Protocol", RFC
- 977, February 1986.
-
- [2] Limoncelli, Tom, "Read This Before You Write a Newsreader",
- http://mars.superlink.net/tal/news-software-authors.html, June,
- 1996.
-
- [3] Horton, M. and R. Adams, "Standard for interchange of USENET
- messages", RFC 1036, December 1987.
-
- [4] Salz, Rich, Manual Page for wildmat(3) from the INN 1.4
- distribution, UUNET Technologies, Revision 1.10, April, 1992.
-
- [5] Robertson, Rob, "FAQ: Overview database / NOV General
- Information", ftp://ftp.uu.net/networking/news/nntp/inn/faq-
- nov.Z, January, 1995.
-
-
-
-
-Barber Informational [Page 24]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
- [6] Lea, Iain, "FAQ about the TIN newsreader",
- http://www.cs.unca.edu/~davidson/handouts/tinfaq.html
-
- [7] Kappesser, Peter, "[news.software.readers] trn newsreader FAQ",
- 2 parts, ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/news/
- software/readers/%5Bnews.software.readers%5D_trn_newsreader
- _FAQ%2C_part_1%3A_Basics and ftp://rtfm.mit.edu/pub/usenet-by
- -hierarchy/news/software/readers/%5Bnews.software.readers
- %5D_trn_news-reader_FAQ%2C_part_2%3A_Advanced, February, 1995.
-
- [8] Meyers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
- December 1994.
-
- [9] Mills, D., "Network Time Protocol (Version 3), Specification,
- Implementation and Analysis", RFC 1305, March 1992.
-
-8.0 Notes
-
- DEC is a registered trademark of Compaq Computer Corporation. UNIX
- is a registered trademark of The Open Group. VMS is a registered
- trademark of Compaq Computer Corporation.
-
-9.0 Acknowledgments
-
- The author gratefully acknowledges the comments and additional
- information provided by the following individuals:
-
- Wayne Davison <davison@armory.com>
- Chris Lewis <clewis@bnr.ca>
- Tom Limoncelli <tal@lucent.com>
- Eric Schnoebelen <eric@egsner.cirr.com>
- Rich Salz <rsalz@osf.org>
-
- This work was precipitated by the work of various newsreader authors
- and newsserver authors which includes those listed below:
-
- Rick Adams -- Original author of the NNTP extensions to the RN
- newsreader and last maintainer of Bnews
- Stan Barber -- Original author of the NNTP extensions to the
- newsreaders that are part of Bnews.
- Geoff Collyer -- Original author of the OVERVIEW database proposal and
- one of the original authors of CNEWS
- Dan Curry -- Original author of the xvnews newsreader
- Wayne Davison -- Author of the first threading extensions to the
- RN newsreader (commonly called TRN).
- Geoff Huston -- Original author of ANU NEWS
-
-
-
-
-
-Barber Informational [Page 25]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
- Phil Lapsey -- Original author of the UNIX reference
- implementation
- Iain Lea -- Original maintainer of the TIN newsreader
- Chris Lewis -- First known implementor of the AUTHINFO GENERIC
- extension
- Rich Salz -- Original author of INN
- Henry Spencer -- One of the original authors of CNEWS
- Kim Storm -- Original author of the NN newsreader
-
-10.0 Author's Address
-
- Stan Barber
- P.O. Box 300481
- Houston, Texas, 77230
-
- EMail: sob@academ.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Barber Informational [Page 26]
-
-RFC 2980 Common NNTP Extensions October 2000
-
-
-11.0 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Barber Informational [Page 27]
-
diff --git a/doc/src/rfc3156.txt b/doc/src/rfc3156.txt
@@ -1,843 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Elkins
-Request for Comments: 3156 Network Associates, Inc.
-Updates: 2015 D. Del Torto
-Category: Standards Track CryptoRights Foundation
- R. Levien
- University of California at Berkeley
- T. Roessler
- August 2001
-
-
- MIME Security with OpenPGP
-
-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 how the OpenPGP Message Format can be used to
- provide privacy and authentication using the Multipurpose Internet
- Mail Extensions (MIME) security content types described in RFC 1847.
-
-1. Introduction
-
- Work on integrating PGP (Pretty Good Privacy) with MIME [3]
- (including the since withdrawn "application/pgp" content type) prior
- to RFC 2015 suffered from a number of problems, the most significant
- of which is the inability to recover signed message bodies without
- parsing data structures specific to PGP. RFC 2015 makes use of the
- elegant solution proposed in RFC 1847, which defines security
- multipart formats for MIME. The security multiparts clearly separate
- the signed message body from the signature, and have a number of
- other desirable properties. This document revises RFC 2015 to adopt
- the integration of PGP and MIME to the needs which emerged during the
- work on the OpenPGP specification.
-
- This document defines three content types for implementing security
- and privacy with OpenPGP: "application/pgp-encrypted",
- "application/pgp-signature" and "application/pgp-keys".
-
-
-
-
-Elkins, et al. Standards Track [Page 1]
-
-RFC 3156 MIME Security with OpenPGP August 2001
-
-
- 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. OpenPGP data formats
-
- OpenPGP implementations can generate either ASCII armor (described in
- [1]) or 8-bit binary output when encrypting data, generating a
- digital signature, or extracting public key data. The ASCII armor
- output is the REQUIRED method for data transfer. This allows those
- users who do not have the means to interpret the formats described in
- this document to be able to extract and use the OpenPGP information
- in the message.
-
- When the amount of data to be transmitted requires that it be sent in
- many parts, the MIME message/partial mechanism SHOULD be used rather
- than the multi-part ASCII armor OpenPGP format.
-
-3. Content-Transfer-Encoding restrictions
-
- Multipart/signed and multipart/encrypted are to be treated by agents
- as opaque, meaning that the data is not to be altered in any way [2],
- [7]. However, many existing mail gateways will detect if the next
- hop does not support MIME or 8-bit data and perform conversion to
- either Quoted-Printable or Base64. This presents serious problems
- for multipart/signed, in particular, where the signature is
- invalidated when such an operation occurs. For this reason all data
- signed according to this protocol MUST be constrained to 7 bits (8-
- bit data MUST be encoded using either Quoted-Printable or Base64).
- Note that this also includes the case where a signed object is also
- encrypted (see section 6). This restriction will increase the
- likelihood that the signature will be valid upon receipt.
-
- Additionally, implementations MUST make sure that no trailing
- whitespace is present after the MIME encoding has been applied.
-
- Note: In most cases, trailing whitespace can either be removed, or
- protected by applying an appropriate content-transfer-encoding.
- However, special care must be taken when any header lines - either
- in MIME entity headers, or in embedded RFC 822 headers - are
- present which only consist of whitespace: Such lines must be
- removed entirely, since replacing them by empty lines would turn
- them into header delimiters, and change the semantics of the
- message. The restrictions on whitespace are necessary in order to
- make the hash calculated invariant under the text and binary mode
- signature mechanisms provided by OpenPGP [1]. Also, they help to
- avoid compatibility problems with PGP implementations which
- predate the OpenPGP specification.
-
-
-
-Elkins, et al. Standards Track [Page 2]
-
-RFC 3156 MIME Security with OpenPGP August 2001
-
-
- Note: If any line begins with the string "From ", it is strongly
- suggested that either the Quoted-Printable or Base64 MIME encoding
- be applied. If Quoted-Printable is used, at least one of the
- characters in the string should be encoded using the hexadecimal
- coding rule. This is because many mail transfer and delivery
- agents treat "From " (the word "from" followed immediately by a
- space character) as the start of a new message and thus insert a
- right angle-bracket (>) in front of any line beginning with
- "From " to distinguish this case, invalidating the signature.
-
- Data that is ONLY to be encrypted is allowed to contain 8-bit
- characters and trailing whitespace and therefore need not undergo the
- conversion to a 7bit format, and the stripping of whitespace.
-
- Implementor's note: It cannot be stressed enough that applications
- using this standard follow MIME's suggestion that you "be
- conservative in what you generate, and liberal in what you
- accept." In this particular case it means it would be wise for an
- implementation to accept messages with any content-transfer-
- encoding, but restrict generation to the 7-bit format required by
- this memo. This will allow future compatibility in the event the
- Internet SMTP framework becomes 8-bit friendly.
-
-4. OpenPGP encrypted data
-
- Before OpenPGP encryption, the data is written in MIME canonical
- format (body and headers).
-
- OpenPGP encrypted data is denoted by the "multipart/encrypted"
- content type, described in [2], and MUST have a "protocol" parameter
- value of "application/pgp-encrypted". Note that the value of the
- parameter MUST be enclosed in quotes.
-
- The multipart/encrypted MIME body MUST consist of exactly two body
- parts, the first with content type "application/pgp-encrypted". This
- body contains the control information. A message complying with this
- standard MUST contain a "Version: 1" field in this body. Since the
- OpenPGP packet format contains all other information necessary for
- decrypting, no other information is required here.
-
- The second MIME body part MUST contain the actual encrypted data. It
- MUST be labeled with a content type of "application/octet-stream".
-
- Example message:
-
- From: Michael Elkins <elkins@aero.org>
- To: Michael Elkins <elkins@aero.org>
- Mime-Version: 1.0
-
-
-
-Elkins, et al. Standards Track [Page 3]
-
-RFC 3156 MIME Security with OpenPGP August 2001
-
-
- Content-Type: multipart/encrypted; boundary=foo;
- protocol="application/pgp-encrypted"
-
- --foo
- Content-Type: application/pgp-encrypted
-
- Version: 1
-
- --foo
- Content-Type: application/octet-stream
-
- -----BEGIN PGP MESSAGE-----
- Version: 2.6.2
-
- hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
- eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
- g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
- AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
- 1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
- =zzaA
- -----END PGP MESSAGE-----
-
- --foo--
-
-5. OpenPGP signed data
-
- OpenPGP signed messages are denoted by the "multipart/signed" content
- type, described in [2], with a "protocol" parameter which MUST have a
- value of "application/pgp-signature" (MUST be quoted).
-
- The "micalg" parameter for the "application/pgp-signature" protocol
- MUST contain exactly one hash-symbol of the format "pgp-<hash-
- identifier>", where <hash-identifier> identifies the Message
- Integrity Check (MIC) algorithm used to generate the signature.
- Hash-symbols are constructed from the text names registered in [1] or
- according to the mechanism defined in that document by converting the
- text name to lower case and prefixing it with the four characters
- "pgp-".
-
- Currently defined values are "pgp-md5", "pgp-sha1", "pgp-ripemd160",
- "pgp-md2", "pgp-tiger192", and "pgp-haval-5-160".
-
- The multipart/signed body MUST consist of exactly two parts. The
- first part contains the signed data in MIME canonical format,
- including a set of appropriate content headers describing the data.
-
- The second body MUST contain the OpenPGP digital signature. It MUST
- be labeled with a content type of "application/pgp-signature".
-
-
-
-Elkins, et al. Standards Track [Page 4]
-
-RFC 3156 MIME Security with OpenPGP August 2001
-
-
- Note: Implementations can either generate "signatures of a
- canonical text document" or "signatures of a binary document", as
- defined in [1]. The restrictions on the signed material put forth
- in section 3 and in this section will make sure that the various
- MIC algorithm variants specified in [1] and [5] will all produce
- the same result.
-
- When the OpenPGP digital signature is generated:
-
- (1) The data to be signed MUST first be converted to its content-
- type specific canonical form. For text/plain, this means
- conversion to an appropriate character set and conversion of
- line endings to the canonical <CR><LF> sequence.
-
- (2) An appropriate Content-Transfer-Encoding is then applied; see
- section 3. In particular, line endings in the encoded data
- MUST use the canonical <CR><LF> sequence where appropriate
- (note that the canonical line ending may or may not be present
- on the last line of encoded data and MUST NOT be included in
- the signature if absent).
-
- (3) MIME content headers are then added to the body, each ending
- with the canonical <CR><LF> sequence.
-
- (4) As described in section 3 of this document, any trailing
- whitespace MUST then be removed from the signed material.
-
- (5) As described in [2], the digital signature MUST be calculated
- over both the data to be signed and its set of content headers.
-
- (6) The signature MUST be generated detached from the signed data
- so that the process does not alter the signed data in any way.
-
- Note: The accepted OpenPGP convention is for signed data to end
- with a <CR><LF> sequence. Note that the <CR><LF> sequence
- immediately preceding a MIME boundary delimiter line is considered
- to be part of the delimiter in [3], 5.1. Thus, it is not part of
- the signed data preceding the delimiter line. An implementation
- which elects to adhere to the OpenPGP convention has to make sure
- it inserts a <CR><LF> pair on the last line of the data to be
- signed and transmitted (signed message and transmitted message
- MUST be identical).
-
- Example message:
-
- From: Michael Elkins <elkins@aero.org>
- To: Michael Elkins <elkins@aero.org>
- Mime-Version: 1.0
-
-
-
-Elkins, et al. Standards Track [Page 5]
-
-RFC 3156 MIME Security with OpenPGP August 2001
-
-
- Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
- protocol="application/pgp-signature"
-
- --bar
- & Content-Type: text/plain; charset=iso-8859-1
- & Content-Transfer-Encoding: quoted-printable
- &
- & =A1Hola!
- &
- & Did you know that talking to yourself is a sign of senility?
- &
- & It's generally a good idea to encode lines that begin with
- & From=20because some mail transport agents will insert a greater-
- & than (>) sign, thus invalidating the signature.
- &
- & Also, in some cases it might be desirable to encode any =20
- & trailing whitespace that occurs on lines in order to ensure =20
- & that the message signature is not invalidated when passing =20
- & a gateway that modifies such whitespace (like BITNET). =20
- &
- & me
-
- --bar
-
- Content-Type: application/pgp-signature
-
- -----BEGIN PGP MESSAGE-----
- Version: 2.6.2
-
- iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
- jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
- uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
- HOxEa44b+EI=
- =ndaj
- -----END PGP MESSAGE-----
-
- --bar--
-
- The "&"s in the previous example indicate the portion of the data
- over which the signature was calculated.
-
- Upon receipt of a signed message, an application MUST:
-
- (1) Convert line endings to the canonical <CR><LF> sequence before
- the signature can be verified. This is necessary since the
- local MTA may have converted to a local end of line convention.
-
-
-
-
-
-Elkins, et al. Standards Track [Page 6]
-
-RFC 3156 MIME Security with OpenPGP August 2001
-
-
- (2) Pass both the signed data and its associated content headers
- along with the OpenPGP signature to the signature verification
- service.
-
-6. Encrypted and Signed Data
-
- Sometimes it is desirable to both digitally sign and then encrypt a
- message to be sent. This protocol allows for two methods of
- accomplishing this task.
-
-6.1. RFC 1847 Encapsulation
-
- In [2], it is stated that the data is first signed as a
- multipart/signature body, and then encrypted to form the final
- multipart/encrypted body. This is most useful for standard MIME-
- compliant message forwarding.
-
- Example:
-
- Content-Type: multipart/encrypted;
- protocol="application/pgp-encrypted"; boundary=foo
-
- --foo
- Content-Type: application/pgp-encrypted
-
- Version: 1
-
- --foo
- Content-Type: application/octet-stream
-
- -----BEGIN PGP MESSAGE-----
- & Content-Type: multipart/signed; micalg=pgp-md5
- & protocol="application/pgp-signature"; boundary=bar
- &
- & --bar
- & Content-Type: text/plain; charset=us-ascii
- &
- & This message was first signed, and then encrypted.
- &
- & --bar
- & Content-Type: application/pgp-signature
- &
- & -----BEGIN PGP MESSAGE-----
- & Version: 2.6.2
- &
- & iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
- & jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
- & uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
-
-
-
-Elkins, et al. Standards Track [Page 7]
-
-RFC 3156 MIME Security with OpenPGP August 2001
-
-
- & HOxEa44b+EI=
- & =ndaj
- & -----END PGP MESSAGE-----
- &
- & --bar--
- -----END PGP MESSAGE-----
-
- --foo--
-
- (The text preceded by '&' indicates that it is really encrypted, but
- presented as text for clarity.)
-
-6.2. Combined method
-
- The OpenPGP packet format [1] describes a method for signing and
- encrypting data in a single OpenPGP message. This method is allowed
- in order to reduce processing overhead and increase compatibility
- with non-MIME implementations of OpenPGP. The resulting data is
- formatted as a "multipart/encrypted" object as described in Section
- 4.
-
- Messages which are encrypted and signed in this combined fashion are
- REQUIRED to follow the same canonicalization rules as
- multipart/signed objects.
-
- It is explicitly allowed for an agent to decrypt a combined message
- and rewrite it as a multipart/signed object using the signature data
- embedded in the encrypted version.
-
-7. Distribution of OpenPGP public keys
-
- Content-Type: application/pgp-keys
- Required parameters: none
- Optional parameters: none
-
- A MIME body part of the content type "application/pgp-keys" contains
- ASCII-armored transferable Public Key Packets as defined in [1],
- section 10.1.
-
-8. Security Considerations
-
- Signatures of a canonical text document as defined in [1] ignore
- trailing white space in signed material. Implementations which
- choose to use signatures of canonical text documents will not be able
- to detect the addition of whitespace in transit.
-
- See [3], [4] for more information on the security considerations
- concerning the underlying protocols.
-
-
-
-Elkins, et al. Standards Track [Page 8]
-
-RFC 3156 MIME Security with OpenPGP August 2001
-
-
-9. IANA Considerations
-
- This document defines three media types: "application/pgp-encrypted",
- "application/pgp-signature" and "application/pgp-keys". The
- following sections specify the IANA registrations for these types.
-
-9.1. Registration of the application/pgp-encrypted media type
-
- MIME media type name: application
- MIME subtype name: pgp-encrypted
- Required parameters: none
- Optional parameters: none
-
- Encoding considerations:
-
- Currently this media type always consists of a single 7bit text
- string.
-
- Security considerations:
-
- See Section 8 and RFC 2440 Section 13.
-
- Interoperability considerations: none
-
- Published specification:
-
- This document.
-
- Additional information:
-
- Magic number(s): none
- File extension(s): none
- Macintosh File Type Code(s): none
-
- Person & email address to contact for further information:
-
- Michael Elkins
- Email: me@cs.hmc.edu
-
- Intended usage: common
-
- Author/Change controller:
-
- Michael Elkins
- Email: me@cs.hmc.edu
-
-
-
-
-
-
-Elkins, et al. Standards Track [Page 9]
-
-RFC 3156 MIME Security with OpenPGP August 2001
-
-
-9.2. Registration of the application/pgp-signature media type
-
- MIME media type name: application
- MIME subtype name: pgp-signature
- Required parameters: none
- Optional parameters: none
-
- Encoding considerations:
-
- The content of this media type always consists of 7bit text.
-
- Security considerations:
-
- See Section 8 and RFC 2440 Section 13.
-
- Interoperability considerations: none
-
- Published specification:
-
- RFC 2440 and this document.
-
- Additional information:
-
- Magic number(s): none
- File extension(s): asc, sig
- Macintosh File Type Code(s): pgDS
-
- Person & email address to contact for further information:
-
- Michael Elkins
- Email: me@cs.hmc.edu
-
- Intended usage: common
-
- Author/Change controller:
-
- Michael Elkins
- Email: me@cs.hmc.edu
-
-9.3. Registration of the application/pgp-keys media type
-
- MIME media type name: application
- MIME subtype name: pgp-keys
- Required parameters: none
- Optional parameters: none
-
-
-
-
-
-
-Elkins, et al. Standards Track [Page 10]
-
-RFC 3156 MIME Security with OpenPGP August 2001
-
-
- Encoding considerations:
-
- The content of this media type always consists of 7bit text.
-
- Security considerations:
-
- See Section 8 and RFC 2440 Section 13.
-
- Interoperability considerations: none
-
- Published specification:
-
- RFC 2440 and this document.
-
- Additional information:
-
- Magic number(s): none
- File extension(s): asc
- Macintosh File Type Code(s): none
-
- Person & email address to contact for further information:
-
- Michael Elkins
- Email: me@cs.hmc.edu
-
- Intended usage: common
-
- Author/Change controller:
-
- Michael Elkins
- Email: me@cs.hmc.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Elkins, et al. Standards Track [Page 11]
-
-RFC 3156 MIME Security with OpenPGP August 2001
-
-
-10. Notes
-
- "PGP" and "Pretty Good Privacy" are registered trademarks of Network
- Associates, Inc.
-
-11. Acknowledgements
-
- This document relies on the work of the IETF's OpenPGP Working
- Group's definitions of the OpenPGP Message Format. The OpenPGP
- message format is currently described in RFC 2440 [1].
-
- Special thanks are due: to Philip Zimmermann for his original and
- ongoing work on PGP; to Charles Breed, Jon Callas and Dave Del Torto
- for originally proposing the formation of the OpenPGP Working Group;
- and to Steve Schoenfeld for helpful feedback during the draft
- process. The authors would also like to thank the engineers at
- Pretty Good Privacy, Inc (now Network Associates, Inc), including
- Colin Plumb, Hal Finney, Jon Callas, Mark Elrod, Mark Weaver and
- Lloyd Chambers, for their technical commentary.
-
- Additional thanks are due to Jeff Schiller and Derek Atkins for their
- continuing support of strong cryptography and PGP freeware at MIT; to
- Rodney Thayer of Sable Technology; to John Noerenberg, Steve Dorner
- and Laurence Lundblade of the Eudora team at QUALCOMM, Inc; to Bodo
- Moeller for proposing the approach followed with respect to trailing
- whitespace; to John Gilmore, Hugh Daniel and Fred Ringel (at
- Rivertown) and Ian Bell (at Turnpike) for their timely critical
- commentary; and to the international members of the IETF's OpenPGP
- mailing list, including William Geiger, Lutz Donnerhacke and Kazu
- Yamamoto. The idea to use multipart/mixed with multipart/signed has
- been attributed to James Galvin. Finally, our gratitude is due to
- the many members of the "Cypherpunks," "Coderpunks" and "pgp-users"
- <http://cryptorights.org/pgp-users> mailing lists and the many users
- of PGP worldwide for helping keep the path to privacy open.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Elkins, et al. Standards Track [Page 12]
-
-RFC 3156 MIME Security with OpenPGP August 2001
-
-
-12. Addresses of the Authors and OpenPGP Working Group Chair
-
- The OpenPGP working group can be contacted via the current chair:
-
- John W. Noerenberg II
- Qualcomm, Inc.
- 5775 Morehouse Dr.
- San Diego, CA 92121 USA
-
- Phone: +1 619 658 3510
- EMail: jwn2@qualcomm.com
-
- The principal authors of this document are:
-
- Dave Del Torto
- CryptoRights Foundation
- 80 Alviso Street, Mailstop: CRF
- San Francisco, CA 94127 USA
-
- Phone: +1.415.334.5533, vm: #2
- EMail: ddt@cryptorights.org, ddt@openpgp.net
-
-
- Michael Elkins
- Network Associates, Inc.
- 3415 S. Sepulveda Blvd Suite 700
- Los Angeles, CA 90034 USA
-
- Phone: +1.310.737.1663
- Fax: +1.310.737.1755
- Email: me@cs.hmc.edu, Michael_Elkins@NAI.com
-
-
- Raph Levien
- University of California at Berkeley
- 579 Soda Hall
- Berkeley, CA 94720 USA
-
- Phone: +1.510.642.6509
- EMail: raph@acm.org
-
-
- Thomas Roessler
- Nordstrasse 99
- D-53111 Bonn, Germany
-
- Phone: +49-228-638007
- EMail: roessler@does-not-exist.org
-
-
-
-Elkins, et al. Standards Track [Page 13]
-
-RFC 3156 MIME Security with OpenPGP August 2001
-
-
-References
-
- [1] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
- Message Format", RFC 2440, November 1998.
-
- [2] Galvin, J., Murphy, G., Crocker, S. and N. Freed, "Security
- Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
- RFC 1847, October 1995.
-
- [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part Two: Media Types", RFC 2046, November
- 1996.
-
- [4] Galvin, J., Murphy, G., Crocker, S. and N. Freed, "MIME Object
- Security Services", RFC 1848, October 1995.
-
- [5] Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message
- Exchange Formats", RFC 1991, August 1996.
-
- [6] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC
- 2015, October 1996.
-
- [7] Freed, N., "Gateways and MIME Security Multiparts", RFC 2480,
- January 1999.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Elkins, et al. Standards Track [Page 14]
-
-RFC 3156 MIME Security with OpenPGP August 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Elkins, et al. Standards Track [Page 15]
-
diff --git a/doc/src/rfc3501.txt b/doc/src/rfc3501.txt
@@ -1,6051 +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 <foobar@Blurdybloop.COM>
- C: Subject: afternoon meeting
- C: To: mooch@owatagu.siam.edu
- C: Message-Id: <B27397-0100000@Blurdybloop.COM>
- 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")
- "<960723163407.20117h@cac.washington.edu>" "Compiler diff"
- "BASE64" 4554 73) "MIXED")
-
- Extension data follows the multipart subtype. Extension data
- is never returned with the BODY fetch, but can be returned with
- a BODYSTRUCTURE fetch. Extension data, if present, MUST be in
- the defined order. The extension data of a multipart body part
- are in the following order:
-
- body parameter parenthesized list
- A parenthesized list of attribute/value pairs [e.g., ("foo"
- "bar" "baz" "rag") where "bar" is the value of "foo", and
- "rag" is the value of "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
- "<B27397-0100000@cac.washington.edu>")
- 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 <gray@cac.washington.edu>
-S: Subject: IMAP4rev1 WG mtg summary and minutes
-S: To: imap@cac.washington.edu
-S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>
-S: Message-Id: <B27397-0100000@cac.washington.edu>
-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: MRC@CAC.Washington.EDU
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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/src/rfc5804.txt b/doc/src/rfc5804.txt
@@ -1,2747 +0,0 @@
-
-
-
-
-
-
-Internet Engineering Task Force (IETF) A. Melnikov, Ed.
-Request for Comments: 5804 Isode Limited
-Category: Standards Track T. Martin
-ISSN: 2070-1721 BeThereBeSquare, Inc.
- July 2010
-
-
- A Protocol for Remotely Managing Sieve Scripts
-
-Abstract
-
- Sieve scripts allow users to filter incoming email. Message stores
- are commonly sealed servers so users cannot log into them, yet users
- must be able to update their scripts on them. This document
- describes a protocol "ManageSieve" for securely managing Sieve
- scripts on a remote server. This protocol allows a user to have
- multiple scripts, and also alerts a user to syntactically flawed
- scripts.
-
-Status of This Memo
-
- This is an Internet Standards Track document.
-
- This document is a product of the Internet Engineering Task Force
- (IETF). It represents the consensus of the IETF community. It has
- received public review and has been approved for publication by the
- Internet Engineering Steering Group (IESG). Further information on
- Internet Standards is available in Section 2 of RFC 5741.
-
- Information about the current status of this document, any errata,
- and how to provide feedback on it may be obtained at
- http://www.rfc-editor.org/info/rfc5804.
-
-Copyright Notice
-
- Copyright (c) 2010 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (http://trustee.ietf.org/license-info) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with respect
- to this document. Code Components extracted from this document must
- include Simplified BSD License text as described in Section 4.e of
- the Trust Legal Provisions and are provided without warranty as
- described in the Simplified BSD License.
-
-
-
-
-Melnikov & Martin Standards Track [Page 1]
-
-RFC 5804 ManageSieve July 2010
-
-
-Table of Contents
-
- 1. Introduction ....................................................3
- 1.1. Commands and Responses .....................................3
- 1.2. Syntax .....................................................3
- 1.3. Response Codes .............................................3
- 1.4. Active Script ..............................................6
- 1.5. Quotas .....................................................6
- 1.6. Script Names ...............................................6
- 1.7. Capabilities ...............................................7
- 1.8. Transport ..................................................9
- 1.9. Conventions Used in This Document .........................10
- 2. Commands .......................................................10
- 2.1. AUTHENTICATE Command ......................................11
- 2.1.1. Use of SASL PLAIN Mechanism over TLS ...............16
- 2.2. STARTTLS Command ..........................................16
- 2.2.1. Server Identity Check ..............................17
- 2.3. LOGOUT Command ............................................20
- 2.4. CAPABILITY Command ........................................20
- 2.5. HAVESPACE Command .........................................20
- 2.6. PUTSCRIPT Command .........................................21
- 2.7. LISTSCRIPTS Command .......................................23
- 2.8. SETACTIVE Command .........................................24
- 2.9. GETSCRIPT Command .........................................25
- 2.10. DELETESCRIPT Command .....................................25
- 2.11. RENAMESCRIPT Command .....................................26
- 2.12. CHECKSCRIPT Command ......................................27
- 2.13. NOOP Command .............................................28
- 2.14. Recommended Extensions ...................................28
- 2.14.1. UNAUTHENTICATE Command ............................28
- 3. Sieve URL Scheme ...............................................29
- 4. Formal Syntax ..................................................31
- 5. Security Considerations ........................................37
- 6. IANA Considerations ............................................38
- 6.1. ManageSieve Capability Registration Template ..............39
- 6.2. Registration of Initial ManageSieve Capabilities ..........39
- 6.3. ManageSieve Response Code Registration Template ...........41
- 6.4. Registration of Initial ManageSieve Response Codes ........41
- 7. Internationalization Considerations ............................46
- 8. Acknowledgements ...............................................46
- 9. References .....................................................47
- 9.1. Normative References ......................................47
- 9.2. Informative References ....................................48
-
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 2]
-
-RFC 5804 ManageSieve July 2010
-
-
-1. Introduction
-
-1.1. Commands and Responses
-
- A ManageSieve 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 a ManageSieve client or server is either reading a line or reading
- a sequence of octets with a known count followed by a line.
-
-1.2. Syntax
-
- ManageSieve is a line-oriented protocol much like [IMAP] or [ACAP],
- which runs over TCP. There are three data types: atoms, numbers and
- strings. Strings may be quoted or literal. See [ACAP] for detailed
- descriptions of these types.
-
- Each command consists of an atom (the command name) followed by zero
- or more strings and numbers terminated by CRLF.
-
- All client queries are replied to with either an OK, NO, or BYE
- response. Each response may be followed by a response code (see
- Section 1.3) and by a string consisting of human-readable text in the
- local language (as returned by the LANGUAGE capability; see
- Section 1.7), encoded in UTF-8 [UTF-8]. The contents of the string
- SHOULD be shown to the user ,and implementations MUST NOT attempt to
- parse the message for meaning.
-
- The BYE response SHOULD be used if the server wishes to close the
- connection. A server may wish to do this because the client was idle
- for too long or there were too many failed authentication attempts.
- This response can be issued at any time and should be immediately
- followed by a server hang-up of the connection. If a server has an
- inactivity timeout resulting in client autologout, it MUST be no less
- than 30 minutes after successful authentication. The inactivity
- timeout MAY be less before authentication.
-
-1.3. Response Codes
-
- An OK, NO, or BYE response from the server MAY contain a response
- code to describe the event in a more detailed machine-parsable
- fashion. A response code consists of data inside parentheses in the
- form of an atom, possibly followed by a space and arguments.
-
-
-
-Melnikov & Martin Standards Track [Page 3]
-
-RFC 5804 ManageSieve July 2010
-
-
- Response codes are defined when there is a specific action that a
- client can take based upon the additional information. In order to
- support future extension, the response code is represented as a
- slash-separated (Solidus, %x2F) hierarchy with each level of
- hierarchy representing increasing detail about the error. Response
- codes MUST NOT start with the Solidus character. Clients MUST
- tolerate additional hierarchical response code detail that they don't
- understand. For example, if the client supports the "QUOTA" response
- code, but doesn't understand the "QUOTA/MAXSCRIPTS" response code, it
- should treat "QUOTA/MAXSCRIPTS" as "QUOTA".
-
- Client implementations MUST tolerate (ignore) response codes that
- they do not recognize.
-
- The currently defined response codes are the following:
-
- AUTH-TOO-WEAK
-
- This response code is returned in the NO or BYE response from an
- AUTHENTICATE command. It indicates that site security policy forbids
- the use of the requested mechanism for the specified authentication
- identity.
-
- ENCRYPT-NEEDED
-
- This response code is returned in the NO or BYE response from an
- AUTHENTICATE command. It indicates that site security policy
- requires the use of a strong encryption mechanism for the specified
- authentication identity and mechanism.
-
- QUOTA
-
- If this response code is returned in the NO/BYE response, it means
- that the command would have placed the user above the site-defined
- quota constraints. If this response code is returned in the OK
- response, it can mean that the user's storage is near its quota, or
- it can mean that the account exceeded its quota but that the
- condition is being allowed by the server (the server supports
- so-called soft quotas). The QUOTA response code has two more
- detailed variants: "QUOTA/MAXSCRIPTS" (the maximum number of per-user
- scripts) and "QUOTA/MAXSIZE" (the maximum script size).
-
- REFERRAL
-
- This response code may be returned with a BYE result from any
- command, and includes a mandatory parameter that indicates what
- server to access to manage this user's Sieve scripts. The server
- will be specified by a Sieve URL (see Section 3). The scriptname
-
-
-
-Melnikov & Martin Standards Track [Page 4]
-
-RFC 5804 ManageSieve July 2010
-
-
- portion of the URL MUST NOT be specified. The client should
- authenticate to the specified server and use it for all further
- commands in the current session.
-
- SASL
-
- This response code can occur in the OK response to a successful
- AUTHENTICATE command and includes the optional final server response
- data from the server as specified by [SASL].
-
- TRANSITION-NEEDED
-
- This response code occurs in a NO response of an AUTHENTICATE
- command. It indicates that the user name is valid, but the entry in
- the authentication database needs to be updated in order to permit
- authentication with the specified mechanism. This is typically done
- by establishing a secure channel using TLS, verifying server identity
- as specified in Section 2.2.1, and finally authenticating once using
- the [PLAIN] authentication mechanism. The selected mechanism SHOULD
- then work for authentications in subsequent sessions.
-
- This condition can happen if a user has an entry in a system
- authentication database such as Unix /etc/passwd, but does not have
- credentials suitable for use by the specified mechanism.
-
- TRYLATER
-
- A command failed due to a temporary server failure. The client MAY
- continue using local information and try the command later. This
- response code only makes sense when returned in a NO/BYE response.
-
- ACTIVE
-
- A command failed because it is not allowed on the active script, for
- example, DELETESCRIPT on the active script. This response code only
- makes sense when returned in a NO/BYE response.
-
- NONEXISTENT
-
- A command failed because the referenced script name doesn't exist.
- This response code only makes sense when returned in a NO/BYE
- response.
-
- ALREADYEXISTS
-
- A command failed because the referenced script name already exists.
- This response code only makes sense when returned in a NO/BYE
- response.
-
-
-
-Melnikov & Martin Standards Track [Page 5]
-
-RFC 5804 ManageSieve July 2010
-
-
- TAG
-
- This response code name is followed by a string specified in the
- command. See Section 2.13 for a possible use case.
-
- WARNINGS
-
- This response code MAY be returned by the server in the OK response
- (but it might be returned with the NO/BYE response as well) and
- signals the client that even though the script is syntactically
- valid, it might contain errors not intended by the script writer.
- This response code is typically returned in response to PUTSCRIPT
- and/or CHECKSCRIPT commands. A client seeing such response code
- SHOULD present the returned warning text to the user.
-
-1.4. Active Script
-
- A user may have multiple Sieve scripts on the server, yet only one
- script may be used for filtering of incoming messages. This is the
- active script. Users may have zero or one active script and MUST use
- the SETACTIVE command described below for changing the active script
- or disabling Sieve processing. For example, users may have an
- everyday script they normally use and a special script they use when
- they go on vacation. Users can change which script is being used
- without having to download and upload a script stored somewhere else.
-
-1.5. Quotas
-
- Servers SHOULD impose quotas to prevent malicious users from
- overflowing available storage. If a command would place a user over
- a quota setting, servers that impose such quotas MUST reply with a NO
- response containing the QUOTA response code. Client implementations
- MUST be able to handle commands failing because of quota
- restrictions.
-
-1.6. Script Names
-
- A Sieve script name is a sequence of Unicode characters encoded in
- UTF-8 [UTF-8]. A script name MUST comply with Net-Unicode Definition
- (Section 2 of [NET-UNICODE]), with the additional restriction of
- prohibiting the following Unicode characters:
-
- o 0000-001F; [CONTROL CHARACTERS]
-
- o 007F; DELETE
-
- o 0080-009F; [CONTROL CHARACTERS]
-
-
-
-
-Melnikov & Martin Standards Track [Page 6]
-
-RFC 5804 ManageSieve July 2010
-
-
- o 2028; LINE SEPARATOR
-
- o 2029; PARAGRAPH SEPARATOR
-
- Sieve script names MUST be at least one octet (and hence Unicode
- character) long. Zero octets script name has a special meaning (see
- Section 2.8). Servers MUST allow names of up to 128 Unicode
- characters in length (which can take up to 512 bytes when encoded in
- UTF-8, not counting the terminating NUL), and MAY allow longer names.
- A server that receives a script name longer than its internal limit
- MUST reject the corresponding operation, in particular it MUST NOT
- truncate the script name.
-
-1.7. Capabilities
-
- Server capabilities are sent automatically by the server upon a
- client connection, or after successful STARTTLS and AUTHENTICATE
- (which establishes a Simple Authentication and Security Layer (SASL))
- commands. Capabilities may change immediately after a successfully
- completed STARTTLS command, and/or immediately after a successfully
- completed AUTHENTICATE command, and/or after a successfully completed
- UNAUTHENTICATE command (see Section 2.14.1). Capabilities MUST
- remain static at all other times.
-
- Clients MAY request the capabilities at a later time by issuing the
- CAPABILITY command described later. The capabilities consist of a
- series of lines each with one or two strings. The first string is
- the name of the capability, which is case-insensitive. The second
- optional string is the value associated with that capability. Order
- of capabilities is arbitrary, but each capability name can appear at
- most once.
-
- The following capabilities are defined in this document:
-
- IMPLEMENTATION - Name of implementation and version. This capability
- MUST always be returned by the server.
-
- SASL - List of SASL mechanisms supported by the server, each
- separated by a space. This list can be empty if and only if STARTTLS
- is also advertised. This means that the client must negotiate TLS
- encryption with STARTTLS first, at which point the SASL capability
- will list a non-empty list of SASL mechanisms.
-
- SIEVE - List of space-separated Sieve extensions (as listed in Sieve
- "require" action [SIEVE]) supported by the Sieve engine. This
- capability MUST always be returned by the server.
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 7]
-
-RFC 5804 ManageSieve July 2010
-
-
- STARTTLS - If TLS [TLS] is supported by this implementation. Before
- advertising this capability a server MUST verify to the best of its
- ability that TLS can be successfully negotiated by a client with
- common cipher suites. Specifically, a server should verify that a
- server certificate has been installed and that the TLS subsystem has
- successfully initialized. This capability SHOULD NOT be advertised
- once STARTTLS or AUTHENTICATE command completes successfully. Client
- and server implementations MUST implement the STARTTLS extension.
-
- MAXREDIRECTS - Specifies the limit on the number of Sieve "redirect"
- actions a script can perform during a single evaluation. Note that
- this is different from the total number of "redirect" actions a
- script can contain. The value is a non-negative number represented
- as a ManageSieve string.
-
- NOTIFY - A space-separated list of URI schema parts for supported
- notification methods. This capability MUST be specified if the Sieve
- implementation supports the "enotify" extension [NOTIFY].
-
- LANGUAGE - The language (<Language-Tag> from [RFC5646]) currently
- used for human-readable error messages. If this capability is not
- returned, the "i-default" [RFC2277] language is assumed. Note that
- the current language MAY be per-user configurable (i.e., it MAY
- change after authentication).
-
- OWNER - The canonical name of the logged-in user (SASL "authorization
- identity") encoded in UTF-8. This capability MUST NOT be returned in
- unauthenticated state and SHOULD be returned once the AUTHENTICATE
- command succeeds.
-
- VERSION - This capability MUST be returned by servers compliant with
- this document or its successor. For servers compliant with this
- document, the capability value is the string "1.0". Lack of this
- capability means that the server predates this specification and thus
- doesn't support the following commands: RENAMESCRIPT, CHECKSCRIPT,
- and NOOP.
-
- Section 2.14 defines some additional ManageSieve extensions and their
- respective capabilities.
-
- A server implementation MUST return SIEVE, IMPLEMENTATION, and
- VERSION capabilities.
-
- A client implementation MUST ignore any listed capabilities that it
- does not understand.
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 8]
-
-RFC 5804 ManageSieve July 2010
-
-
- Example:
-
- S: "IMPlemENTATION" "Example1 ManageSieved v001"
- S: "SASl" "DIGEST-MD5 GSSAPI"
- S: "SIeVE" "fileinto vacation"
- S: "StaRTTLS"
- S: "NOTIFY" "xmpp mailto"
- S: "MAXREdIRECTS" "5"
- S: "VERSION" "1.0"
- S: OK
-
- After successful authentication, this might look like this:
-
- Example:
-
- S: "IMPlemENTATION" "Example1 ManageSieved v001"
- S: "SASl" "DIGEST-MD5 GSSAPI"
- S: "SIeVE" "fileinto vacation"
- S: "NOTIFY" "xmpp mailto"
- S: "OWNER" "alexey@example.com"
- S: "MAXREdIRECTS" "5"
- S: "VERSION" "1.0"
- S: OK
-
-1.8. Transport
-
- The ManageSieve protocol assumes a reliable data stream such as that
- provided by TCP. When TCP is used, a ManageSieve server typically
- listens on port 4190.
-
- Before opening the TCP connection, the ManageSieve client first MUST
- resolve the Domain Name System (DNS) hostname associated with the
- receiving entity and determine the appropriate TCP port for
- communication with the receiving entity. The process is as follows:
-
- 1. Attempt to resolve the hostname using a [DNS-SRV] Service of
- "sieve" and a Proto of "tcp" for the target domain (e.g.,
- "example.net"), resulting in resource records such as
- "_sieve._tcp.example.net.". The result of the SRV lookup, if
- successful, will be one or more combinations of a port and
- hostname; the ManageSieve client MUST resolve the returned
- hostnames to IPv4/IPv6 addresses according to returned SRV record
- weight. IP addresses from the first successfully resolved
- hostname (with the corresponding port number returned by SRV
- lookup) are used to connect to the server. If connection using
- one of the IP addresses fails, the next resolved IP address is
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 9]
-
-RFC 5804 ManageSieve July 2010
-
-
- used to connect. If connection to all resolved IP addresses
- fails, then the resolution/connect is repeated for the next
- hostname returned by SRV lookup.
-
- 2. If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or
- IPv6 address record resolution to determine the IP address, where
- the port used is the default ManageSieve port of 4190.
-
-1.9. 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 [KEYWORDS].
-
- In examples, "C:" and "S:" indicate lines sent by the client and
- server respectively. Line breaks that do not start a new "C:" or
- "S:" exist for editorial reasons.
-
- Examples of authentication in this document are using DIGEST-MD5
- [DIGEST-MD5] and GSSAPI [GSSAPI] SASL mechanisms.
-
-2. Commands
-
- This section and its subsections describe valid ManageSieve commands.
- Upon initial connection to the server, the client's session is in
- non-authenticated state. Prior to successful authentication, only
- the AUTHENTICATE, CAPABILITY, STARTTLS, LOGOUT, and NOOP (see Section
- 2.13) commands are valid. ManageSieve extensions MAY define other
- commands that are valid in non-authenticated state. Servers MUST
- reject all other commands with a NO response. Clients may pipeline
- commands (send more than one command at a time without waiting for
- completion of the first command). However, a group of commands sent
- together MUST NOT have an AUTHENTICATE (*), a STARTTLS, or a
- HAVESPACE command anywhere but the last command in the list.
-
- (*) - The only exception to this rule is when the AUTHENTICATE
- command contains an initial response for a SASL mechanism that allows
- clients to send data first, the mechanism is known to complete in one
- round trip, and the mechanism doesn't negotiate a SASL security
- layer. Two examples of such SASL mechanisms are PLAIN [PLAIN] and
- EXTERNAL [SASL].
-
-
-
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 10]
-
-RFC 5804 ManageSieve July 2010
-
-
-2.1. AUTHENTICATE Command
-
- Arguments: String - mechanism
- String - initial data (optional)
-
- The AUTHENTICATE command indicates a SASL [SASL] authentication
- mechanism to the server. If the server supports the requested
- authentication mechanism, it performs an authentication protocol
- exchange to identify and authenticate the user. Optionally, it also
- negotiates a security layer for subsequent protocol interactions. If
- the requested authentication mechanism is not supported, the server
- rejects the AUTHENTICATE command by sending the NO response.
-
- The authentication protocol exchange consists of a series of server
- challenges and client responses that are specific to the selected
- authentication mechanism. A server challenge consists of a string
- (quoted or literal) followed by a CRLF. The contents of the string
- is a base-64 encoding [BASE64] of the SASL data. A client response
- consists of a string (quoted or literal) with the base-64 encoding of
- the SASL data followed by a CRLF. If the client wishes to cancel the
- authentication exchange, it issues a string containing a single "*".
- If the server receives such a response, it MUST reject the
- AUTHENTICATE command by sending a NO reply.
-
- Note that an empty challenge/response is sent as an empty string. If
- the mechanism dictates that the final response is sent by the server,
- this data MAY be placed within the data portion of the SASL response
- code to save a round trip.
-
- The optional initial-response argument to the AUTHENTICATE command is
- used to save a round trip when using authentication mechanisms that
- are defined to send no data in the initial challenge. When the
- initial-response argument is used with such a mechanism, the initial
- empty challenge is not sent to the client and the server uses the
- data in the initial-response argument as if it were sent in response
- to the empty challenge. If the initial-response argument to the
- AUTHENTICATE command is used with a mechanism that sends data in the
- initial challenge, the server MUST reject the AUTHENTICATE command by
- sending the NO response.
-
- The service name specified by this protocol's profile of SASL is
- "sieve".
-
- Reauthentication is not supported by ManageSieve protocol's profile
- of SASL. That is, after a successfully completed AUTHENTICATE
- command, no more AUTHENTICATE commands may be issued in the same
- session. After a successful AUTHENTICATE command completes, a server
- MUST reject any further AUTHENTICATE commands with a NO reply.
-
-
-
-Melnikov & Martin Standards Track [Page 11]
-
-RFC 5804 ManageSieve July 2010
-
-
- However, note that a server may implement the UNAUTHENTICATE
- extension described in Section 2.14.1.
-
- If a security layer is negotiated through the SASL authentication
- exchange, it takes effect immediately following the CRLF that
- concludes the successful authentication exchange for the client, and
- the CRLF of the OK response for the server.
-
- When a security layer takes effect, the ManageSieve protocol is reset
- to the initial state (the state in ManageSieve after a client has
- connected to the server). The server MUST discard any knowledge
- obtained from the client that was not obtained from the SASL (or TLS)
- negotiation itself. Likewise, the client MUST discard any knowledge
- obtained from the server, such as the list of ManageSieve extensions,
- that was not obtained from the SASL (and/or TLS) negotiation itself.
- (Note that a client MAY compare the advertised SASL mechanisms before
- and after authentication in order to detect an active down-
- negotiation attack. See below.)
-
- Once a SASL security layer is established, the server MUST re-issue
- the capability results, followed by an OK response. This is
- necessary to protect against man-in-the-middle attacks that alter the
- capabilities list prior to SASL negotiation. The capability results
- MUST include all SASL mechanisms the server was capable of
- negotiating with that client. This is done in order to allow the
- client to detect an active down-negotiation attack. If a user-
- oriented client detects such a down-negotiation attack, it SHOULD
- either notify the user (it MAY give the user the opportunity to
- continue with the ManageSieve session in this case) or close the
- transport connection and indicate that a down-negotiation attack
- might be in progress. If an automated client detects a down-
- negotiation attack, it SHOULD return or log an error indicating that
- a possible attack might be in progress and/or SHOULD close the
- transport connection.
-
- When both [TLS] and SASL security layers are in effect, the TLS
- encoding MUST be applied (when sending data) after the SASL encoding.
-
- Server implementations SHOULD support SASL proxy authentication so
- that an administrator can administer a user's scripts. Proxy
- authentication is when a user authenticates as herself/himself but
- requests the server to act (authorize) as another user.
-
- The authorization identity generated by this [SASL] exchange is a
- "simple username" (in the sense defined in [SASLprep]), and both
- client and server MUST use the [SASLprep] profile of the [StringPrep]
- algorithm to prepare these names for transmission or comparison. If
- preparation of the authorization identity fails or results in an
-
-
-
-Melnikov & Martin Standards Track [Page 12]
-
-RFC 5804 ManageSieve July 2010
-
-
- empty string (unless it was transmitted as the empty string), the
- server MUST fail the authentication.
-
- If an AUTHENTICATE command fails with a NO response, the client MAY
- try another authentication mechanism by issuing another AUTHENTICATE
- command. In other words, the client may request authentication types
- in decreasing order of preference.
-
- Note that a failed (NO) response to the AUTHENTICATE command may
- contain one of the following response codes: AUTH-TOO-WEAK, ENCRYPT-
- NEEDED, or TRANSITION-NEEDED. See Section 1.3 for detailed
- description of the relevant conditions.
-
- To ensure interoperability, both client and server implementations of
- the ManageSieve protocol MUST implement the SCRAM-SHA-1 [SCRAM] SASL
- mechanism, as well as [PLAIN] over [TLS].
-
- Note: use of PLAIN over TLS reflects current use of PLAIN over TLS in
- other email-related protocols; however, a longer-term goal is to
- migrate email-related protocols from using PLAIN over TLS to SCRAM-
- SHA-1 mechanism.
-
- Examples (Note that long lines are folded for readability and are not
- part of protocol exchange):
-
- S: "IMPLEMENTATION" "Example1 ManageSieved v001"
- S: "SASL" "DIGEST-MD5 GSSAPI"
- S: "SIEVE" "fileinto vacation"
- S: "STARTTLS"
- S: "VERSION" "1.0"
- S: OK
- C: Authenticate "DIGEST-MD5"
- S: "cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik
- 9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz
- cyxjaGFyc2V0PXV0Zi04"
- C: "Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
- QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo
- aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX
- N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy
- ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3
- A9YXV0aA=="
- S: OK (SASL "cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZ
- mZmZA==")
-
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 13]
-
-RFC 5804 ManageSieve July 2010
-
-
- A slightly different variant of the same authentication exchange is:
-
- S: "IMPLEMENTATION" "Example1 ManageSieved v001"
- S: "SASL" "DIGEST-MD5 GSSAPI"
- S: "SIEVE" "fileinto vacation"
- S: "VERSION" "1.0"
- S: "STARTTLS"
- S: OK
- C: Authenticate "DIGEST-MD5"
- S: {136}
- S: cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik
- 9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz
- cyxjaGFyc2V0PXV0Zi04
- C: {300+}
- C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
- QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo
- aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX
- N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy
- ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3
- A9YXV0aA==
- S: {56}
- S: cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
- C: ""
- S: OK
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 14]
-
-RFC 5804 ManageSieve July 2010
-
-
- Another example demonstrating use of SASL PLAIN mechanism under TLS
- follows. This example also demonstrate use of SASL "initial
- response" (the second parameter to the Authenticate command):
-
- S: "IMPLEMENTATION" "Example1 ManageSieved v001"
- S: "VERSION" "1.0"
- S: "SASL" ""
- S: "SIEVE" "fileinto vacation"
- S: "STARTTLS"
- S: OK
- C: STARTTLS
- S: OK
- <TLS negotiation, further commands are under TLS layer>
- S: "IMPLEMENTATION" "Example1 ManageSieved v001"
- S: "VERSION" "1.0"
- S: "SASL" "PLAIN"
- S: "SIEVE" "fileinto vacation"
- S: OK
- C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu"
- S: NO
- C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xz"
- S: NO
- C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xy"
- S: BYE "Too many failed authentication attempts"
- <Server closes connection>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 15]
-
-RFC 5804 ManageSieve July 2010
-
-
- The following example demonstrates use of SASL "initial response".
- It also demonstrates that an empty response can be sent as a literal
- and that negotiating a SASL security layer results in the server
- re-issuing server capabilities:
-
- C: AUTHENTICATE "GSSAPI" {1488+}
- C: YIIE[...1480 octets here ...]dA==
- S: {208}
- S: YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKic
- [...114 octets here ...]
- /yzpAy9p+Y0LanLskOTvMc0MnjgAa4YEr3eJ6
- C: {0+}
- C:
- S: {44}
- S: BQQF/wAMAAwAAAAAYRGFAo6W0vIHti8i1UXODgEAEAA=
- C: {44+}
- C: BQQE/wAMAAwAAAAAIsT1iv9UkZApw471iXt6cwEAAAE=
- S: OK
- <Further commands/responses are under SASL security layer>
- S: "IMPLEMENTATION" "Example1 ManageSieved v001"
- S: "VERSION" "1.0"
- S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
- S: "SIEVE" "fileinto vacation"
- S: "LANGUAGE" "ru"
- S: "MAXREDIRECTS" "3"
- S: ok
-
-2.1.1. Use of SASL PLAIN Mechanism over TLS
-
- This section is normative for ManageSieve client implementations that
- support SASL [PLAIN] over [TLS].
-
- If a ManageSieve client is willing to use SASL PLAIN over TLS to
- authenticate to the ManageSieve server, the client MUST verify the
- server identity (see Section 2.2.1). If the server identity can't be
- verified (e.g., the server has not provided any certificate, or if
- the certificate verification fails), the client MUST NOT attempt to
- authenticate using the SASL PLAIN mechanism.
-
-2.2. STARTTLS Command
-
- Support for STARTTLS command in servers is optional. Its
- availability is advertised with "STARTTLS" capability as described in
- Section 1.7.
-
- The STARTTLS command requests commencement of a TLS [TLS]
- negotiation. The negotiation begins immediately after the CRLF in
- the OK response. After a client issues a STARTTLS command, it MUST
-
-
-
-Melnikov & Martin Standards Track [Page 16]
-
-RFC 5804 ManageSieve July 2010
-
-
- 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 the
- capability results, followed by an OK response. This is necessary to
- protect against man-in-the-middle attacks that alter the capabilities
- list prior to STARTTLS. This capability result MUST NOT include the
- STARTTLS capability.
-
- The client MUST discard cached capability information and replace it
- with the new information. The server MAY advertise different
- capabilities after STARTTLS.
-
- Example:
-
- C: StartTls
- S: oK
- <TLS negotiation, further commands are under TLS layer>
- S: "IMPLEMENTATION" "Example1 ManageSieved v001"
- S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
- S: "SIEVE" "fileinto vacation"
- S: "VERSION" "1.0"
- S: "LANGUAGE" "fr"
- S: ok
-
-2.2.1. Server Identity Check
-
- During the TLS negotiation, the ManageSieve client MUST check its
- understanding of the server hostname/IP address against the server's
- identity as presented in the server Certificate message, in order to
- prevent man-in-the-middle attacks. In this section, the client's
- understanding of the server's identity is called the "reference
- identity".
-
- Checking is performed according to the following rules:
-
- o If the reference identity is a hostname:
-
- 1. If a subjectAltName extension of the SRVName [X509-SRV],
- dNSName [X509] (in that order of preference) type is present
- in the server's certificate, then it SHOULD be used as the
-
-
-
-Melnikov & Martin Standards Track [Page 17]
-
-RFC 5804 ManageSieve July 2010
-
-
- source of the server's identity. Matching is performed as
- described in Section 2.2.1.1, with the exception that no
- wildcard matching is allowed for SRVName type. 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.
-
- 2. The client MAY use other types of subjectAltName for
- performing comparison.
-
- 3. The server's identity MAY also be verified by comparing the
- reference identity to the Common Name (CN) [RFC4519] value in
- the leaf Relative Distinguished Name (RDN) of the subjectName
- field of the server's certificate. This comparison is
- performed using the rules for comparison of DNS names in
- Section 2.2.1.1, below. Although the use of the Common Name
- value is existing practice, it is deprecated, and
- Certification Authorities are encouraged to provide
- subjectAltName values instead. Note that the TLS
- implementation may represent DNs in certificates according to
- X.500 or other conventions. For example, some X.500
- implementations order the RDNs in a DN using a left-to-right
- (most significant to least significant) convention instead of
- LDAP's right-to-left convention.
-
- o When the reference identity is an IP address, the iPAddress
- subjectAltName SHOULD be used by the client for comparison. The
- comparison is performed as described in Section 2.2.1.2.
-
- If the server identity check fails, user-oriented clients SHOULD
- either notify the user (clients MAY give the user the opportunity to
- continue with the ManageSieve session in this case) or close the
- transport connection and indicate that the server's identity is
- suspect. Automated clients SHOULD return or log an error indicating
- that the server's identity is suspect and/or SHOULD close the
- transport connection. Automated clients MAY provide a configuration
- setting that disables this check, but MUST provide a setting that
- enables it.
-
- Beyond the server identity check described in this section, clients
- should be prepared to do further checking to ensure that the server
- is authorized to provide the service it is requested to provide. The
- client may need to make use of local policy information in making
- this determination.
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 18]
-
-RFC 5804 ManageSieve July 2010
-
-
-2.2.1.1. Comparison of DNS Names
-
- If the reference identity is an internationalized domain name,
- conforming implementations MUST convert it to the ASCII Compatible
- Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490]
- before comparison with subjectAltName values of type dNSName.
- Specifically, conforming implementations MUST perform the conversion
- operation specified in Section 4 of [RFC3490] as follows:
-
- o in step 1, the domain name SHALL be considered a "stored string";
-
- o in step 3, set the flag called "UseSTD3ASCIIRules";
-
- o in step 4, process each label with the "ToASCII" operation; and
-
- o in step 5, change all label separators to U+002E (full stop).
-
- After performing the "to-ASCII" conversion, the DNS labels and names
- MUST be compared for equality according to the rules specified in
- Section 3 of [RFC3490]; i.e., once all label separators are replaced
- with U+002E (dot) they are compared in the case-insensitive manner.
-
- The '*' (ASCII 42) wildcard character is allowed in subjectAltName
- values of type dNSName, and then only as the left-most (least
- significant) DNS label in that value. This wildcard matches any
- left-most DNS label in the server name. That is, the subject
- *.example.com matches the server names a.example.com and
- b.example.com, but does not match example.com or a.b.example.com.
-
-2.2.1.2. Comparison of IP Addresses
-
- When the reference identity is an IP address, the identity MUST be
- converted to the "network byte order" octet string representation
- [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the
- octet string will contain exactly four octets. For IP Version 6, as
- specified in RFC 2460, the octet string will contain exactly sixteen
- octets. This octet string is then compared against subjectAltName
- values of type iPAddress. A match occurs if the reference identity
- octet string and value octet strings are identical.
-
-2.2.1.3. Comparison of Other subjectName Types
-
- Client implementations MAY support matching against subjectAltName
- values of other types as described in other documents.
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 19]
-
-RFC 5804 ManageSieve July 2010
-
-
-2.3. LOGOUT Command
-
- The client sends the LOGOUT command when it is finished with a
- connection and wishes to terminate it. The server MUST reply with an
- OK response. The server MUST ignore commands issued by the client
- after the LOGOUT command.
-
- The client SHOULD wait for the OK response before closing the
- connection. This avoids the TCP connection going into the TIME_WAIT
- state on the server. In order to avoid going into the TIME_WAIT TCP
- state, the server MAY wait for a short while for the client to close
- the TCP connection first. Whether or not the server waits for the
- client to close the connection, it MUST then close the connection
- itself.
-
- Example:
-
- C: Logout
- S: Ok
- <connection is terminated>
-
-2.4. CAPABILITY Command
-
- The CAPABILITY command requests the server capabilities as described
- earlier in this document. It has no parameters.
-
- Example:
-
- C: CAPABILITY
- S: "IMPLEMENTATION" "Example1 ManageSieved v001"
- S: "VERSION" "1.0"
- S: "SASL" "PLAIN SCRAM-SHA-1 GSSAPI"
- S: "SIEVE" "fileinto vacation"
- S: "STARTTLS"
- S: OK
-
-2.5. HAVESPACE Command
-
- Arguments: String - name
- Number - script size
-
- The HAVESPACE command is used to query the server for available
- space. Clients specify the name they wish to save the script as and
- its size in octets. Both parameters can be used by the server to see
- if the script with the specified name and size is within a user's
- quota(s). For example, the server MAY use the script name to check
- if a script would be replaced or a new one would be created. Servers
- respond with a NO if storing a script with that name and size would
-
-
-
-Melnikov & Martin Standards Track [Page 20]
-
-RFC 5804 ManageSieve July 2010
-
-
- fail or OK otherwise. Clients SHOULD issue this command before
- attempting to place a script on the server.
-
- Note that the OK response from the HAVESPACE command does not
- constitute a guarantee of success as server disk space conditions
- could change between the client issuing the HAVESPACE and the client
- issuing the PUTSCRIPT commands. A QUOTA response code (see
- Section 1.3) remains a possible (albeit unlikely) response to a
- subsequent PUTSCRIPT with the same name and size.
-
- Example:
-
- C: HAVESPACE "myscript" 999999
- S: NO (QUOTA/MAXSIZE) "Quota exceeded"
-
- C: HAVESPACE "foobar" 435
- S: OK
-
-2.6. PUTSCRIPT Command
-
- Arguments: String - Script name
- String - Script content
-
- The PUTSCRIPT command is used by the client to submit a Sieve script
- to the server.
-
- If the script already exists, upon success the old script will be
- overwritten. The old script MUST NOT be overwritten if PUTSCRIPT
- fails in any way. A script of zero length SHOULD be disallowed.
-
- This command places the script on the server. It does not affect
- whether the script is processed on incoming mail, unless it replaces
- the script that is already active. The SETACTIVE command is used to
- mark a script as active.
-
- When submitting large scripts, clients SHOULD use the HAVESPACE
- command beforehand to query if the server is willing to accept a
- script of that size.
-
- The server MUST check the submitted script for validity, which
- includes checking that the script complies with the Sieve grammar
- [SIEVE] and that all Sieve extensions mentioned in the script's
- "require" statement(s) are supported by the Sieve interpreter. (Note
- that if the Sieve interpreter supports the Sieve "ihave" extension
- [I-HAVE], any unrecognized/unsupported extension mentioned in the
- "ihave" test MUST NOT cause the validation failure.) Other checks
- such as validating the supplied command arguments for each command
- MAY be performed. Essentially, the performed validation SHOULD be
-
-
-
-Melnikov & Martin Standards Track [Page 21]
-
-RFC 5804 ManageSieve July 2010
-
-
- the same as performed when compiling the script for execution.
- Implementations that use a binary representation to store compiled
- scripts can extend the validation to a full compilation, in order to
- avoid validating uploaded scripts multiple times.
-
- If the script fails the validation, the server MUST reply with a NO
- response. Any script that fails the validity test MUST NOT be stored
- on the server. The message given with a NO response MUST be human
- readable and SHOULD contain a specific error message giving the line
- number of the first error. Implementors should strive to produce
- helpful error messages similar to those given by programming language
- compilers. Client implementations should note that this may be a
- multiline literal string with more than one error message separated
- by CRLFs. The human-readable message is in the language returned in
- the latest LANGUAGE capability (or in "i-default"; see Section 1.7),
- encoded in UTF-8 [UTF-8].
-
- An OK response MAY contain the WARNINGS response code. In such a
- case the human-readable message that follows the OK response SHOULD
- contain a specific warning message (or messages) giving the line
- number(s) in the script that might contain errors not intended by the
- script writer. The human-readable message is in the language
- returned in the latest LANGUAGE capability (or in "i-default"; see
- Section 1.7), encoded in UTF-8 [UTF-8]. A client seeing such a
- response code SHOULD present the message to the user.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 22]
-
-RFC 5804 ManageSieve July 2010
-
-
- Examples:
-
- C: Putscript "foo" {31+}
- C: #comment
- C: InvalidSieveCommand
- C:
- S: NO "line 2: Syntax error"
-
- C: Putscript "mysievescript" {110+}
- C: require ["fileinto"];
- C:
- C: if envelope :contains "to" "tmartin+sent" {
- C: fileinto "INBOX.sent";
- C: }
- S: OK
-
- C: Putscript "myforwards" {190+}
- C: redirect "111@example.net";
- C:
- C: if size :under 10k {
- C: redirect "mobile@cell.example.com";
- C: }
- C:
- C: if envelope :contains "to" "tmartin+lists" {
- C: redirect "lists@groups.example.com";
- C: }
- S: OK (WARNINGS) "line 8: server redirect action
- limit is 2, this redirect might be ignored"
-
-2.7. LISTSCRIPTS Command
-
- This command lists the scripts the user has on the server. Upon
- success, a list of CRLF-separated script names (each represented as a
- quoted or literal string) is returned followed by an OK response. If
- there exists an active script, the atom ACTIVE is appended to the
- corresponding script name. The atom ACTIVE MUST NOT appear on more
- than one response line.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 23]
-
-RFC 5804 ManageSieve July 2010
-
-
- Example:
-
- C: Listscripts
- S: "summer_script"
- S: "vacation_script"
- S: {13}
- S: clever"script
- S: "main_script" ACTIVE
- S: OK
-
- C: listscripts
- S: "summer_script"
- S: "main_script" active
- S: OK
-
-2.8. SETACTIVE Command
-
- Arguments: String - script name
-
- This command sets a script active. If the script name is the empty
- string (i.e., ""), then any active script is disabled. Disabling an
- active script when there is no script active is not an error and MUST
- result in an OK reply.
-
- If the script does not exist on the server, then the server MUST
- reply with a NO response. Such a reply SHOULD contain the
- NONEXISTENT response code.
-
- Examples:
-
- C: Setactive "vacationscript"
- S: Ok
-
- C: Setactive ""
- S: Ok
-
- C: Setactive "baz"
- S: No (NONEXISTENT) "There is no script by that name"
-
- C: Setactive "baz"
- S: No (NONEXISTENT) {31}
- S: There is no script by that name
-
-
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 24]
-
-RFC 5804 ManageSieve July 2010
-
-
-2.9. GETSCRIPT Command
-
- Arguments: String - script name
-
- This command gets the contents of the specified script. If the
- script does not exist, the server MUST reply with a NO response.
- Such a reply SHOULD contain the NONEXISTENT response code.
-
- Upon success, a string with the contents of the script is returned
- followed by an OK response.
-
- Example:
-
- C: Getscript "myscript"
- S: {54}
- S: #this is my wonderful script
- S: reject "I reject all";
- S:
- S: OK
-
-2.10. DELETESCRIPT Command
-
- Arguments: String - script name
-
- This command is used to delete a user's Sieve script. Servers MUST
- reply with a NO response if the script does not exist. Such
- responses SHOULD include the NONEXISTENT response code.
-
- The server MUST NOT allow the client to delete an active script, so
- the server MUST reply with a NO response if attempted. Such a
- response SHOULD contain the ACTIVE response code. If a client wishes
- to delete an active script, it should use the SETACTIVE command to
- disable the script first.
-
- Example:
-
- C: Deletescript "foo"
- S: Ok
-
- C: Deletescript "baz"
- S: No (ACTIVE) "You may not delete an active script"
-
-
-
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 25]
-
-RFC 5804 ManageSieve July 2010
-
-
-2.11. RENAMESCRIPT Command
-
- Arguments: String - Old Script name
- String - New Script name
-
- This command is used to rename a user's Sieve script. Servers MUST
- reply with a NO response if the old script does not exist (in which
- case the NONEXISTENT response code SHOULD be included), or a script
- with the new name already exists (in which case the ALREADYEXISTS
- response code SHOULD be included). Renaming the active script is
- allowed; the renamed script remains active.
-
- Example:
-
- C: Renamescript "foo" "bar"
- S: Ok
-
- C: Renamescript "baz" "bar"
- S: No "bar already exists"
-
- If the server doesn't support the RENAMESCRIPT command, the client
- can emulate it by performing the following steps:
-
- 1. List available scripts with LISTSCRIPTS. If the script with the
- new script name exists, then the client should ask the user
- whether to abort the operation, to replace the script (by issuing
- the DELETESCRIPT <newname> after that), or to choose a different
- name.
-
- 2. Download the old script with GETSCRIPT <oldname>.
-
- 3. Upload the old script with the new name: PUTSCRIPT <newname>.
-
- 4. If the old script was active (as reported by LISTSCRIPTS in step
- 1), then make the new script active: SETACTIVE <newname>.
-
- 5. Delete the old script: DELETESCRIPT <oldname>.
-
- Note that these steps don't describe how to handle various other
- error conditions (for example, NO response containing QUOTA response
- code in step 3). Error handling is left as an exercise for the
- reader.
-
-
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 26]
-
-RFC 5804 ManageSieve July 2010
-
-
-2.12. CHECKSCRIPT Command
-
- Arguments: String - Script content
-
- The CHECKSCRIPT command is used by the client to verify Sieve script
- validity without storing the script on the server.
-
- The server MUST check the submitted script for syntactic validity,
- which includes checking that all Sieve extensions mentioned in Sieve
- script "require" statement(s) are supported by the Sieve interpreter.
- (Note that if the Sieve interpreter supports the Sieve "ihave"
- extension [I-HAVE], any unrecognized/unsupported extension mentioned
- in the "ihave" test MUST NOT cause the syntactic validation failure.)
- If the script fails this test, the server MUST reply with a NO
- response. The message given with a NO response MUST be human
- readable and SHOULD contain a specific error message giving the line
- number of the first error. Implementors should strive to produce
- helpful error messages similar to those given by programming language
- compilers. Client implementations should note that this may be a
- multiline literal string with more than one error message separated
- by CRLFs. The human-readable message is in the language returned in
- the latest LANGUAGE capability (or in "i-default"; see Section 1.7),
- encoded in UTF-8 [UTF-8].
-
- Examples:
-
- C: CheckScript {31+}
- C: #comment
- C: InvalidSieveCommand
- C:
- S: NO "line 2: Syntax error"
-
- A ManageSieve server supporting this command MUST NOT check if the
- script will put the current user over its quota limit.
-
- An OK response MAY contain the WARNINGS response code. In such a
- case, the human-readable message that follows the OK response SHOULD
- contain a specific warning message (or messages) giving the line
- number(s) in the script that might contain errors not intended by the
- script writer. The human-readable message is in the language
- returned in the latest LANGUAGE capability (or in "i-default"; see
- Section 1.7), encoded in UTF-8 [UTF-8]. A client seeing such a
- response code SHOULD present the message to the user.
-
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 27]
-
-RFC 5804 ManageSieve July 2010
-
-
-2.13. NOOP Command
-
- Arguments: String - tag to echo back (optional)
-
- The NOOP command does nothing, beyond returning a response to the
- client. It may be used by clients for protocol re-synchronization or
- to reset any inactivity auto-logout timer on the server.
-
- The response to the NOOP command is always OK, followed by the TAG
- response code together with the supplied string. If no string was
- supplied in the NOOP command, the TAG response code MUST NOT be
- included.
-
- Examples:
-
- C: NOOP
- S: OK "NOOP completed"
-
- C: NOOP "STARTTLS-SYNC-42"
- S: OK (TAG {16}
- S: STARTTLS-SYNC-42) "Done"
-
-2.14. Recommended Extensions
-
- The UNAUTHENTICATE extension (advertised as the "UNAUTHENTICATE"
- capability with no parameters) defines a new UNAUTHENTICATE command,
- which allows a client to return the server to non-authenticated
- state. Support for this extension is RECOMMENDED.
-
-2.14.1. UNAUTHENTICATE Command
-
- The UNAUTHENTICATE command returns the server to the
- non-authenticated state. It doesn't affect any previously
- established TLS [TLS] or SASL (Section 2.1) security layer.
-
- The UNAUTHENTICATE command is only valid in authenticated state. If
- issued in a wrong state, the server MUST reject it with a NO
- response.
-
- The UNAUTHENTICATE command has no parameters.
-
- When issued in the authenticated state, the UNAUTHENTICATE command
- MUST NOT fail (i.e., it must never return anything other than OK or
- BYE).
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 28]
-
-RFC 5804 ManageSieve July 2010
-
-
-3. Sieve URL Scheme
-
- URI scheme name: sieve
-
- Status: permanent
-
- URI scheme syntax: Described using ABNF [ABNF]. Some ABNF
- productions not defined below are from [URI-GEN].
-
- sieveurl = sieveurl-server / sieveurl-list-scripts /
- sieveurl-script
-
- sieveurl-server = "sieve://" authority
-
- sieveurl-list-scripts = "sieve://" authority ["/"]
-
- sieveurl-script = "sieve://" authority "/"
- [owner "/"] scriptname
-
- authority = <defined in [URI-GEN]>
-
- owner = *ochar
- ;; %-encoded version of [SASL] authorization
- ;; identity (script owner) or "userid".
- ;;
- ;; Empty owner is used to reference
- ;; global scripts.
- ;;
- ;; Note that ASCII characters such as " ", ";",
- ;; "&", "=", "/" and "?" must be %-encoded
- ;; as per rule specified in [URI-GEN].
-
- scriptname = 1*ochar
- ;; %-encoded version of UTF-8 representation
- ;; of the script name.
- ;; Note that ASCII characters such as " ", ";",
- ;; "&", "=", "/" and "?" must be %-encoded
- ;; as per rule specified in [URI-GEN].
-
- ochar = unreserved / pct-encoded / sub-delims-sh /
- ":" / "@"
- ;; Same as [URI-GEN] 'pchar',
- ;; but without ";", "&" and "=".
-
- unreserved = <defined in [URI-GEN]>
-
- pct-encoded = <defined in [URI-GEN]>
-
-
-
-
-Melnikov & Martin Standards Track [Page 29]
-
-RFC 5804 ManageSieve July 2010
-
-
- sub-delims-sh = "!" / "$" / "'" / "(" / ")" /
- "*" / "+" / ","
- ;; Same as [URI-GEN] sub-delims,
- ;; but without ";", "&" and "=".
-
- URI scheme semantics:
-
- A Sieve URL identifies a Sieve server or a Sieve script on a Sieve
- server. The latter form is associated with the application/sieve
- MIME type defined in [SIEVE]. There is no MIME type associated
- with the former form of Sieve URI.
-
- The server form is used in the REFERRAL response code (see Section
- 1.3) in order to designate another server where the client should
- perform its operations.
-
- The script form allows to retrieve (GETSCRIPT), update
- (PUTSCRIPT), delete (DELETESCRIPT), or activate (SETACTIVE) the
- named script; however, the most typical action would be to
- retrieve the script. If the script name is empty (omitted), the
- URI requests that the client lists available scripts using the
- LISTSCRIPTS command.
-
- Encoding considerations:
-
- The script name and/or the owner, if present, is in UTF-8. Non--
- US-ASCII UTF-8 octets MUST be percent-encoded as described in
- [URI-GEN]. US-ASCII characters such as " " (space), ";", "&",
- "=", "/" and "?" MUST be %-encoded as described in [URI-GEN].
- Note that "&" and "?" are in this list in order to allow for
- future extensions.
-
- Note that the empty owner (e.g., sieve://example.com//script) is
- different from the missing owner (e.g.,
- sieve://example.com/script) and is reserved for referencing global
- scripts.
-
- The user name (in the "authority" part), if present, is in UTF-8.
- Non-US-ASCII UTF-8 octets MUST be percent-encoded as described in
- [URI-GEN].
-
- Applications/protocols that use this URI scheme name:
- ManageSieve [RFC5804] clients and servers. Clients that can store
- user preferences in protocols such as [LDAP] or [ACAP].
-
- Interoperability considerations: None.
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 30]
-
-RFC 5804 ManageSieve July 2010
-
-
- Security considerations:
- The <scriptname> part of a ManageSieve URL might potentially disclose
- some confidential information about the author of the script or,
- depending on a ManageSieve implementation, about configuration of the
- mail system. The latter might be used to prepare for a more complex
- attack on the mail system.
-
- Clients resolving ManageSieve URLs that wish to achieve data
- confidentiality and/or integrity SHOULD use the STARTTLS command (if
- supported by the server) before starting authentication, or use a
- SASL mechanism, such as GSSAPI, that provides a confidentiality
- security layer.
-
- Contact: Alexey Melnikov <alexey.melnikov@isode.com>
-
- Author/Change controller: IESG.
-
- References: This document and RFC 5228 [SIEVE].
-
-4. Formal Syntax
-
- The following syntax specification uses the Augmented Backus-Naur
- Form (BNF) notation as specified in [ABNF]. This uses the ABNF core
- rules as specified in Appendix A of the ABNF specification [ABNF].
- "UTF8-2", "UTF8-3", and "UTF8-4" non-terminal are defined in [UTF-8].
-
- Except as noted otherwise, all alphabetic characters are case-
- insensitive. The use of upper- or lowercase characters to define
- token strings is for editorial clarity only. Implementations MUST
- accept these strings in a case-insensitive fashion.
-
- SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B /
- %x5D-7F
- ;; any TEXT-CHAR except QUOTED-SPECIALS
-
- QUOTED-CHAR = SAFE-UTF8-CHAR / "\" QUOTED-SPECIALS
-
- QUOTED-SPECIALS = DQUOTE / "\"
-
- SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4
- ;; <UTF8-2>, <UTF8-3>, and <UTF8-4>
- ;; are defined in [UTF-8].
-
- ATOM-CHAR = "!" / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E
- ;; Any CHAR except ATOM-SPECIALS
-
- ATOM-SPECIALS = "(" / ")" / "{" / SP / CTL / QUOTED-SPECIALS
-
-
-
-
-Melnikov & Martin Standards Track [Page 31]
-
-RFC 5804 ManageSieve July 2010
-
-
- NZDIGIT = %x31-39
- ;; 1-9
-
- atom = 1*1024ATOM-CHAR
-
- iana-token = atom
- ;; MUST be registered with IANA
-
- auth-type = DQUOTE auth-type-name DQUOTE
-
- auth-type-name = iana-token
- ;; as defined in SASL [SASL]
-
- command = (command-any / command-auth /
- command-nonauth) CRLF
- ;; Modal based on state
-
- command-any = command-capability / command-logout /
- command-noop
- ;; Valid in all states
-
- command-auth = command-getscript / command-setactive /
- command-listscripts / command-deletescript /
- command-putscript / command-checkscript /
- command-havespace /
- command-renamescript /
- command-unauthenticate
- ;; Valid only in Authenticated state
-
- command-nonauth = command-authenticate / command-starttls
- ;; Valid only when in Non-Authenticated
- ;; state
-
- command-authenticate = "AUTHENTICATE" SP auth-type [SP string]
- *(CRLF string)
-
- command-capability = "CAPABILITY"
-
- command-deletescript = "DELETESCRIPT" SP sieve-name
-
- command-getscript = "GETSCRIPT" SP sieve-name
-
- command-havespace = "HAVESPACE" SP sieve-name SP number
-
- command-listscripts = "LISTSCRIPTS"
-
- command-noop = "NOOP" [SP string]
-
-
-
-
-Melnikov & Martin Standards Track [Page 32]
-
-RFC 5804 ManageSieve July 2010
-
-
- command-logout = "LOGOUT"
-
- command-putscript = "PUTSCRIPT" SP sieve-name SP sieve-script
-
- command-checkscript = "CHECKSCRIPT" SP sieve-script
-
- sieve-script = string
-
- command-renamescript = "RENAMESCRIPT" SP old-sieve-name SP
- new-sieve-name
-
- old-sieve-name = sieve-name
-
- new-sieve-name = sieve-name
-
- command-setactive = "SETACTIVE" SP active-sieve-name
-
- command-starttls = "STARTTLS"
-
- command-unauthenticate= "UNAUTHENTICATE"
-
- extend-token = atom
- ;; MUST be defined by a Standards Track or
- ;; IESG-approved experimental protocol
- ;; extension
-
- extension-data = extension-item *(SP extension-item)
-
- extension-item = extend-token / string / number /
- "(" [extension-data] ")"
-
- literal-c2s = "{" number "+}" CRLF *OCTET
- ;; The number represents the number of
- ;; octets.
- ;; This type of literal can only be sent
- ;; from the client to the server.
-
- literal-s2c = "{" number "}" CRLF *OCTET
- ;; Almost identical to literal-c2s,
- ;; but with no '+' character.
- ;; The number represents the number of
- ;; octets.
- ;; This type of literal can only be sent
- ;; from the server to the client.
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 33]
-
-RFC 5804 ManageSieve July 2010
-
-
- number = (NZDIGIT *DIGIT) / "0"
- ;; A 32-bit unsigned number
- ;; with no extra leading zeros.
- ;; (0 <= n < 4,294,967,296)
-
- number-str = string
- ;; <number> encoded as a <string>.
-
- quoted = DQUOTE *1024QUOTED-CHAR DQUOTE
- ;; limited to 1024 octets between the <">s
-
- resp-code = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" / "QUOTA"
- ["/" ("MAXSCRIPTS" / "MAXSIZE")] /
- resp-code-sasl /
- resp-code-referral /
- "TRANSITION-NEEDED" / "TRYLATER" /
- "ACTIVE" / "NONEXISTENT" /
- "ALREADYEXISTS" / "WARNINGS" /
- "TAG" SP string /
- resp-code-ext
-
- resp-code-referral = "REFERRAL" SP sieveurl
-
- resp-code-sasl = "SASL" SP string
-
- resp-code-name = iana-token
- ;; The response code name is hierarchical,
- ;; separated by '/'.
- ;; The response code name MUST NOT start
- ;; with '/'.
-
- resp-code-ext = resp-code-name [SP extension-data]
- ;; unknown response codes MUST be tolerated
- ;; by the client.
-
- response = response-authenticate /
- response-logout /
- response-getscript /
- response-setactive /
- response-listscripts /
- response-deletescript /
- response-putscript /
- response-checkscript /
- response-capability /
- response-havespace /
- response-starttls /
- response-renamescript /
- response-noop /
-
-
-
-Melnikov & Martin Standards Track [Page 34]
-
-RFC 5804 ManageSieve July 2010
-
-
- response-unauthenticate
-
- response-authenticate = *(string CRLF)
- ((response-ok [response-capability]) /
- response-nobye)
- ;; <response-capability> is REQUIRED if a
- ;; SASL security layer was negotiated and
- ;; MUST be omitted otherwise.
-
- response-capability = *(single-capability) response-oknobye
-
- single-capability = capability-name [SP string] CRLF
-
- capability-name = string
-
- ;; Note that literal-s2c is allowed.
-
- initial-capabilities = DQUOTE "IMPLEMENTATION" DQUOTE SP string /
- DQUOTE "SASL" DQUOTE SP sasl-mechs /
- DQUOTE "SIEVE" DQUOTE SP sieve-extensions /
- DQUOTE "MAXREDIRECTS" DQUOTE SP number-str /
- DQUOTE "NOTIFY" DQUOTE SP notify-mechs /
- DQUOTE "STARTTLS" DQUOTE /
- DQUOTE "LANGUAGE" DQUOTE SP language /
- DQUOTE "VERSION" DQUOTE SP version /
- DQUOTE "OWNER" DQUOTE SP string
- ;; Each capability conforms to
- ;; the syntax for single-capability.
- ;; Also, note that the capability name
- ;; can be returned as either literal-s2c
- ;; or quoted, even though only "quoted"
- ;; string is shown above.
-
- version = ( DQUOTE "1.0" DQUOTE ) / version-ext
-
- version-ext = DQUOTE ver-major "." ver-minor DQUOTE
- ; Future versions specified in updates
- ; to this document. An increment to
- ; the ver-major means a backward-incompatible
- ; change to the protocol, e.g., "3.5" (ver-major "3")
- ; is not backward-compatible with any "2.X" version.
- ; Any version "Z.W" MUST be backward compatible
- ; with any version "Z.Q", where Q < W.
- ; For example, version "2.4" is backward compatible
- ; with version "2.0", "2.1", "2.2", and "2.3".
-
- ver-major = number
-
-
-
-
-Melnikov & Martin Standards Track [Page 35]
-
-RFC 5804 ManageSieve July 2010
-
-
- ver-minor = number
-
- sasl-mechs = string
- ; Space-separated list of SASL mechanisms,
- ; each SASL mechanism name complies with rules
- ; specified in [SASL].
- ; Can be empty.
-
- sieve-extensions = string
- ; Space-separated list of supported SIEVE extensions.
- ; Can be empty.
-
- language = string
- ; Contains <Language-Tag> from [RFC5646].
-
-
- notify-mechs = string
- ; Space-separated list of URI schema parts
- ; for supported notification [NOTIFY] methods.
- ; MUST NOT be empty.
-
- response-deletescript = response-oknobye
-
- response-getscript = (sieve-script CRLF response-ok) /
- response-nobye
-
- response-havespace = response-oknobye
-
- response-listscripts = *(sieve-name [SP "ACTIVE"] CRLF)
- response-oknobye
- ;; ACTIVE may only occur with one sieve-name
-
- response-logout = response-oknobye
-
- response-unauthenticate= response-oknobye
- ;; "NO" response can only be returned when
- ;; the command is issued in a wrong state
- ;; or has a wrong number of parameters
-
- response-ok = "OK" [SP "(" resp-code ")"]
- [SP string] CRLF
- ;; The string contains human-readable text
- ;; encoded as UTF-8.
-
- response-nobye = ("NO" / "BYE") [SP "(" resp-code ")"]
- [SP string] CRLF
- ;; The string contains human-readable text
- ;; encoded as UTF-8.
-
-
-
-Melnikov & Martin Standards Track [Page 36]
-
-RFC 5804 ManageSieve July 2010
-
-
- response-oknobye = response-ok / response-nobye
-
- response-noop = response-ok
-
- response-putscript = response-oknobye
-
- response-checkscript = response-oknobye
-
- response-renamescript = response-oknobye
-
- response-setactive = response-oknobye
-
- response-starttls = (response-ok response-capability) /
- response-nobye
-
- sieve-name = string
- ;; See Section 1.6 for the full list of
- ;; prohibited characters.
- ;; Empty string is not allowed.
-
- active-sieve-name = string
- ;; See Section 1.6 for the full list of
- ;; prohibited characters.
- ;; This is similar to <sieve-name>, but
- ;; empty string is allowed and has a special
- ;; meaning.
-
- string = quoted / literal-c2s / literal-s2c
- ;; literal-c2s is only allowed when sent
- ;; from the client to the server.
- ;; literal-s2c is only allowed when sent
- ;; from the server to the client.
- ;; quoted is allowed in either direction.
-
-5. Security Considerations
-
- The AUTHENTICATE command uses SASL [SASL] to provide authentication
- and authorization services. Integrity and privacy services can be
- provided by [SASL] and/or [TLS]. When a SASL mechanism is used, the
- security considerations for that mechanism apply.
-
- This protocol's transactions are susceptible to passive observers or
- man-in-the-middle attacks that alter the data, unless the optional
- encryption and integrity services of the SASL (via the AUTHENTICATE
- command) and/or [TLS] (via the STARTTLS command) are enabled, or an
- external security mechanism is used for protection. It may be useful
- to allow configuration of both clients and servers to refuse to
- transfer sensitive information in the absence of strong encryption.
-
-
-
-Melnikov & Martin Standards Track [Page 37]
-
-RFC 5804 ManageSieve July 2010
-
-
- If an implementation supports SASL mechanisms that are vulnerable to
- passive eavesdropping attacks (such as [PLAIN]), then the
- implementation MUST support at least one configuration where these
- SASL mechanisms are not advertised or used without the presence of an
- external security layer such as [TLS].
-
- Some response codes returned on failed AUTHENTICATE command may
- disclose whether or not the username is valid (e.g., TRANSITION-
- NEEDED), so server implementations SHOULD provide the ability to
- disable these features (or make them not conditional on a per-user
- basis) for sites concerned about such disclosure. In the case of
- ENCRYPT-NEEDED, if it is applied to all identities then no extra
- information is disclosed, but if it is applied on a per-user basis it
- can disclose information.
-
- A compromised or malicious server can use the TRANSITION-NEEDED
- response code to force the client that is configured to use a
- mechanism that does not disclose the user's password to the server
- (e.g., Kerberos), to send the bare password to the server. Clients
- SHOULD have the ability to disable the password transition feature,
- or disclose that risk to the user and offer the user an option of how
- to proceed.
-
-6. IANA Considerations
-
- IANA has reserved TCP port number 4190 for use with the ManageSieve
- protocol described in this document.
-
- IANA has registered the "sieve" URI scheme defined in Section 3 of
- this document.
-
- IANA has registered "sieve" in the "GSSAPI/Kerberos/SASL Service
- Names" registry.
-
- IANA has created a new registry for ManageSieve capabilities. The
- registration template for ManageSieve capabilities is specified in
- Section 6.1. ManageSieve protocol capabilities MUST be specified in
- a Standards-Track or IESG-approved Experimental RFC.
-
- IANA has created a new registry for ManageSieve response codes. The
- registration template for ManageSieve response codes is specified in
- Section 6.3. ManageSieve protocol response codes MUST be specified
- in a Standards-Track or IESG-approved Experimental RFC.
-
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 38]
-
-RFC 5804 ManageSieve July 2010
-
-
-6.1. ManageSieve Capability Registration Template
-
- To: iana@iana.org
- Subject: ManageSieve Capability Registration
-
- Please register the following ManageSieve capability:
-
- Capability name:
- Description:
- Relevant publications:
- Person & email address to contact for further information:
- Author/Change controller:
-
-6.2. Registration of Initial ManageSieve Capabilities
-
- To: iana@iana.org
- Subject: ManageSieve Capability Registration
-
- Please register the following ManageSieve capabilities:
-
- Capability name: IMPLEMENTATION
- Description: Its value contains the name of the server
- implementation and its version.
- Relevant publications: this RFC, Section 1.7.
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
- Capability name: SASL
- Description: Its value contains a space-separated list of SASL
- mechanisms supported by the server.
- Relevant publications: this RFC, Sections 1.7 and 2.1.
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
- Capability name: SIEVE
- Description: Its value contains a space-separated list of supported
- SIEVE extensions.
- Relevant publications: this RFC, Section 1.7. Also [SIEVE].
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 39]
-
-RFC 5804 ManageSieve July 2010
-
-
- Capability name: STARTTLS
- Description: This capability is returned if the server supports TLS
- (STARTTLS command).
- Relevant publications: this RFC, Sections 1.7 and 2.2.
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
- Capability name: NOTIFY
- Description: This capability is returned if the server supports the
- 'enotify' [NOTIFY] Sieve extension.
- Relevant publications: this RFC, Section 1.7.
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
- Capability name: MAXREDIRECTS
- Description: This capability returns the limit on the number of
- Sieve "redirect" actions a script can perform during a
- single evaluation. The value is a non-negative number
- represented as a ManageSieve string.
- Relevant publications: this RFC, Section 1.7.
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
- Capability name: LANGUAGE
- Description: The language (<Language-Tag> from [RFC5646]) currently
- used for human-readable error messages.
- Relevant publications: this RFC, Section 1.7.
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
- Capability name: OWNER
- Description: Its value contains the UTF-8-encoded name of the
- currently logged-in user ("authorization identity"
- according to RFC 4422).
- Relevant publications: this RFC, Section 1.7.
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
-
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 40]
-
-RFC 5804 ManageSieve July 2010
-
-
- Capability name: VERSION
- Description: This capability is returned if the server is compliant
- with RFC 5804; i.e., that it supports RENAMESCRIPT,
- CHECKSCRIPT, and NOOP commands.
- Relevant publications: this RFC, Sections 2.11, 2.12, and 2.13.
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
-6.3. ManageSieve Response Code Registration Template
-
- To: iana@iana.org
- Subject: ManageSieve Response Code Registration
-
- Please register the following ManageSieve response code:
-
- Response Code:
- Arguments (use ABNF to specify syntax, or the word NONE if none
- can be specified):
- Purpose:
- Published Specification(s):
- Person & email address to contact for further information:
- Author/Change controller:
-
-6.4. Registration of Initial ManageSieve Response Codes
-
- To: iana@iana.org
- Subject: ManageSieve Response Code Registration
-
- Please register the following ManageSieve response codes:
-
- Response Code: AUTH-TOO-WEAK
- Arguments (use ABNF to specify syntax, or the word NONE if none can
- be specified): NONE
- Purpose: This response code is returned in the NO response from
- an AUTHENTICATE command. It indicates that site
- security policy forbids the use of the requested
- mechanism for the specified authentication identity.
- Published Specification(s): [RFC5804]
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
-
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 41]
-
-RFC 5804 ManageSieve July 2010
-
-
- Response Code: ENCRYPT-NEEDED
- Arguments (use ABNF to specify syntax, or the word NONE if none can
- be specified): NONE
- Purpose: This response code is returned in the NO response from
- an AUTHENTICATE command. It indicates that site
- security policy requires the use of a strong
- encryption mechanism for the specified authentication
- identity and mechanism.
- Published Specification(s): [RFC5804]
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
- Response Code: QUOTA
- Arguments (use ABNF to specify syntax, or the word NONE if none can
- be specified): NONE
- Purpose: If this response code is returned in the NO/BYE
- response, it means that the command would have placed
- the user above the site-defined quota constraints. If
- this response code is returned in the OK response, it
- can mean that the user is near its quota or that the
- user exceeded its quota, but the server supports soft
- quotas.
- Published Specification(s): [RFC5804]
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
- Response Code: QUOTA/MAXSCRIPTS
- Arguments (use ABNF to specify syntax, or the word NONE if none can
- be specified): NONE
- Purpose: If this response code is returned in the NO/BYE
- response, it means that the command would have placed
- the user above the site-defined limit on the number of
- Sieve scripts. If this response code is returned in
- the OK response, it can mean that the user is near its
- quota or that the user exceeded its quota, but the
- server supports soft quotas. This response code is a
- more specific version of the QUOTA response code.
- Published Specification(s): [RFC5804]
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 42]
-
-RFC 5804 ManageSieve July 2010
-
-
- Response Code: QUOTA/MAXSIZE
- Arguments (use ABNF to specify syntax, or the word NONE if none can
- be specified): NONE
- Purpose: If this response code is returned in the NO/BYE
- response, it means that the command would have placed
- the user above the site-defined maximum script size.
- If this response code is returned in the OK response,
- it can mean that the user is near its quota or that
- the user exceeded its quota, but the server supports
- soft quotas. This response code is a more specific
- version of the QUOTA response code.
- Published Specification(s): [RFC5804]
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
- Response Code: REFERRAL
- Arguments (use ABNF to specify syntax, or the word NONE if none can
- be specified): <sieveurl>
- Purpose: This response code may be returned with a BYE result
- from any command, and includes a mandatory parameter
- that indicates what server to access to manage this
- user's Sieve scripts. The server will be specified by
- a Sieve URL (see Section 3). The scriptname portion
- of the URL MUST NOT be specified. The client should
- authenticate to the specified server and use it for
- all further commands in the current session.
- Published Specification(s): [RFC5804]
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
- Response Code: SASL
- Arguments (use ABNF to specify syntax, or the word NONE if none can
- be specified): <string>
- Purpose: This response code can occur in the OK response to a
- successful AUTHENTICATE command and includes the
- optional final server response data from the server as
- specified by [SASL].
- Published Specification(s): [RFC5804]
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 43]
-
-RFC 5804 ManageSieve July 2010
-
-
- Response Code: TRANSITION-NEEDED
- Arguments (use ABNF to specify syntax, or the word NONE if none can
- be specified): NONE
- Purpose: This response code occurs in a NO response of an
- AUTHENTICATE command. It indicates that the user name
- is valid, but the entry in the authentication database
- needs to be updated in order to permit authentication
- with the specified mechanism. This is typically done
- by establishing a secure channel using TLS, followed
- by authenticating once using the [PLAIN]
- authentication mechanism. The selected mechanism
- SHOULD then work for authentications in subsequent
- sessions.
- Published Specification(s): [RFC5804]
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
- Response Code: TRYLATER
- Arguments (use ABNF to specify syntax, or the word NONE if none can
- be specified): NONE
- Purpose: A command failed due to a temporary server failure.
- The client MAY continue using local information and
- try the command later. This response code only make
- sense when returned in a NO/BYE response.
- Published Specification(s): [RFC5804]
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
- Response Code: ACTIVE
- Arguments (use ABNF to specify syntax, or the word NONE if none can
- be specified): NONE
- Purpose: A command failed because it is not allowed on the
- active script, for example, DELETESCRIPT on the active
- script. This response code only makes sense when
- returned in a NO/BYE response.
- Published Specification(s): [RFC5804]
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
-
-
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 44]
-
-RFC 5804 ManageSieve July 2010
-
-
- Response Code: NONEXISTENT
- Arguments (use ABNF to specify syntax, or the word NONE if none can
- be specified): NONE
- Purpose: A command failed because the referenced script name
- doesn't exist. This response code only makes sense
- when returned in a NO/BYE response.
- Published Specification(s): [RFC5804]
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
- Response Code: ALREADYEXISTS
- Arguments (use ABNF to specify syntax, or the word NONE if none can
- be specified): NONE
- Purpose: A command failed because the referenced script name
- already exists. This response code only makes sense
- when returned in a NO/BYE response.
- Published Specification(s): [RFC5804]
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
- Response Code: WARNINGS
- Arguments (use ABNF to specify syntax, or the word NONE if none can
- be specified): NONE
- Purpose: This response code MAY be returned by the server in
- the OK response (but it might be returned with the NO/
- BYE response as well) and signals the client that even
- though the script is syntactically valid, it might
- contain errors not intended by the script writer.
- Published Specification(s): [RFC5804]
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
- Response Code: TAG
- Arguments (use ABNF to specify syntax, or the word NONE if none can
- be specified): string
- Purpose: This response code name is followed by a string
- specified in the command that caused this response.
- It is typically used for client state synchronization.
- Published Specification(s): [RFC5804]
- Person & email address to contact for further information:
- Alexey Melnikov <alexey.melnikov@isode.com>
- Author/Change controller: IESG.
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 45]
-
-RFC 5804 ManageSieve July 2010
-
-
-7. Internationalization Considerations
-
- The LANGUAGE capability (see Section 1.7) allows a client to discover
- the current language used in all human-readable responses that might
- be returned at the end of any OK/NO/BYE response. Human-readable
- text in OK responses typically doesn't need to be shown to the user,
- unless it is returned in response to a PUTSCRIPT or CHECKSCRIPT
- command that also contains the WARNINGS response code (Section 1.3).
- Human-readable text from NO/BYE responses is intended be shown to the
- user, unless the client can automatically handle failure of the
- command that caused such a response. Clients SHOULD use response
- codes (Section 1.3) for automatic error handling. Response codes MAY
- also be used by the client to present error messages in a language
- understood by the user, for example, if the LANGUAGE capability
- doesn't return a language understood by the user.
-
- Note that the human-readable text from OK (WARNINGS) or NO/BYE
- responses for PUTSCRIPT/CHECKSCRIPT commands is intended for advanced
- users that understand Sieve language. Such advanced users are often
- sophisticated enough to be able to handle whatever language the
- server is using, even if it is not their preferred language, and will
- want to see error/warning text no matter what language the server
- puts it in.
-
- A client that generates Sieve script automatically, for example, if
- the script is generated without user intervention or from a UI that
- presents an abstract list of conditions and corresponding actions,
- SHOULD NOT present warning/error messages to the user, because the
- user might not even be aware that the client is using Sieve
- underneath. However, if the client has a debugging mode, such
- warnings/errors SHOULD be available in the debugging mode.
-
- Note that this document doesn't provide a way to modify the currently
- used language. It is expected that a future extension will address
- that.
-
-8. Acknowledgements
-
- Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris
- Newman, Lyndon Nerenberg, Tim Showalter, Sarah Robeson, Walter Wong,
- Barry Leiba, Arnt Gulbrandsen, Stephan Bosch, Ken Murchison, Phil
- Pennock, Ned Freed, Jeffrey Hutzelman, Mark E. Mallett, Dilyan
- Palauzov, Dave Cridland, Aaron Stone, Robert Burrell Donkin, Patrick
- Ben Koetter, Bjoern Hoehrmann, Martin Duerst, Pasi Eronen, Magnus
- Westerlund, Tim Polk, and Julien Coloos for help with this document.
- Special thank you to Phil Pennock for providing text for the NOOP
- command, as well as finding various bugs in the document.
-
-
-
-
-Melnikov & Martin Standards Track [Page 46]
-
-RFC 5804 ManageSieve July 2010
-
-
-9. References
-
-9.1. Normative References
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", STD 68, RFC 5234, January 2008.
-
- [ACAP] Newman, C. and J. Myers, "ACAP -- Application
- Configuration Access Protocol", RFC 2244, November
- 1997.
-
- [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
- Encodings", RFC 4648, October 2006.
-
- [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
- for specifying the location of services (DNS SRV)",
- RFC 2782, February 2000.
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [NET-UNICODE] Klensin, J. and M. Padlipsky, "Unicode Format for
- Network Interchange", RFC 5198, March 2008.
-
- [NOTIFY] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin,
- "Sieve Email Filtering: Extension for Notifications",
- RFC 5435, January 2009.
-
- [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
- Languages", BCP 18, RFC 2277, January 1998.
-
- [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
- 6 (IPv6) Specification", RFC 2460, December 1998.
-
- [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
- "Internationalizing Domain Names in Applications
- (IDNA)", RFC 3490, March 2003.
-
- [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol
- (LDAP): Schema for User Applications", RFC 4519, June
- 2006.
-
- [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
- Languages", BCP 47, RFC 5646, September 2009.
-
- [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
- September 1981.
-
-
-
-
-Melnikov & Martin Standards Track [Page 47]
-
-RFC 5804 ManageSieve July 2010
-
-
- [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication
- and Security Layer (SASL)", RFC 4422, June 2006.
-
- [SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User
- Names and Passwords", RFC 4013, February 2005.
-
- [SCRAM] Menon-Sen, A., Melnikov, A., Newman, C., and N.
- Williams, "Salted Challenge Response Authentication
- Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC
- 5802, July 2010.
-
- [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email
- Filtering Language", RFC 5228, January 2008.
-
- [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
- Internationalized Strings ("stringprep")", RFC 3454,
- December 2002.
-
- [TLS] Dierks, T. and E. Rescorla, "The Transport Layer
- Security (TLS) Protocol Version 1.2", RFC 5246, August
- 2008.
-
- [URI-GEN] Berners-Lee, T., Fielding, R., and L. Masinter,
- "Uniform Resource Identifier (URI): Generic Syntax",
- STD 66, RFC 3986, January 2005.
-
- [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", STD 63, RFC 3629, November 2003.
-
- [X509] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
- Housley, R., and W. Polk, "Internet X.509 Public Key
- Infrastructure Certificate and Certificate Revocation
- List (CRL) Profile", RFC 5280, May 2008.
-
- [X509-SRV] Santesson, S., "Internet X.509 Public Key
- Infrastructure Subject Alternative Name for Expression
- of Service Name", RFC 4985, August 2007.
-
-9.2. Informative References
-
- [DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication
- as a SASL Mechanism", RFC 2831, May 2000.
-
- [GSSAPI] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple
- Authentication and Security Layer (SASL) Mechanism",
- RFC 4752, November 2006.
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 48]
-
-RFC 5804 ManageSieve July 2010
-
-
- [I-HAVE] Freed, N., "Sieve Email Filtering: Ihave Extension",
- RFC 5463, March 2009.
-
- [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
- VERSION 4rev1", RFC 3501, March 2003.
-
- [LDAP] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP): Technical Specification Road Map", RFC 4510,
- June 2006.
-
- [PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and
- Security Layer (SASL) Mechanism", RFC 4616, August
- 2006.
-
-Authors' Addresses
-
- Alexey Melnikov (editor)
- Isode Limited
- 5 Castle Business Village
- 36 Station Road
- Hampton, Middlesex TW12 2BX
- UK
-
- EMail: Alexey.Melnikov@isode.com
-
-
- Tim Martin
- BeThereBeSquare, Inc.
- 672 Haight st.
- San Francisco, CA 94117
- USA
-
- Phone: +1 510 260-4175
- EMail: timmartin@alumni.cmu.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Melnikov & Martin Standards Track [Page 49]
-
diff --git a/doc/src/rfc977.txt b/doc/src/rfc977.txt
@@ -1,1539 +0,0 @@
-
-
-Network Working Group Brian Kantor (U.C. San Diego)
-Request for Comments: 977 Phil Lapsley (U.C. Berkeley)
- February 1986
-
- Network News Transfer Protocol
-
- A Proposed Standard for the Stream-Based
- Transmission of News
-
-Status of This Memo
-
- NNTP specifies a protocol for the distribution, inquiry, retrieval,
- and posting of news articles using a reliable stream-based
- transmission of news among the ARPA-Internet community. NNTP is
- designed so that news articles are stored in a central database
- allowing a subscriber to select only those items he wishes to read.
- Indexing, cross-referencing, and expiration of aged messages are also
- provided. This RFC suggests a proposed protocol for the ARPA-Internet
- community, and requests discussion and suggestions for improvements.
- Distribution of this memo is unlimited.
-
-1. Introduction
-
- For many years, the ARPA-Internet community has supported the
- distribution of bulletins, information, and data in a timely fashion
- to thousands of participants. We collectively refer to such items of
- information as "news". Such news provides for the rapid
- dissemination of items of interest such as software bug fixes, new
- product reviews, technical tips, and programming pointers, as well as
- rapid-fire discussions of matters of concern to the working computer
- professional. News is very popular among its readers.
-
- There are popularly two methods of distributing such news: the
- Internet method of direct mailing, and the USENET news system.
-
-1.1. Internet Mailing Lists
-
- The Internet community distributes news by the use of mailing lists.
- These are lists of subscriber's mailbox addresses and remailing
- sublists of all intended recipients. These mailing lists operate by
- remailing a copy of the information to be distributed to each
- subscriber on the mailing list. Such remailing is inefficient when a
- mailing list grows beyond a dozen or so people, since sending a
- separate copy to each of the subscribers occupies large quantities of
- network bandwidth, CPU resources, and significant amounts of disk
- storage at the destination host. There is also a significant problem
- in maintenance of the list itself: as subscribers move from one job
- to another; as new subscribers join and old ones leave; and as hosts
- come in and out of service.
-
-
-
-
-Kantor & Lapsley [Page 1]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-1.2. The USENET News System
-
- Clearly, a worthwhile reduction of the amount of these resources used
- can be achieved if articles are stored in a central database on the
- receiving host instead of in each subscriber's mailbox. The USENET
- news system provides a method of doing just this. There is a central
- repository of the news articles in one place (customarily a spool
- directory of some sort), and a set of programs that allow a
- subscriber to select those items he wishes to read. Indexing,
- cross-referencing, and expiration of aged messages are also provided.
-
-1.3. Central Storage of News
-
- For clusters of hosts connected together by fast local area networks
- (such as Ethernet), it makes even more sense to consolidate news
- distribution onto one (or a very few) hosts, and to allow access to
- these news articles using a server and client model. Subscribers may
- then request only the articles they wish to see, without having to
- wastefully duplicate the storage of a copy of each item on each host.
-
-1.4. A Central News Server
-
- A way to achieve these economies is to have a central computer system
- that can provide news service to the other systems on the local area
- network. Such a server would manage the collection of news articles
- and index files, with each person who desires to read news bulletins
- doing so over the LAN. For a large cluster of computer systems, the
- savings in total disk space is clearly worthwhile. Also, this allows
- workstations with limited disk storage space to participate in the
- news without incoming items consuming oppressive amounts of the
- workstation's disk storage.
-
- We have heard rumors of somewhat successful attempts to provide
- centralized news service using IBIS and other shared or distributed
- file systems. While it is possible that such a distributed file
- system implementation might work well with a group of similar
- computers running nearly identical operating systems, such a scheme
- is not general enough to offer service to a wide range of client
- systems, especially when many diverse operating systems may be in use
- among a group of clients. There are few (if any) shared or networked
- file systems that can offer the generality of service that stream
- connections using Internet TCP provide, particularly when a wide
- range of host hardware and operating systems are considered.
-
- NNTP specifies a protocol for the distribution, inquiry, retrieval,
- and posting of news articles using a reliable stream (such as TCP)
- server-client model. NNTP is designed so that news articles need only
-
-
-Kantor & Lapsley [Page 2]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- be stored on one (presumably central) host, and subscribers on other
- hosts attached to the LAN may read news articles using stream
- connections to the news host.
-
- NNTP is modelled upon the news article specifications in RFC 850,
- which describes the USENET news system. However, NNTP makes few
- demands upon the structure, content, or storage of news articles, and
- thus we believe it easily can be adapted to other non-USENET news
- systems.
-
- Typically, the NNTP server runs as a background process on one host,
- and would accept connections from other hosts on the LAN. This works
- well when there are a number of small computer systems (such as
- workstations, with only one or at most a few users each), and a large
- central server.
-
-1.5. Intermediate News Servers
-
- For clusters of machines with many users (as might be the case in a
- university or large industrial environment), an intermediate server
- might be used. This intermediate or "slave" server runs on each
- computer system, and is responsible for mediating news reading
- requests and performing local caching of recently-retrieved news
- articles.
-
- Typically, a client attempting to obtain news service would first
- attempt to connect to the news service port on the local machine. If
- this attempt were unsuccessful, indicating a failed server, an
- installation might choose to either deny news access, or to permit
- connection to the central "master" news server.
-
- For workstations or other small systems, direct connection to the
- master server would probably be the normal manner of operation.
-
- This specification does not cover the operation of slave NNTP
- servers. We merely suggest that slave servers are a logical addition
- to NNTP server usage which would enhance operation on large local
- area networks.
-
-1.6. News Distribution
-
- NNTP has commands which provide a straightforward method of
- exchanging articles between cooperating hosts. Hosts which are well
- connected on a local area or other fast network and who wish to
- actually obtain copies of news articles for local storage might well
- find NNTP to be a more efficient way to distribute news than more
- traditional transfer methods (such as UUCP).
-
-
-Kantor & Lapsley [Page 3]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- In the traditional method of distributing news articles, news is
- propagated from host to host by flooding - that is, each host will
- send all its new news articles on to each host that it feeds. These
- hosts will then in turn send these new articles on to other hosts
- that they feed. Clearly, sending articles that a host already has
- obtained a copy of from another feed (many hosts that receive news
- are redundantly fed) again is a waste of time and communications
- resources, but for transport mechanisms that are single-transaction
- based rather than interactive (such as UUCP in the UNIX-world <1>),
- distribution time is diminished by sending all articles and having
- the receiving host simply discard the duplicates. This is an
- especially true when communications sessions are limited to once a
- day.
-
- Using NNTP, hosts exchanging news articles have an interactive
- mechanism for deciding which articles are to be transmitted. A host
- desiring new news, or which has new news to send, will typically
- contact one or more of its neighbors using NNTP. First it will
- inquire if any new news groups have been created on the serving host
- by means of the NEWGROUPS command. If so, and those are appropriate
- or desired (as established by local site-dependent rules), those new
- newsgroups can be created.
-
- The client host will then inquire as to which new articles have
- arrived in all or some of the newsgroups that it desires to receive,
- using the NEWNEWS command. It will receive a list of new articles
- from the server, and can request transmission of those articles that
- it desires and does not already have.
-
- Finally, the client can advise the server of those new articles which
- the client has recently received. The server will indicate those
- articles that it has already obtained copies of, and which articles
- should be sent to add to its collection.
-
- In this manner, only those articles which are not duplicates and
- which are desired are transferred.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kantor & Lapsley [Page 4]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-2. The NNTP Specification
-
-2.1. Overview
-
- The news server specified by this document uses a stream connection
- (such as TCP) and SMTP-like commands and responses. It is designed
- to accept connections from hosts, and to provide a simple interface
- to the news database.
-
- This server is only an interface between programs and the news
- databases. It does not perform any user interaction or presentation-
- level functions. These "user-friendly" functions are better left to
- the client programs, which have a better understanding of the
- environment in which they are operating.
-
- When used via Internet TCP, the contact port assigned for this
- service is 119.
-
-2.2. Character Codes
-
- Commands and replies are composed of characters from the ASCII
- character set. When the transport service provides an 8-bit byte
- (octet) transmission channel, each 7-bit character is transmitted
- right justified in an octet with the high order bit cleared to zero.
-
-2.3. Commands
-
- Commands consist of a command word, which in some cases may be
- followed by a parameter. Commands with parameters must separate the
- parameters from each other and from the command by one or more space
- or tab characters. Command lines must be complete with all required
- parameters, and may not contain more than one command.
-
- Commands and command parameters are not case sensitive. That is, a
- command or parameter word may be upper case, lower case, or any
- mixture of upper and lower case.
-
- Each command line must be terminated by a CR-LF (Carriage Return -
- Line Feed) pair.
-
- Command lines shall not exceed 512 characters in length, counting all
- characters including spaces, separators, punctuation, and the
- trailing CR-LF (thus there are 510 characters maximum allowed for the
- command and its parameters). There is no provision for continuation
- command lines.
-
-
-
-
-Kantor & Lapsley [Page 5]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-2.4. Responses
-
- Responses are of two kinds, textual and status.
-
-2.4.1. Text Responses
-
- Text is sent only after a numeric status response line has been sent
- that indicates that text will follow. Text is sent as a series of
- successive lines of textual matter, each terminated with CR-LF pair.
- A single line containing only a period (.) is sent to indicate the
- end of the text (i.e., the server will send a CR-LF pair at the end
- of the last line of text, a period, and another CR-LF pair).
-
- If the text contained a period as the first character of the text
- line in the original, that first period is doubled. Therefore, the
- client must examine the first character of each line received, and
- for those beginning with a period, determine either that this is the
- end of the text or whether to collapse the doubled period to a single
- one.
-
- The intention is that text messages will usually be displayed on the
- user's terminal whereas command/status responses will be interpreted
- by the client program before any possible display is done.
-
-2.4.2. Status Responses
-
- These are status reports from the server and indicate the response to
- the last command received from the client.
-
- Status response lines begin with a 3 digit numeric code which is
- sufficient to distinguish all responses. Some of these may herald
- the subsequent transmission of text.
-
- The first digit of the response broadly indicates the success,
- failure, or progress of the previous command.
-
- 1xx - Informative message
- 2xx - Command ok
- 3xx - Command ok so far, send the rest of it.
- 4xx - Command was correct, but couldn't be performed for
- some reason.
- 5xx - Command unimplemented, or incorrect, or a serious
- program error occurred.
-
-
-
-
-
-
-Kantor & Lapsley [Page 6]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- The next digit in the code indicates the function response category.
-
- x0x - Connection, setup, and miscellaneous messages
- x1x - Newsgroup selection
- x2x - Article selection
- x3x - Distribution functions
- x4x - Posting
- x8x - Nonstandard (private implementation) extensions
- x9x - Debugging output
-
- The exact response codes that should be expected from each command
- are detailed in the description of that command. In addition, below
- is listed a general set of response codes that may be received at any
- time.
-
- Certain status responses contain parameters such as numbers and
- names. The number and type of such parameters is fixed for each
- response code to simplify interpretation of the response.
-
- Parameters are separated from the numeric response code and from each
- other by a single space. All numeric parameters are decimal, and may
- have leading zeros. All string parameters begin after the separating
- space, and end before the following separating space or the CR-LF
- pair at the end of the line. (String parameters may not, therefore,
- contain spaces.) All text, if any, in the response which is not a
- parameter of the response must follow and be separated from the last
- parameter by a space. Also, note that the text following a response
- number may vary in different implementations of the server. The
- 3-digit numeric code should be used to determine what response was
- sent.
-
- Response codes not specified in this standard may be used for any
- installation-specific additional commands also not specified. These
- should be chosen to fit the pattern of x8x specified above. (Note
- that debugging is provided for explicitly in the x9x response codes.)
- The use of unspecified response codes for standard commands is
- prohibited.
-
- We have provided a response pattern x9x for debugging. Since much
- debugging output may be classed as "informative messages", we would
- expect, therefore, that responses 190 through 199 would be used for
- various debugging outputs. There is no requirement in this
- specification for debugging output, but if such is provided over the
- connected stream, it must use these response codes. If appropriate
- to a specific implementation, other x9x codes may be used for
- debugging. (An example might be to use e.g., 290 to acknowledge a
- remote debugging request.)
-
-
-Kantor & Lapsley [Page 7]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-2.4.3. General Responses
-
- The following is a list of general response codes that may be sent by
- the NNTP server. These are not specific to any one command, but may
- be returned as the result of a connection, a failure, or some unusual
- condition.
-
- In general, 1xx codes may be ignored or displayed as desired; code
- 200 or 201 is sent upon initial connection to the NNTP server
- depending upon posting permission; code 400 will be sent when the
- NNTP server discontinues service (by operator request, for example);
- and 5xx codes indicate that the command could not be performed for
- some unusual reason.
-
- 100 help text
- 190
- through
- 199 debug output
-
- 200 server ready - posting allowed
- 201 server ready - no posting allowed
-
- 400 service discontinued
-
- 500 command not recognized
- 501 command syntax error
- 502 access restriction or permission denied
- 503 program fault - command not performed
-
-3. Command and Response Details
-
- On the following pages are descriptions of each command recognized by
- the NNTP server and the responses which will be returned by those
- commands.
-
- Each command is shown in upper case for clarity, although case is
- ignored in the interpretation of commands by the NNTP server. Any
- parameters are shown in lower case. A parameter shown in [square
- brackets] is optional. For example, [GMT] indicates that the
- triglyph GMT may present or omitted.
-
- Every command described in this section must be implemented by all
- NNTP servers.
-
-
-
-
-
-
-Kantor & Lapsley [Page 8]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- There is no prohibition against additional commands being added;
- however, it is recommended that any such unspecified command begin
- with the letter "X" to avoid conflict with later revisions of this
- specification.
-
- Implementors are reminded that such additional commands may not
- redefine specified status response codes. Using additional
- unspecified responses for standard commands is also prohibited.
-
-3.1. The ARTICLE, BODY, HEAD, and STAT commands
-
- There are two forms to the ARTICLE command (and the related BODY,
- HEAD, and STAT commands), each using a different method of specifying
- which article is to be retrieved. When the ARTICLE command is
- followed by a message-id in angle brackets ("<" and ">"), the first
- form of the command is used; when a numeric parameter or no parameter
- is supplied, the second form is invoked.
-
- The text of the article is returned as a textual response, as
- described earlier in this document.
-
- The HEAD and BODY commands are identical to the ARTICLE command
- except that they respectively return only the header lines or text
- body of the article.
-
- The STAT command is similar to the ARTICLE command except that no
- text is returned. When selecting by message number within a group,
- the STAT command serves to set the current article pointer without
- sending text. The returned acknowledgement response will contain the
- message-id, which may be of some value. Using the STAT command to
- select by message-id is valid but of questionable value, since a
- selection by message-id does NOT alter the "current article pointer".
-
-3.1.1. ARTICLE (selection by message-id)
-
- ARTICLE <message-id>
-
- Display the header, a blank line, then the body (text) of the
- specified article. Message-id is the message id of an article as
- shown in that article's header. It is anticipated that the client
- will obtain the message-id from a list provided by the NEWNEWS
- command, from references contained within another article, or from
- the message-id provided in the response to some other commands.
-
- Please note that the internally-maintained "current article pointer"
- is NOT ALTERED by this command. This is both to facilitate the
- presentation of articles that may be referenced within an article
-
-
-Kantor & Lapsley [Page 9]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- being read, and because of the semantic difficulties of determining
- the proper sequence and membership of an article which may have been
- posted to more than one newsgroup.
-
-3.1.2. ARTICLE (selection by number)
-
- ARTICLE [nnn]
-
- Displays the header, a blank line, then the body (text) of the
- current or specified article. The optional parameter nnn is the
-
- numeric id of an article in the current newsgroup and must be chosen
- from the range of articles provided when the newsgroup was selected.
- If it is omitted, the current article is assumed.
-
- The internally-maintained "current article pointer" is set by this
- command if a valid article number is specified.
-
- [the following applies to both forms of the article command.] A
- response indicating the current article number, a message-id string,
- and that text is to follow will be returned.
-
- The message-id string returned is an identification string contained
- within angle brackets ("<" and ">"), which is derived from the header
- of the article itself. The Message-ID header line (required by
- RFC850) from the article must be used to supply this information. If
- the message-id header line is missing from the article, a single
- digit "0" (zero) should be supplied within the angle brackets.
-
- Since the message-id field is unique with each article, it may be
- used by a news reading program to skip duplicate displays of articles
- that have been posted more than once, or to more than one newsgroup.
-
-3.1.3. Responses
-
- 220 n <a> article retrieved - head and body follow
- (n = article number, <a> = message-id)
- 221 n <a> article retrieved - head follows
- 222 n <a> article retrieved - body follows
- 223 n <a> article retrieved - request text separately
- 412 no newsgroup has been selected
- 420 no current article has been selected
- 423 no such article number in this group
- 430 no such article found
-
-
-
-
-
-Kantor & Lapsley [Page 10]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-3.2. The GROUP command
-
-3.2.1. GROUP
-
- GROUP ggg
-
- The required parameter ggg is the name of the newsgroup to be
- selected (e.g. "net.news"). A list of valid newsgroups may be
- obtained from the LIST command.
-
- The successful selection response will return the article numbers of
- the first and last articles in the group, and an estimate of the
- number of articles on file in the group. It is not necessary that
- the estimate be correct, although that is helpful; it must only be
- equal to or larger than the actual number of articles on file. (Some
- implementations will actually count the number of articles on file.
- Others will just subtract first article number from last to get an
- estimate.)
-
- When a valid group is selected by means of this command, the
- internally maintained "current article pointer" is set to the first
- article in the group. If an invalid group is specified, the
- previously selected group and article remain selected. If an empty
- newsgroup is selected, the "current article pointer" is in an
- indeterminate state and should not be used.
-
- Note that the name of the newsgroup is not case-dependent. It must
- otherwise match a newsgroup obtained from the LIST command or an
- error will result.
-
-3.2.2. Responses
-
- 211 n f l s group selected
- (n = estimated number of articles in group,
- f = first article number in the group,
- l = last article number in the group,
- s = name of the group.)
- 411 no such news group
-
-
-
-
-
-
-
-
-
-
-
-Kantor & Lapsley [Page 11]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-3.3. The HELP command
-
-3.3.1. HELP
-
- HELP
-
- Provides a short summary of commands that are understood by this
- implementation of the server. The help text will be presented as a
- textual response, terminated by a single period on a line by itself.
-
- 3.3.2. Responses
-
- 100 help text follows
-
-3.4. The IHAVE command
-
-3.4.1. IHAVE
-
- IHAVE <messageid>
-
- The IHAVE command informs the server that the client has an article
- whose id is <messageid>. If the server desires a copy of that
- article, it will return a response instructing the client to send the
- entire article. If the server does not want the article (if, for
- example, the server already has a copy of it), a response indicating
- that the article is not wanted will be returned.
-
- If transmission of the article is requested, the client should send
- the entire article, including header and body, in the manner
- specified for text transmission from the server. A response code
- indicating success or failure of the transferral of the article will
- be returned.
-
- This function differs from the POST command in that it is intended
- for use in transferring already-posted articles between hosts.
- Normally it will not be used when the client is a personal
- newsreading program. In particular, this function will invoke the
- server's news posting program with the appropriate settings (flags,
- options, etc) to indicate that the forthcoming article is being
- forwarded from another host.
-
- The server may, however, elect not to post or forward the article if
- after further examination of the article it deems it inappropriate to
- do so. The 436 or 437 error codes may be returned as appropriate to
- the situation.
-
- Reasons for such subsequent rejection of an article may include such
-
-
-Kantor & Lapsley [Page 12]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- problems as inappropriate newsgroups or distributions, disk space
- limitations, article lengths, garbled headers, and the like. These
- are typically restrictions enforced by the server host's news
- software and not necessarily the NNTP server itself.
-
-3.4.2. Responses
-
- 235 article transferred ok
- 335 send article to be transferred. End with <CR-LF>.<CR-LF>
- 435 article not wanted - do not send it
- 436 transfer failed - try again later
- 437 article rejected - do not try again
-
- An implementation note:
-
- Because some host news posting software may not be able to decide
- immediately that an article is inappropriate for posting or
- forwarding, it is acceptable to acknowledge the successful transfer
- of the article and to later silently discard it. Thus it is
- permitted to return the 235 acknowledgement code and later discard
- the received article. This is not a fully satisfactory solution to
- the problem. Perhaps some implementations will wish to send mail to
- the author of the article in certain of these cases.
-
-3.5. The LAST command
-
-3.5.1. LAST
-
- LAST
-
- The internally maintained "current article pointer" is set to the
- previous article in the current newsgroup. If already positioned at
- the first article of the newsgroup, an error message is returned and
- the current article remains selected.
-
- The internally-maintained "current article pointer" is set by this
- command.
-
- A response indicating the current article number, and a message-id
- string will be returned. No text is sent in response to this
- command.
-
-3.5.2. Responses
-
- 223 n a article retrieved - request text separately
- (n = article number, a = unique article id)
-
-
-
-Kantor & Lapsley [Page 13]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- 412 no newsgroup selected
- 420 no current article has been selected
- 422 no previous article in this group
-
-3.6. The LIST command
-
-3.6.1. LIST
-
- LIST
-
- Returns a list of valid newsgroups and associated information. Each
- newsgroup is sent as a line of text in the following format:
-
- group last first p
-
- where <group> is the name of the newsgroup, <last> is the number of
- the last known article currently in that newsgroup, <first> is the
- number of the first article currently in the newsgroup, and <p> is
- either 'y' or 'n' indicating whether posting to this newsgroup is
- allowed ('y') or prohibited ('n').
-
- The <first> and <last> fields will always be numeric. They may have
- leading zeros. If the <last> field evaluates to less than the
- <first> field, there are no articles currently on file in the
- newsgroup.
-
- Note that posting may still be prohibited to a client even though the
- LIST command indicates that posting is permitted to a particular
- newsgroup. See the POST command for an explanation of client
- prohibitions. The posting flag exists for each newsgroup because
- some newsgroups are moderated or are digests, and therefore cannot be
- posted to; that is, articles posted to them must be mailed to a
- moderator who will post them for the submitter. This is independent
- of the posting permission granted to a client by the NNTP server.
-
- Please note that an empty list (i.e., the text body returned by this
- command consists only of the terminating period) is a possible valid
- response, and indicates that there are currently no valid newsgroups.
-
-3.6.2. Responses
-
- 215 list of newsgroups follows
-
-
-
-
-
-
-
-Kantor & Lapsley [Page 14]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-3.7. The NEWGROUPS command
-
-3.7.1. NEWGROUPS
-
- NEWGROUPS date time [GMT] [<distributions>]
-
- A list of newsgroups created since <date and time> will be listed in
- the same format as the LIST command.
-
- The date is sent as 6 digits in the format YYMMDD, where YY is the
- last two digits of the year, MM is the two digits of the month (with
- leading zero, if appropriate), and DD is the day of the month (with
- leading zero, if appropriate). The closest century is assumed as
- part of the year (i.e., 86 specifies 1986, 30 specifies 2030, 99 is
- 1999, 00 is 2000).
-
- Time must also be specified. It must be as 6 digits HHMMSS with HH
- being hours on the 24-hour clock, MM minutes 00-59, and SS seconds
- 00-59. The time is assumed to be in the server's timezone unless the
- token "GMT" appears, in which case both time and date are evaluated
- at the 0 meridian.
-
- The optional parameter "distributions" is a list of distribution
- groups, enclosed in angle brackets. If specified, the distribution
- portion of a new newsgroup (e.g, 'net' in 'net.wombat') will be
- examined for a match with the distribution categories listed, and
- only those new newsgroups which match will be listed. If more than
- one distribution group is to be listed, they must be separated by
- commas within the angle brackets.
-
- Please note that an empty list (i.e., the text body returned by this
- command consists only of the terminating period) is a possible valid
- response, and indicates that there are currently no new newsgroups.
-
-3.7.2. Responses
-
- 231 list of new newsgroups follows
-
-
-
-
-
-
-
-
-
-
-
-
-Kantor & Lapsley [Page 15]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-3.8. The NEWNEWS command
-
-3.8.1. NEWNEWS
-
- NEWNEWS newsgroups date time [GMT] [<distribution>]
-
- A list of message-ids of articles posted or received to the specified
- newsgroup since "date" will be listed. The format of the listing will
- be one message-id per line, as though text were being sent. A single
- line consisting solely of one period followed by CR-LF will terminate
- the list.
-
- Date and time are in the same format as the NEWGROUPS command.
-
- A newsgroup name containing a "*" (an asterisk) may be specified to
- broaden the article search to some or all newsgroups. The asterisk
- will be extended to match any part of a newsgroup name (e.g.,
- net.micro* will match net.micro.wombat, net.micro.apple, etc). Thus
- if only an asterisk is given as the newsgroup name, all newsgroups
- will be searched for new news.
-
- (Please note that the asterisk "*" expansion is a general
- replacement; in particular, the specification of e.g., net.*.unix
- should be correctly expanded to embrace names such as net.wombat.unix
- and net.whocares.unix.)
-
- Conversely, if no asterisk appears in a given newsgroup name, only
- the specified newsgroup will be searched for new articles. Newsgroup
- names must be chosen from those returned in the listing of available
- groups. Multiple newsgroup names (including a "*") may be specified
- in this command, separated by a comma. No comma shall appear after
- the last newsgroup in the list. [Implementors are cautioned to keep
- the 512 character command length limit in mind.]
-
- The exclamation point ("!") may be used to negate a match. This can
- be used to selectively omit certain newsgroups from an otherwise
- larger list. For example, a newsgroups specification of
- "net.*,mod.*,!mod.map.*" would specify that all net.<anything> and
- all mod.<anything> EXCEPT mod.map.<anything> newsgroup names would be
- matched. If used, the exclamation point must appear as the first
- character of the given newsgroup name or pattern.
-
- The optional parameter "distributions" is a list of distribution
- groups, enclosed in angle brackets. If specified, the distribution
- portion of an article's newsgroup (e.g, 'net' in 'net.wombat') will
- be examined for a match with the distribution categories listed, and
- only those articles which have at least one newsgroup belonging to
-
-
-Kantor & Lapsley [Page 16]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- the list of distributions will be listed. If more than one
- distribution group is to be supplied, they must be separated by
- commas within the angle brackets.
-
- The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to distribute
- news is discussed in an earlier part of this document.
-
- Please note that an empty list (i.e., the text body returned by this
- command consists only of the terminating period) is a possible valid
- response, and indicates that there is currently no new news.
-
-3.8.2. Responses
-
- 230 list of new articles by message-id follows
-
-3.9. The NEXT command
-
-3.9.1. NEXT
-
- NEXT
-
- The internally maintained "current article pointer" is advanced to
- the next article in the current newsgroup. If no more articles
- remain in the current group, an error message is returned and the
- current article remains selected.
-
- The internally-maintained "current article pointer" is set by this
- command.
-
- A response indicating the current article number, and the message-id
- string will be returned. No text is sent in response to this
- command.
-
-3.9.2. Responses
-
- 223 n a article retrieved - request text separately
- (n = article number, a = unique article id)
- 412 no newsgroup selected
- 420 no current article has been selected
- 421 no next article in this group
-
-
-
-
-
-
-
-
-
-Kantor & Lapsley [Page 17]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-3.10. The POST command
-
-3.10.1. POST
-
- POST
-
- If posting is allowed, response code 340 is returned to indicate that
- the article to be posted should be sent. Response code 440 indicates
- that posting is prohibited for some installation-dependent reason.
-
- If posting is permitted, the article should be presented in the
- format specified by RFC850, and should include all required header
- lines. After the article's header and body have been completely sent
- by the client to the server, a further response code will be returned
- to indicate success or failure of the posting attempt.
-
- The text forming the header and body of the message to be posted
- should be sent by the client using the conventions for text received
- from the news server: A single period (".") on a line indicates the
- end of the text, with lines starting with a period in the original
- text having that period doubled during transmission.
-
- No attempt shall be made by the server to filter characters, fold or
- limit lines, or otherwise process incoming text. It is our intent
- that the server just pass the incoming message to be posted to the
- server installation's news posting software, which is separate from
- this specification. See RFC850 for more details.
-
- Since most installations will want the client news program to allow
- the user to prepare his message using some sort of text editor, and
- transmit it to the server for posting only after it is composed, the
- client program should take note of the herald message that greeted it
- when the connection was first established. This message indicates
- whether postings from that client are permitted or not, and can be
- used to caution the user that his access is read-only if that is the
- case. This will prevent the user from wasting a good deal of time
- composing a message only to find posting of the message was denied.
- The method and determination of which clients and hosts may post is
- installation dependent and is not covered by this specification.
-
-3.10.2. Responses
-
- 240 article posted ok
- 340 send article to be posted. End with <CR-LF>.<CR-LF>
- 440 posting not allowed
- 441 posting failed
-
-
-
-Kantor & Lapsley [Page 18]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- (for reference, one of the following codes will be sent upon initial
- connection; the client program should determine whether posting is
- generally permitted from these:) 200 server ready - posting allowed
- 201 server ready - no posting allowed
-
-3.11. The QUIT command
-
-3.11.1. QUIT
-
- QUIT
-
- The server process acknowledges the QUIT command and then closes the
- connection to the client. This is the preferred method for a client
- to indicate that it has finished all its transactions with the NNTP
- server.
-
- If a client simply disconnects (or the connection times out, or some
- other fault occurs), the server should gracefully cease its attempts
- to service the client.
-
-3.11.2. Responses
-
- 205 closing connection - goodbye!
-
-3.12. The SLAVE command
-
-3.12.1. SLAVE
-
- SLAVE
-
- Indicates to the server that this client connection is to a slave
- server, rather than a user.
-
- This command is intended for use in separating connections to single
- users from those to subsidiary ("slave") servers. It may be used to
- indicate that priority should therefore be given to requests from
- this client, as it is presumably serving more than one person. It
- might also be used to determine which connections to close when
- system load levels are exceeded, perhaps giving preference to slave
- servers. The actual use this command is put to is entirely
- implementation dependent, and may vary from one host to another. In
- NNTP servers which do not give priority to slave servers, this
- command must nonetheless be recognized and acknowledged.
-
-3.12.2. Responses
-
- 202 slave status noted
-
-
-Kantor & Lapsley [Page 19]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-4. Sample Conversations
-
- These are samples of the conversations that might be expected with
- the news server in hypothetical sessions. The notation C: indicates
- commands sent to the news server from the client program; S: indicate
- responses received from the server by the client.
-
-4.1. Example 1 - relative access with NEXT
-
- S: (listens at TCP port 119)
-
- C: (requests connection on TCP port 119)
- S: 200 wombatvax news server ready - posting ok
-
- (client asks for a current newsgroup list)
- C: LIST
- S: 215 list of newsgroups follows
- S: net.wombats 00543 00501 y
- S: net.unix-wizards 10125 10011 y
- (more information here)
- S: net.idiots 00100 00001 n
- S: .
-
- (client selects a newsgroup)
- C: GROUP net.unix-wizards
- S: 211 104 10011 10125 net.unix-wizards group selected
- (there are 104 articles on file, from 10011 to 10125)
-
- (client selects an article to read)
- C: STAT 10110
- S: 223 10110 <23445@sdcsvax.ARPA> article retrieved - statistics
- only (article 10110 selected, its message-id is
- <23445@sdcsvax.ARPA>)
-
- (client examines the header)
- C: HEAD
- S: 221 10110 <23445@sdcsvax.ARPA> article retrieved - head
- follows (text of the header appears here)
- S: .
-
- (client wants to see the text body of the article)
- C: BODY
- S: 222 10110 <23445@sdcsvax.ARPA> article retrieved - body
- follows (body text here)
- S: .
-
- (client selects next article in group)
-
-
-Kantor & Lapsley [Page 20]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- C: NEXT
- S: 223 10113 <21495@nudebch.uucp> article retrieved - statistics
- only (article 10113 was next in group)
-
- (client finishes session)
- C: QUIT
- S: 205 goodbye.
-
-4.2. Example 2 - absolute article access with ARTICLE
-
- S: (listens at TCP port 119)
-
- C: (requests connection on TCP port 119)
- S: 201 UCB-VAX netnews server ready -- no posting allowed
-
- C: GROUP msgs
- S: 211 103 402 504 msgs Your new group is msgs
- (there are 103 articles, from 402 to 504)
-
- C: ARTICLE 401
- S: 423 No such article in this newsgroup
-
- C: ARTICLE 402
- S: 220 402 <4105@ucbvax.ARPA> Article retrieved, text follows
- S: (article header and body follow)
- S: .
-
- C: HEAD 403
- S: 221 403 <3108@mcvax.UUCP> Article retrieved, header follows
- S: (article header follows)
- S: .
-
- C: QUIT
- S: 205 UCB-VAX news server closing connection. Goodbye.
-
-4.3. Example 3 - NEWGROUPS command
-
- S: (listens at TCP port 119)
-
- C: (requests connection on TCP port 119)
- S: 200 Imaginary Institute News Server ready (posting ok)
-
- (client asks for new newsgroups since April 3, 1985)
- C: NEWGROUPS 850403 020000
-
- S: 231 New newsgroups since 03/04/85 02:00:00 follow
-
-
-
-Kantor & Lapsley [Page 21]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- S: net.music.gdead
- S: net.games.sources
- S: .
-
- C: GROUP net.music.gdead
- S: 211 0 1 1 net.music.gdead Newsgroup selected
- (there are no articles in that newsgroup, and
- the first and last article numbers should be ignored)
-
- C: QUIT
- S: 205 Imaginary Institute news server ceasing service. Bye!
-
-4.4. Example 4 - posting a news article
-
- S: (listens at TCP port 119)
-
- C: (requests connection on TCP port 119)
- S: 200 BANZAIVAX news server ready, posting allowed.
-
- C: POST
- S: 340 Continue posting; Period on a line by itself to end
- C: (transmits news article in RFC850 format)
- C: .
- S: 240 Article posted successfully.
-
- C: QUIT
- S: 205 BANZAIVAX closing connection. Goodbye.
-
-4.5. Example 5 - interruption due to operator request
-
- S: (listens at TCP port 119)
-
- C: (requests connection on TCP port 119)
- S: 201 genericvax news server ready, no posting allowed.
-
- (assume normal conversation for some time, and
- that a newsgroup has been selected)
-
- C: NEXT
- S: 223 1013 <5734@mcvax.UUCP> Article retrieved; text separate.
-
- C: HEAD
- C: 221 1013 <5734@mcvax.UUCP> Article retrieved; head follows.
-
- S: (sends head of article, but halfway through is
- interrupted by an operator request. The following
- then occurs, without client intervention.)
-
-
-Kantor & Lapsley [Page 22]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- S: (ends current line with a CR-LF pair)
- S: .
- S: 400 Connection closed by operator. Goodbye.
- S: (closes connection)
-
-4.6. Example 6 - Using the news server to distribute news between
- systems.
-
- S: (listens at TCP port 119)
-
- C: (requests connection on TCP port 119)
- S: 201 Foobar NNTP server ready (no posting)
-
- (client asks for new newsgroups since 2 am, May 15, 1985)
- C: NEWGROUPS 850515 020000
- S: 235 New newsgroups since 850515 follow
- S: net.fluff
- S: net.lint
- S: .
-
- (client asks for new news articles since 2 am, May 15, 1985)
- C: NEWNEWS * 850515 020000
- S: 230 New news since 850515 020000 follows
- S: <1772@foo.UUCP>
- S: <87623@baz.UUCP>
- S: <17872@GOLD.CSNET>
- S: .
-
- (client asks for article <1772@foo.UUCP>)
- C: ARTICLE <1772@foo.UUCP>
- S: 220 <1772@foo.UUCP> All of article follows
- S: (sends entire message)
- S: .
-
- (client asks for article <87623@baz.UUCP>
- C: ARTICLE <87623@baz.UUCP>
- S: 220 <87623@baz.UUCP> All of article follows
- S: (sends entire message)
- S: .
-
- (client asks for article <17872@GOLD.CSNET>
- C: ARTICLE <17872@GOLD.CSNET>
- S: 220 <17872@GOLD.CSNET> All of article follows
- S: (sends entire message)
- S: .
-
-
-
-
-Kantor & Lapsley [Page 23]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- (client offers an article it has received recently)
- C: IHAVE <4105@ucbvax.ARPA>
- S: 435 Already seen that one, where you been?
-
- (client offers another article)
- C: IHAVE <4106@ucbvax.ARPA>
- S: 335 News to me! <CRLF.CRLF> to end.
- C: (sends article)
- C: .
- S: 235 Article transferred successfully. Thanks.
-
- (or)
-
- S: 436 Transfer failed.
-
- (client is all through with the session)
- C: QUIT
- S: 205 Foobar NNTP server bids you farewell.
-
-4.7. Summary of commands and responses.
-
- The following are the commands recognized and responses returned by
- the NNTP server.
-
-4.7.1. Commands
-
- ARTICLE
- BODY
- GROUP
- HEAD
- HELP
- IHAVE
- LAST
- LIST
- NEWGROUPS
- NEWNEWS
- NEXT
- POST
- QUIT
- SLAVE
- STAT
-
-4.7.2. Responses
-
- 100 help text follows
- 199 debug output
-
-
-
-Kantor & Lapsley [Page 24]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- 200 server ready - posting allowed
- 201 server ready - no posting allowed
- 202 slave status noted
- 205 closing connection - goodbye!
- 211 n f l s group selected
- 215 list of newsgroups follows
- 220 n <a> article retrieved - head and body follow 221 n <a> article
- retrieved - head follows
- 222 n <a> article retrieved - body follows
- 223 n <a> article retrieved - request text separately 230 list of new
- articles by message-id follows
- 231 list of new newsgroups follows
- 235 article transferred ok
- 240 article posted ok
-
- 335 send article to be transferred. End with <CR-LF>.<CR-LF>
- 340 send article to be posted. End with <CR-LF>.<CR-LF>
-
- 400 service discontinued
- 411 no such news group
- 412 no newsgroup has been selected
- 420 no current article has been selected
- 421 no next article in this group
- 422 no previous article in this group
- 423 no such article number in this group
- 430 no such article found
- 435 article not wanted - do not send it
- 436 transfer failed - try again later
- 437 article rejected - do not try again.
- 440 posting not allowed
- 441 posting failed
-
- 500 command not recognized
- 501 command syntax error
- 502 access restriction or permission denied
- 503 program fault - command not performed
-
-4.8. A Brief Word about the USENET News System
-
- In the UNIX world, which traditionally has been linked by 1200 baud
- dial-up telephone lines, the USENET News system has evolved to handle
- central storage, indexing, retrieval, and distribution of news. With
- the exception of its underlying transport mechanism (UUCP), USENET
- News is an efficient means of providing news and bulletin service to
- subscribers on UNIX and other hosts worldwide. The USENET News
-
-
-
-
-Kantor & Lapsley [Page 25]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- system is discussed in detail in RFC 850. It runs on most versions
- of UNIX and on many other operating systems, and is customarily
- distributed without charge.
-
- USENET uses a spooling area on the UNIX host to store news articles,
- one per file. Each article consists of a series of heading text,
- which contain the sender's identification and organizational
- affiliation, timestamps, electronic mail reply paths, subject,
- newsgroup (subject category), and the like. A complete news article
- is reproduced in its entirety below. Please consult RFC 850 for more
- details.
-
- Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site
- sdcsvax.UUCP
- Posting-Version: version B 2.10.1 6/24/83 SMI; site unitek.uucp
- Path:sdcsvax!sdcrdcf!hplabs!qantel!ihnp4!alberta!ubc-vision!unitek
- !honman
- From: honman@unitek.uucp (Man Wong)
- Newsgroups: net.unix-wizards
- Subject: foreground -> background ?
- Message-ID: <167@unitek.uucp>
- Date: 25 Sep 85 23:51:52 GMT
- Date-Received: 29 Sep 85 09:54:48 GMT
- Reply-To: honman@unitek.UUCP (Hon-Man Wong)
- Distribution: net.all
- Organization: Unitek Technologies Corporation
- Lines: 12
-
- I have a process (C program) which generates a child and waits for
- it to return. What I would like to do is to be able to run the
- child process interactively for a while before kicking itself into
- the background so I can return to the parent process (while the
- child process is RUNNING in the background). Can it be done? And
- if it can, how?
-
- Please reply by E-mail. Thanks in advance.
-
- Hon-Man Wong
-
-
-
-
-
-
-
-
-
-
-
-Kantor & Lapsley [Page 26]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-5. References
-
- [1] Crocker, D., "Standard for the Format of ARPA Internet Text
- Messages", RFC-822, Department of Electrical Engineering,
- University of Delaware, August, 1982.
-
- [2] Horton, M., "Standard for Interchange of USENET Messages",
- RFC-850, USENET Project, June, 1983.
-
- [3] Postel, J., "Transmission Control Protocol- DARPA Internet
- Program Protocol Specification", RFC-793, USC/Information
- Sciences Institute, September, 1981.
-
- [4] Postel, J., "Simple Mail Transfer Protocol", RFC-821,
- USC/Information Sciences Institute, August, 1982.
-
-6. Acknowledgements
-
- The authors wish to express their heartfelt thanks to those many
- people who contributed to this specification, and especially to Erik
- Fair and Chuq von Rospach, without whose inspiration this whole thing
- would not have been necessary.
-
-7. Notes
-
- <1> UNIX is a trademark of Bell Laboratories.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kantor & Lapsley [Page 27]
-
diff --git a/doc/src/ui_seperation.txt b/doc/src/ui_seperation.txt
@@ -1,54 +0,0 @@
-This is a table of old and new files to find functions when
-files have been splitted into several files for seperation
-
-old new state
-
-base64.[ch] common/base64.[ch] ok
-
-uuencode.[ch] common/uuencode.[ch] ok
-
-utils.[ch] common/utils.[ch] ok
- common/log.[ch] ok
-
-socket.[ch] common/socket.[ch] ok
-
-ssl.[ch] common/ssl.[ch] ok
-
-intl.h common/intl.h ok
-
-defs.h common/defs.h ok
-
-md5.[ch] common/md5.[ch] ok
-
-gtksctree.[ch] gtk/gtksctree.[ch] ok
-
-template.[ch] common/template.[ch] ok
-
-nntp.[ch] common/nntp.[ch] ok
-
-session.[ch] common/session.[ch] ok
-
-smtp.[ch] common/smtp.[ch] ok
-
-gtkstext.[ch] gtk/gtkstext.[ch] ok
-
-gtkshruler.[ch] gtk/gtkshruler.[ch] ok
-
-manage_window.[ch] gtk/manage_window.[ch] ok
-
-prefs.[ch] common/prefs.[ch]
- prefs_gtk.[ch] not completed
-
-menu.[ch] gtk/menu.[ch] ok
-
-stringtable.[ch] common/stringtable.[ch] ok
-
-gtkutils.[ch] gtk/gtkutils.[ch] ok
-
-about.[ch] gtk/about.[ch] ok
-
-colorlabel.[ch] gtk/colorlabel.[ch] ok
-
-filesel.[ch] gtk/filesel.[ch] ok
-
-gtkaspell.[ch] gtk/gtkaspell.[ch] ok
diff --git a/m4/README b/m4/README
@@ -1,6 +0,0 @@
-If you encountered errors like:
-
- aclocal: configure.in: ??: macro `AM_SOMETHING' not found in library
-
-when executing autogen.sh, copy the corresponding m4 files in the missing/
-directory into here (or install the development packages).
diff --git a/m4/gpgme.m4 b/m4/gpgme.m4
@@ -1,413 +0,0 @@
-# gpgme.m4 - autoconf macro to detect GPGME.
-# Copyright (C) 2002, 2003, 2004, 2014, 2018, 2022 g10 Code GmbH
-#
-# This file is free software; as a special exception the author gives
-# unlimited permission to copy and/or distribute it, with or without
-# modifications, as long as this notice is preserved.
-#
-# This file is distributed in the hope that it will be useful, but
-# WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
-# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-#
-# Last-changed: 2022-11-25
-
-
-dnl
-dnl Find gpgrt-config, which uses .pc file
-dnl (minimum pkg-config functionality, supporting cross build)
-dnl
-dnl _AM_PATH_GPGRT_CONFIG
-AC_DEFUN([_AM_PATH_GPGRT_CONFIG],[dnl
- AC_PATH_PROG(GPGRT_CONFIG, gpgrt-config, no, [$prefix/bin:$PATH])
- if test "$GPGRT_CONFIG" != "no"; then
- # Determine gpgrt_libdir
- #
- # Get the prefix of gpgrt-config assuming it's something like:
- # <PREFIX>/bin/gpgrt-config
- gpgrt_prefix=${GPGRT_CONFIG%/*/*}
- possible_libdir1=${gpgrt_prefix}/lib
- # Determine by using system libdir-format with CC, it's like:
- # Normal style: /usr/lib
- # GNU cross style: /usr/<triplet>/lib
- # Debian style: /usr/lib/<multiarch-name>
- # Fedora/openSUSE style: /usr/lib, /usr/lib32 or /usr/lib64
- # It is assumed that CC is specified to the one of host on cross build.
- if libdir_candidates=$(${CC:-cc} -print-search-dirs | \
- sed -n -e "/^libraries/{s/libraries: =//;s/:/\\
-/g;p;}"); then
- # From the output of -print-search-dirs, select valid pkgconfig dirs.
- libdir_candidates=$(for dir in $libdir_candidates; do
- if p=$(cd $dir 2>/dev/null && pwd); then
- test -d "$p/pkgconfig" && echo $p;
- fi
- done)
-
- for possible_libdir0 in $libdir_candidates; do
- # possible_libdir0:
- # Fallback candidate, the one of system-installed (by $CC)
- # (/usr/<triplet>/lib, /usr/lib/<multiarch-name> or /usr/lib32)
- # possible_libdir1:
- # Another candidate, user-locally-installed
- # (<gpgrt_prefix>/lib)
- # possible_libdir2
- # Most preferred
- # (<gpgrt_prefix>/<triplet>/lib,
- # <gpgrt_prefix>/lib/<multiarch-name> or <gpgrt_prefix>/lib32)
- if test "${possible_libdir0##*/}" = "lib"; then
- possible_prefix0=${possible_libdir0%/lib}
- possible_prefix0_triplet=${possible_prefix0##*/}
- if test -z "$possible_prefix0_triplet"; then
- continue
- fi
- possible_libdir2=${gpgrt_prefix}/$possible_prefix0_triplet/lib
- else
- possible_prefix0=${possible_libdir0%%/lib*}
- possible_libdir2=${gpgrt_prefix}${possible_libdir0#$possible_prefix0}
- fi
- if test -f ${possible_libdir2}/pkgconfig/gpg-error.pc; then
- gpgrt_libdir=${possible_libdir2}
- elif test -f ${possible_libdir1}/pkgconfig/gpg-error.pc; then
- gpgrt_libdir=${possible_libdir1}
- elif test -f ${possible_libdir0}/pkgconfig/gpg-error.pc; then
- gpgrt_libdir=${possible_libdir0}
- fi
- if test -n "$gpgrt_libdir"; then break; fi
- done
- if test -z "$libdir_candidates"; then
- # No valid pkgconfig dir in any of the system directories, fallback
- gpgrt_libdir=${possible_libdir1}
- fi
- else
- # When we cannot determine system libdir-format, use this:
- gpgrt_libdir=${possible_libdir1}
- fi
- else
- unset GPGRT_CONFIG
- fi
-
- if test -n "$gpgrt_libdir"; then
- GPGRT_CONFIG="$GPGRT_CONFIG --libdir=$gpgrt_libdir"
- if $GPGRT_CONFIG gpg-error >/dev/null 2>&1; then
- GPG_ERROR_CONFIG="$GPGRT_CONFIG gpg-error"
- AC_MSG_NOTICE([Use gpgrt-config with $gpgrt_libdir as gpg-error-config])
- gpg_error_config_version=`$GPG_ERROR_CONFIG --modversion`
- else
- unset GPGRT_CONFIG
- fi
- elif test "$GPG_ERROR_CONFIG" != "no"; then
- gpg_error_config_version=`$GPG_ERROR_CONFIG --version`
- unset GPGRT_CONFIG
- fi
-])
-
-AC_DEFUN([_AM_PATH_GPGME_CONFIG],[dnl
-AC_REQUIRE([_AM_PATH_GPGRT_CONFIG])dnl
- AC_ARG_WITH(gpgme-prefix,
- AS_HELP_STRING([--with-gpgme-prefix=PFX],
- [prefix where GPGME is installed (optional)]),
- gpgme_config_prefix="$withval", gpgme_config_prefix="")
- if test x"${GPGME_CONFIG}" = x ; then
- if test x"${gpgme_config_prefix}" != x ; then
- GPGME_CONFIG="${gpgme_config_prefix}/bin/gpgme-config"
- else
- case "${SYSROOT}" in
- /*)
- if test -x "${SYSROOT}/bin/gpgme-config" ; then
- GPGME_CONFIG="${SYSROOT}/bin/gpgme-config"
- fi
- ;;
- '')
- ;;
- *)
- AC_MSG_WARN([Ignoring \$SYSROOT as it is not an absolute path.])
- ;;
- esac
- fi
- fi
-
- use_gpgrt_config=""
- if test x"$GPGRT_CONFIG" != x -a "$GPGRT_CONFIG" != "no"; then
- if $GPGRT_CONFIG gpgme --exists; then
- GPGME_CONFIG="$GPGRT_CONFIG gpgme"
- AC_MSG_NOTICE([Use gpgrt-config as gpgme-config])
- use_gpgrt_config=yes
- fi
- fi
- if test -z "$use_gpgrt_config"; then
- AC_PATH_PROG(GPGME_CONFIG, gpgme-config, no)
- fi
-
- if test "$GPGME_CONFIG" != "no" ; then
- if test -z "$use_gpgrt_config"; then
- gpgme_version=`$GPGME_CONFIG --version`
- else
- gpgme_version=`$GPGME_CONFIG --modversion`
- fi
- fi
- gpgme_version_major=`echo $gpgme_version | \
- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\1/'`
- gpgme_version_minor=`echo $gpgme_version | \
- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\2/'`
- gpgme_version_micro=`echo $gpgme_version | \
- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\3/'`
-])
-
-
-AC_DEFUN([_AM_PATH_GPGME_CONFIG_HOST_CHECK],
-[
- if test -z "$use_gpgrt_config"; then
- gpgme_config_host=`$GPGME_CONFIG --host 2>/dev/null || echo none`
- else
- gpgme_config_host=`$GPGME_CONFIG --variable=host 2>/dev/null || echo none`
- fi
- if test x"$gpgme_config_host" != xnone ; then
- if test x"$gpgme_config_host" != x"$host" ; then
- AC_MSG_WARN([[
-***
-*** The config script "$GPGME_CONFIG" was
-*** built for $gpgme_config_host and thus may not match the
-*** used host $host.
-*** You may want to use the configure option --with-gpgme-prefix
-*** to specify a matching config script or use \$SYSROOT.
-***]])
- gpg_config_script_warn="$gpg_config_script_warn gpgme"
- fi
- fi
-])
-
-
-dnl AM_PATH_GPGME([MINIMUM-VERSION,
-dnl [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]])
-dnl Test for libgpgme and define GPGME_CFLAGS and GPGME_LIBS.
-dnl
-dnl If a prefix option is not used, the config script is first
-dnl searched in $SYSROOT/bin and then along $PATH. If the used
-dnl config script does not match the host specification the script
-dnl is added to the gpg_config_script_warn variable.
-dnl
-AC_DEFUN([AM_PATH_GPGME],
-[ AC_REQUIRE([_AM_PATH_GPGME_CONFIG])dnl
- tmp=ifelse([$1], ,1:0.4.2,$1)
- if echo "$tmp" | grep ':' >/dev/null 2>/dev/null ; then
- req_gpgme_api=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\1/'`
- min_gpgme_version=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\2/'`
- else
- req_gpgme_api=0
- min_gpgme_version="$tmp"
- fi
-
- AC_MSG_CHECKING(for GPGME - version >= $min_gpgme_version)
- ok=no
- if test "$GPGME_CONFIG" != "no" ; then
- req_major=`echo $min_gpgme_version | \
- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\1/'`
- req_minor=`echo $min_gpgme_version | \
- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\2/'`
- req_micro=`echo $min_gpgme_version | \
- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\3/'`
- if test "$gpgme_version_major" -gt "$req_major"; then
- ok=yes
- else
- if test "$gpgme_version_major" -eq "$req_major"; then
- if test "$gpgme_version_minor" -gt "$req_minor"; then
- ok=yes
- else
- if test "$gpgme_version_minor" -eq "$req_minor"; then
- if test "$gpgme_version_micro" -ge "$req_micro"; then
- ok=yes
- fi
- fi
- fi
- fi
- fi
- fi
- if test $ok = yes; then
- # If we have a recent GPGME, we should also check that the
- # API is compatible.
- if test "$req_gpgme_api" -gt 0 ; then
- if test -z "$use_gpgrt_config"; then
- tmp=`$GPGME_CONFIG --api-version 2>/dev/null || echo 0`
- else
- tmp=`$GPGME_CONFIG --variable=api_version 2>/dev/null || echo 0`
- fi
- if test "$tmp" -gt 0 ; then
- if test "$req_gpgme_api" -ne "$tmp" ; then
- ok=no
- fi
- fi
- fi
- fi
- if test $ok = yes; then
- GPGME_CFLAGS=`$GPGME_CONFIG --cflags`
- GPGME_LIBS=`$GPGME_CONFIG --libs`
- AC_MSG_RESULT(yes)
- ifelse([$2], , :, [$2])
- _AM_PATH_GPGME_CONFIG_HOST_CHECK
- else
- GPGME_CFLAGS=""
- GPGME_LIBS=""
- AC_MSG_RESULT(no)
- ifelse([$3], , :, [$3])
- fi
- AC_SUBST(GPGME_CFLAGS)
- AC_SUBST(GPGME_LIBS)
-])
-
-dnl AM_PATH_GPGME_PTHREAD([MINIMUM-VERSION,
-dnl [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]])
-dnl Test for libgpgme and define GPGME_PTHREAD_CFLAGS
-dnl and GPGME_PTHREAD_LIBS.
-dnl
-AC_DEFUN([AM_PATH_GPGME_PTHREAD],[
- AC_OBSOLETE([$0], [; use AM_PATH_GPGME instead to use GPGME_CFLAGS and GPGME_LIBS])dnl
- AC_REQUIRE([_AM_PATH_GPGME_CONFIG])dnl
- tmp=ifelse([$1], ,1:0.4.2,$1)
- if echo "$tmp" | grep ':' >/dev/null 2>/dev/null ; then
- req_gpgme_api=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\1/'`
- min_gpgme_version=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\2/'`
- else
- req_gpgme_api=0
- min_gpgme_version="$tmp"
- fi
-
- AC_MSG_CHECKING(for GPGME pthread - version >= $min_gpgme_version)
- ok=no
- if test "$GPGME_CONFIG" != "no" ; then
- req_major=`echo $min_gpgme_version | \
- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\1/'`
- req_minor=`echo $min_gpgme_version | \
- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\2/'`
- req_micro=`echo $min_gpgme_version | \
- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\3/'`
- if test "$gpgme_version_major" -gt "$req_major"; then
- ok=yes
- else
- if test "$gpgme_version_major" -eq "$req_major"; then
- if test "$gpgme_version_minor" -gt "$req_minor"; then
- ok=yes
- else
- if test "$gpgme_version_minor" -eq "$req_minor"; then
- if test "$gpgme_version_micro" -ge "$req_micro"; then
- ok=yes
- fi
- fi
- fi
- fi
- fi
- fi
- if test $ok = yes; then
- # If we have a recent GPGME, we should also check that the
- # API is compatible.
- if test "$req_gpgme_api" -gt 0 ; then
- if test -z "$use_gpgrt_config"; then
- tmp=`$GPGME_CONFIG --api-version 2>/dev/null || echo 0`
- else
- tmp=`$GPGME_CONFIG --variable=api_version 2>/dev/null || echo 0`
- fi
- if test "$tmp" -gt 0 ; then
- if test "$req_gpgme_api" -ne "$tmp" ; then
- ok=no
- fi
- fi
- fi
- fi
- if test $ok = yes; then
- GPGME_PTHREAD_CFLAGS=`$GPGME_CONFIG --cflags`
- GPGME_PTHREAD_LIBS=`$GPGME_CONFIG --libs`
- AC_MSG_RESULT(yes)
- ifelse([$2], , :, [$2])
- _AM_PATH_GPGME_CONFIG_HOST_CHECK
- else
- GPGME_PTHREAD_CFLAGS=""
- GPGME_PTHREAD_LIBS=""
- AC_MSG_RESULT(no)
- ifelse([$3], , :, [$3])
- fi
- AC_SUBST(GPGME_PTHREAD_CFLAGS)
- AC_SUBST(GPGME_PTHREAD_LIBS)
-])
-
-
-dnl AM_PATH_GPGME_GLIB([MINIMUM-VERSION,
-dnl [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]])
-dnl Test for libgpgme-glib and define GPGME_GLIB_CFLAGS and GPGME_GLIB_LIBS.
-dnl
-AC_DEFUN([AM_PATH_GPGME_GLIB],
-[ AC_REQUIRE([_AM_PATH_GPGME_CONFIG])dnl
- tmp=ifelse([$1], ,1:0.4.2,$1)
- if echo "$tmp" | grep ':' >/dev/null 2>/dev/null ; then
- req_gpgme_api=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\1/'`
- min_gpgme_version=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\2/'`
- else
- req_gpgme_api=0
- min_gpgme_version="$tmp"
- fi
-
- AC_MSG_CHECKING(for GPGME - version >= $min_gpgme_version)
- ok=no
- if test "$GPGME_CONFIG" != "no" ; then
- req_major=`echo $min_gpgme_version | \
- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\1/'`
- req_minor=`echo $min_gpgme_version | \
- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\2/'`
- req_micro=`echo $min_gpgme_version | \
- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\3/'`
- if test "$gpgme_version_major" -gt "$req_major"; then
- ok=yes
- else
- if test "$gpgme_version_major" -eq "$req_major"; then
- if test "$gpgme_version_minor" -gt "$req_minor"; then
- ok=yes
- else
- if test "$gpgme_version_minor" -eq "$req_minor"; then
- if test "$gpgme_version_micro" -ge "$req_micro"; then
- ok=yes
- fi
- fi
- fi
- fi
- fi
- fi
- if test $ok = yes; then
- # If we have a recent GPGME, we should also check that the
- # API is compatible.
- if test "$req_gpgme_api" -gt 0 ; then
- if test -z "$use_gpgrt_config"; then
- tmp=`$GPGME_CONFIG --api-version 2>/dev/null || echo 0`
- else
- tmp=`$GPGME_CONFIG --variable=api_version 2>/dev/null || echo 0`
- fi
- if test "$tmp" -gt 0 ; then
- if test "$req_gpgme_api" -ne "$tmp" ; then
- ok=no
- fi
- fi
- fi
- fi
- if test $ok = yes; then
- if test -z "$use_gpgrt_config"; then
- GPGME_GLIB_CFLAGS=`$GPGME_CONFIG --glib --cflags`
- GPGME_GLIB_LIBS=`$GPGME_CONFIG --glib --libs`
- else
- if $GPGRT_CONFIG gpgme-glib --exists; then
- GPGME_CONFIG="$GPGRT_CONFIG gpgme-glib"
- GPGME_GLIB_CFLAGS=`$GPGME_CONFIG --cflags`
- GPGME_GLIB_LIBS=`$GPGME_CONFIG --libs`
- else
- ok = no
- fi
- fi
- fi
- if test $ok = yes; then
- AC_MSG_RESULT(yes)
- ifelse([$2], , :, [$2])
- _AM_PATH_GPGME_CONFIG_HOST_CHECK
- else
- GPGME_GLIB_CFLAGS=""
- GPGME_GLIB_LIBS=""
- AC_MSG_RESULT(no)
- ifelse([$3], , :, [$3])
- fi
- AC_SUBST(GPGME_GLIB_CFLAGS)
- AC_SUBST(GPGME_GLIB_LIBS)
-])
diff --git a/m4/spamassassin.m4 b/m4/spamassassin.m4
@@ -1,76 +0,0 @@
-dnl check for libspamc required includes
-dnl Copyright (C) 2003 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.
-
-AC_DEFUN([AC_SPAMASSASSIN],
-[dnl
-
-AC_CHECK_HEADERS(sys/time.h syslog.h unistd.h errno.h sys/errno.h)
-AC_CHECK_HEADERS(time.h sysexits.h sys/socket.h netdb.h netinet/in.h)
-
-AC_CACHE_CHECK([for SHUT_RD],
- spamassassin_cv_has_shutrd, [
- AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <sys/types.h>
-#include <stdio.h>
-#include <sys/socket.h>]], [[printf ("%d", SHUT_RD); return 0;]])],[spamassassin_cv_has_shutrd=yes],[spamassassin_cv_has_shutrd=no]),
- ])
-if test $spamassassin_cv_has_shutrd = yes ; then
- AC_DEFINE(HAVE_SHUT_RD, 1, HAVE_SHUT_RD)
-fi
-
-dnl ----------------------------------------------------------------------
-
-AC_CHECK_FUNCS(socket strdup strtod strtol snprintf shutdown)
-
-dnl ----------------------------------------------------------------------
-
-AC_CACHE_CHECK([for h_errno],
- spamassassin_cv_has_herrno, [
- AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <netdb.h>
-#include <stdio.h>
-]], [[printf ("%d", h_errno); return 0;]])],[spamassassin_cv_has_herrno=yes],[spamassassin_cv_has_herrno=no]),
- ])
-if test $spamassassin_cv_has_herrno = yes ; then
- AC_DEFINE(HAVE_H_ERRNO, 1, HAVE_H_ERRNO)
-fi
-
-dnl ----------------------------------------------------------------------
-
-dnl ----------------------------------------------------------------------
-
-AC_CACHE_CHECK([for in_addr_t],
- spamassassin_cv_has_inaddrt, [
- AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <sys/types.h>
-#include <netinet/in.h>]], [[in_addr_t foo; return 0;]])],[spamassassin_cv_has_inaddrt=yes],[spamassassin_cv_has_inaddrt=no]),
- ])
-if test $spamassassin_cv_has_inaddrt = no ; then
- AC_CHECK_TYPE(in_addr_t, unsigned long)
-fi
-
-dnl ----------------------------------------------------------------------
-
-AC_CACHE_CHECK([for INADDR_NONE],
- spamassassin_cv_has_haveinaddrnone, [
- AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <sys/types.h>
-#include <netinet/in.h>]], [[in_addr_t foo = INADDR_NONE; return 0;]])],[spamassassin_cv_has_haveinaddrnone=yes],[spamassassin_cv_has_haveinaddrnone=no]),
- ])
-if test $spamassassin_cv_has_haveinaddrnone = yes ; then
- AC_DEFINE(HAVE_INADDR_NONE, 1, HAVE_INADDR_NONE)
-fi
-
-dnl ----------------------------------------------------------------------
-
-AC_CACHE_CHECK([for EX__MAX],
- spamassassin_cv_has_haveexmax, [
- AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#ifdef HAVE_SYSEXITS_H
-#include <sysexits.h>
-#endif
-#include <errno.h>]], [[int foo = EX__MAX; return 0;]])],[spamassassin_cv_has_haveexmax=yes],[spamassassin_cv_has_haveexmax=no]),
- ])
-if test $spamassassin_cv_has_haveexmax = yes ; then
- AC_DEFINE(HAVE_EX__MAX, 1, HAVE_EX__MAX)
-fi
-
-])
diff --git a/src/Makefile.am b/src/Makefile.am
@@ -3,19 +3,8 @@
# terms of the General Public License version 3 (or later).
# See COPYING file for license details.
-if CLAWS_LIBETPAN
-etpan_dir = etpan
-etpan_library = etpan/libclawsetpan.la
-else
-etpan_dir =
-etpan_library =
-endif
-SUBDIRS = common gtk $(etpan_dir) fence .
-if BUILD_TESTS
-include $(top_srcdir)/tests.mk
-SUBDIRS += tests
-endif
+SUBDIRS = common gtk etpan fence .
bin_PROGRAMS = claws-mail
@@ -470,6 +459,8 @@ claws_mail_LDFLAGS = \
# branch targets" which I think(?) trips up my shit code.
# https://www.openbsd.org/innovations.html
+etpan_library = etpan/libclawsetpan.la
+
claws_mail_DEPENDENCIES = $(claws_mail_deps) \
$(etpan_library) \
gtk/libclawsgtk.la
diff --git a/src/common/ssl.c b/src/common/ssl.c
@@ -42,9 +42,7 @@
GCRY_THREAD_OPTION_PTHREAD_IMPL;
#endif
-#ifdef HAVE_LIBETPAN
#include <libetpan/mailstream_ssl.h>
-#endif
#include <pthread.h>
@@ -243,9 +241,7 @@ void ssl_init(void)
#if GNUTLS_VERSION_NUMBER <= 0x020b00
gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread);
#endif
-#ifdef HAVE_LIBETPAN
mailstream_gnutls_init_not_required();
-#endif
gnutls_global_init();
}
diff --git a/src/etpan/etpan-ssl.c b/src/etpan/etpan-ssl.c
@@ -24,7 +24,6 @@
#endif
#ifdef USE_GNUTLS
-#ifdef HAVE_LIBETPAN
#include <libetpan/libetpan.h>
#include <libetpan/libetpan_version.h>
#include <gnutls/gnutls.h>
@@ -191,4 +190,3 @@ void etpan_connect_ssl_context_cb(struct mailstream_ssl_context * ssl_context, v
}
#endif /* USE_GNUTLS */
-#endif /* HAVE_LIBETPAN */
diff --git a/src/etpan/etpan-ssl.h b/src/etpan/etpan-ssl.h
@@ -26,7 +26,6 @@
#endif
#ifdef USE_GNUTLS
-#ifdef HAVE_LIBETPAN
#include <libetpan/libetpan.h>
@@ -34,6 +33,5 @@ gboolean etpan_certificate_check(mailstream *imap_stream, const char *host, gint
void etpan_connect_ssl_context_cb(struct mailstream_ssl_context * ssl_context, void * data);
#endif /* USE_GNUTLS */
-#endif /* HAVE_LIBETPAN */
#endif /* __ETPAN_SSL_H__ */
diff --git a/src/etpan/etpan-thread-manager.c b/src/etpan/etpan-thread-manager.c
@@ -22,8 +22,6 @@
#include "claws-features.h"
#endif
-#ifdef HAVE_LIBETPAN
-
#include "etpan-thread-manager.h"
#include <glib.h>
@@ -647,4 +645,3 @@ void etpan_thread_manager_join(struct etpan_thread_manager * manager)
etpan_thread_manager_loop(manager);
}
}
-#endif
diff --git a/src/etpan/imap-thread.c b/src/etpan/imap-thread.c
@@ -21,8 +21,6 @@
#include "claws-features.h"
#endif
-#ifdef HAVE_LIBETPAN
-
#include <glib.h>
#include <glib/gi18n.h>
#include "imap-thread.h"
@@ -3536,21 +3534,3 @@ void imap_threaded_cancel(Folder * folder)
if (imap && imap->imap_stream != NULL)
mailstream_cancel(imap->imap_stream);
}
-
-#else
-
-void imap_main_init(void)
-{
-}
-void imap_main_done(gboolean have_connectivity)
-{
-}
-void imap_main_set_timeout(int sec)
-{
-}
-
-void imap_threaded_cancel(Folder * folder);
-{
-}
-
-#endif
diff --git a/src/etpan/nntp-thread.c b/src/etpan/nntp-thread.c
@@ -21,8 +21,6 @@
#include "claws-features.h"
#endif
-#ifdef HAVE_LIBETPAN
-
#include <glib.h>
#include <glib/gi18n.h>
#include "nntp-thread.h"
@@ -1064,21 +1062,3 @@ void nntp_main_set_timeout(int sec)
mailstream_network_delay.tv_sec = sec;
mailstream_network_delay.tv_usec = 0;
}
-
-#else
-
-void nntp_main_init(void)
-{
-}
-void nntp_main_done(gboolean have_connectivity)
-{
-}
-void nntp_main_set_timeout(int sec)
-{
-}
-
-void nntp_threaded_cancel(Folder * folder);
-{
-}
-
-#endif
diff --git a/src/fence/Makefile b/src/fence/Makefile
@@ -2,3 +2,6 @@ all: zig-out/lib/libfence.a
zig-out/lib/libfence.a: build.zig src/root.zig src/fence.h
zig build
+
+clean:
+ rm -rf zig-out
diff --git a/src/gtk/about.c b/src/gtk/about.c
@@ -408,11 +408,7 @@ static GtkWidget *about_create_child_page_features(void)
gtk_text_buffer_insert(buffer, &iter,
(gchar *)C_("iconv", "allows converting to and from different character sets\n"), -1);
-#if HAVE_LIBETPAN
gtk_text_buffer_insert_pixbuf(buffer, &iter, active_pixbuf);
-#else
- gtk_text_buffer_insert_pixbuf(buffer, &iter, inactive_pixbuf);
-#endif
gtk_text_buffer_insert_with_tags_by_name(buffer, &iter, (" libetpan "), -1,
"bold", NULL);
gtk_text_buffer_insert(buffer, &iter,
diff --git a/src/imap.c b/src/imap.c
@@ -33,8 +33,6 @@
#include "xml.h"
#include "alertpanel.h"
-#ifdef HAVE_LIBETPAN
-
#include <stdlib.h>
#include <unistd.h>
#include <ctype.h>
@@ -333,9 +331,7 @@ static gchar *imap_get_real_path (IMAPSession *session,
IMAPFolder *folder,
const gchar *path,
gint *ok);
-#ifdef HAVE_LIBETPAN
static void imap_synchronise (FolderItem *item, gint days);
-#endif
static gboolean imap_is_busy (Folder *folder);
static void imap_free_capabilities (IMAPSession *session);
@@ -5882,105 +5878,6 @@ static gboolean imap_is_busy(Folder *folder)
return imap_session->busy;
}
-#else /* HAVE_LIBETPAN */
-
-static FolderClass imap_class;
-
-static XMLTag *imap_item_get_xml(Folder *folder, FolderItem *item);
-static void imap_item_set_xml(Folder *folder, FolderItem *item, XMLTag *tag);
-
-static Folder *imap_folder_new (const gchar *name,
- const gchar *path)
-{
- static gboolean missing_imap_warning = TRUE;
- if (missing_imap_warning) {
- missing_imap_warning = FALSE;
- alertpanel_error(
- _("You have one or more IMAP accounts "
- "defined. However this version of "
- "Claws Mail has been built without "
- "IMAP support; your IMAP accounts are "
- "disabled.\n\n"
- "You probably need to "
- "install libetpan and recompile "
- "Claws Mail."));
- }
- return NULL;
-}
-static gint imap_create_tree (Folder *folder)
-{
- return -1;
-}
-static FolderItem *imap_create_folder (Folder *folder,
- FolderItem *parent,
- const gchar *name)
-{
- return NULL;
-}
-static gint imap_rename_folder (Folder *folder,
- FolderItem *item,
- const gchar *name)
-{
- return -1;
-}
-
-gchar imap_get_path_separator_for_item(FolderItem *item)
-{
- return '/';
-}
-
-FolderClass *imap_get_class(void)
-{
- if (imap_class.idstr == NULL) {
- imap_class.type = F_IMAP;
- imap_class.idstr = "imap";
- imap_class.uistr = "IMAP";
-
- imap_class.new_folder = imap_folder_new;
- imap_class.create_tree = imap_create_tree;
- imap_class.create_folder = imap_create_folder;
- imap_class.rename_folder = imap_rename_folder;
-
- imap_class.set_xml = folder_set_xml;
- imap_class.get_xml = folder_get_xml;
- imap_class.item_set_xml = imap_item_set_xml;
- imap_class.item_get_xml = imap_item_get_xml;
- /* nothing implemented */
- }
-
- return &imap_class;
-}
-
-void imap_disconnect_all(gboolean have_connectivity)
-{
-}
-
-gint imap_subscribe(Folder *folder, FolderItem *item, gchar *rpath, gboolean sub)
-{
- return -1;
-}
-
-GList * imap_scan_subtree(Folder *folder, FolderItem *item, gboolean unsubs_only, gboolean recursive)
-{
- return NULL;
-}
-
-void imap_cache_msg(FolderItem *item, gint msgnum)
-{
-}
-
-void imap_cancel_all(void)
-{
-}
-
-gboolean imap_cancel_all_enabled(void)
-{
- return FALSE;
-}
-
-#endif
-
-#ifdef HAVE_LIBETPAN
static void imap_synchronise(FolderItem *item, gint days)
{
if (IMAP_FOLDER_ITEM(item)->last_sync == IMAP_FOLDER_ITEM(item)->last_change) {
@@ -5991,16 +5888,12 @@ static void imap_synchronise(FolderItem *item, gint days)
imap_gtk_synchronise(item, days);
IMAP_FOLDER_ITEM(item)->last_sync = IMAP_FOLDER_ITEM(item)->last_change;
}
-#endif
static void imap_item_set_xml(Folder *folder, FolderItem *item, XMLTag *tag)
{
-#ifdef HAVE_LIBETPAN
GList *cur;
-#endif
folder_item_set_xml(folder, item, tag);
-#ifdef HAVE_LIBETPAN
for (cur = tag->attr; cur != NULL; cur = g_list_next(cur)) {
XMLAttr *attr = (XMLAttr *) cur->data;
@@ -6014,7 +5907,6 @@ static void imap_item_set_xml(Folder *folder, FolderItem *item, XMLTag *tag)
}
if (IMAP_FOLDER_ITEM(item)->last_change == 0)
IMAP_FOLDER_ITEM(item)->last_change = time(NULL);
-#endif
}
static XMLTag *imap_item_get_xml(Folder *folder, FolderItem *item)
@@ -6023,15 +5915,12 @@ static XMLTag *imap_item_get_xml(Folder *folder, FolderItem *item)
tag = folder_item_get_xml(folder, item);
-#ifdef HAVE_LIBETPAN
xml_tag_add_attr(tag, xml_attr_new_int("uidnext",
IMAP_FOLDER_ITEM(item)->uid_next));
xml_tag_add_attr(tag, xml_attr_new_time_t("last_sync",
IMAP_FOLDER_ITEM(item)->last_sync));
xml_tag_add_attr(tag, xml_attr_new_time_t("last_change",
IMAP_FOLDER_ITEM(item)->last_change));
-
-#endif
return tag;
}
diff --git a/src/main.c b/src/main.c
@@ -109,10 +109,8 @@
#include "oauth2.h"
#endif
-#ifdef HAVE_LIBETPAN
#include "imap-thread.h"
#include "nntp-thread.h"
-#endif
#include "stock_pixmap.h"
#ifdef USE_GNUTLS
# include "ssl.h"
@@ -396,12 +394,10 @@ static void main_dump_features_list(gboolean show_debug_only)
else
g_print(" iconv\n");
#endif
-#if HAVE_LIBETPAN
if (show_debug_only)
debug_print(" libetpan %d.%d\n", LIBETPAN_VERSION_MAJOR, LIBETPAN_VERSION_MINOR);
else
g_print(" libetpan %d.%d\n", LIBETPAN_VERSION_MAJOR, LIBETPAN_VERSION_MINOR);
-#endif
}
int main(int argc, char *argv[])
@@ -576,11 +572,9 @@ int main(int argc, char *argv[])
exit(201);
}
-#ifdef HAVE_LIBETPAN
imap_main_init(prefs_common.skip_ssl_cert_check);
imap_main_set_timeout(prefs_common.io_timeout_secs);
nntp_main_init(prefs_common.skip_ssl_cert_check);
-#endif
/* If we can't read a folder list or don't have accounts,
* it means the configuration's not done. Either this is
* a brand new install, a failed/refused migration,
@@ -822,10 +816,8 @@ static void exit_claws(MainWindow *mainwin)
close_log_file(LOG_PROTOCOL);
close_log_file(LOG_DEBUG_FILTERING);
-#ifdef HAVE_LIBETPAN
imap_main_done(TRUE);
nntp_main_done(TRUE);
-#endif
lock_socket_remove();
diff --git a/src/prefs_account.c b/src/prefs_account.c
@@ -4942,15 +4942,6 @@ static void prefs_account_protocol_set_optmenu(PrefParam *pparam)
g_free(label);
gtk_widget_hide(optmenu);
gtk_widget_show(optlabel);
-#ifndef HAVE_LIBETPAN
- if (protocol == A_IMAP4 || protocol == A_NNTP) {
- gtk_widget_show(protocol_optmenu->no_imap_warn_icon);
- gtk_widget_show(protocol_optmenu->no_imap_warn_label);
- } else {
- gtk_widget_hide(protocol_optmenu->no_imap_warn_icon);
- gtk_widget_hide(protocol_optmenu->no_imap_warn_label);
- }
-#endif
if (protocol == A_IMAP4) {
if (new_account)
gtk_toggle_button_set_active(
@@ -5306,13 +5297,8 @@ static void prefs_account_protocol_changed(GtkComboBox *combobox, gpointer data)
switch(protocol) {
case A_NNTP:
-#ifndef HAVE_LIBETPAN
- gtk_widget_show(protocol_optmenu->no_imap_warn_icon);
- gtk_widget_show(protocol_optmenu->no_imap_warn_label);
-#else
gtk_widget_hide(protocol_optmenu->no_imap_warn_icon);
gtk_widget_hide(protocol_optmenu->no_imap_warn_label);
-#endif
gtk_widget_show(send_page.msgid_checkbtn);
gtk_widget_show(send_page.xmailer_checkbtn);
gtk_widget_show(basic_page.nntpserv_label);
@@ -5471,10 +5457,6 @@ static void prefs_account_protocol_changed(GtkComboBox *combobox, gpointer data)
gtk_widget_hide(receive_page.imap_batch_size_spinbtn);
break;
case A_IMAP4:
-#ifndef HAVE_LIBETPAN
- gtk_widget_show(protocol_optmenu->no_imap_warn_icon);
- gtk_widget_show(protocol_optmenu->no_imap_warn_label);
-#endif
if (new_account)
gtk_toggle_button_set_active(
GTK_TOGGLE_BUTTON(send_page.msgid_checkbtn),
diff --git a/src/prefs_other.c b/src/prefs_other.c
@@ -39,9 +39,7 @@
#include "combobox.h"
#include "manage_window.h"
-#ifdef HAVE_LIBETPAN
#include "imap-thread.h"
-#endif
#include "file-utils.h"
@@ -524,9 +522,7 @@ static void prefs_other_save(PrefsPage *_page)
prefs_common.io_timeout_secs = gtk_spin_button_get_value_as_int(
GTK_SPIN_BUTTON(page->spinbtn_iotimeout));
sock_set_io_timeout(prefs_common.io_timeout_secs);
-#ifdef HAVE_LIBETPAN
imap_main_set_timeout(prefs_common.io_timeout_secs);
-#endif
prefs_common.trans_hdr = gtk_toggle_button_get_active(
GTK_TOGGLE_BUTTON(page->checkbtn_transhdr));
prefs_common.real_time_sync =
diff --git a/tools/Makefile.am b/tools/Makefile.am
@@ -1,77 +0,0 @@
-# Copyright 1999-2016 the Claws Mail team.
-# This file is part of Claws Mail package, and distributed under the
-# terms of the General Public License version 3 (or later).
-# See COPYING file for license details.
-
-EXTRA_TOOLS = \
- acroread2claws-mail.pl \
- calypso_convert.pl \
- claws-mail-compose-insert-files.pl \
- cm-reparent.pl \
- convert_mbox.pl \
- csv2addressbook.pl \
- ddg_search.pl \
- eud2gc.py \
- filter_conv.pl \
- filter_conv_new.pl \
- fix_date.sh \
- gif2xface.pl \
- google_msgid.pl \
- kmail2claws-mail.pl \
- kmail2claws-mail_v2.pl \
- kmail-mailbox2claws-mail.pl \
- mairix.sh \
- mew2claws-mail.pl \
- multiwebsearch.pl \
- nautilus2claws-mail.sh \
- outlook2claws-mail.pl \
- popfile-link.sh \
- tb2claws-mail \
- tbird2claws.py \
- textviewer.pl \
- textviewer.sh \
- thunderbird-filters-convertor.pl \
- update-po \
- uudec \
- uuooffice \
- vcard2xml.py \
- kdeservicemenu/install.sh \
- kdeservicemenu/claws-mail-kdeservicemenu.pl
-
-EXTRA_DIST = \
- README \
- multiwebsearch.conf \
- kdeservicemenu/README \
- kdeservicemenu/claws-mail-attach-files.desktop.template \
- kdeservicemenu/claws-mail-attach-files.desktop.kde4template \
- $(EXTRA_TOOLS)
-
-MAKE_EXE = chmod u+x $(EXTRA_TOOLS)
-
-all-local:
- if [ ! -d kdeservicemenu -a ! -e kdeservicemenu ]; then \
- mkdir kdeservicemenu; \
- fi; \
- for file in $(EXTRA_TOOLS); do \
- if [ ! -e ${top_builddir}/tools/$$file ]; then \
- todir=${top_builddir}/tools; \
- dir=$$(dirname $$file); \
- if [ ! $$dir = . ]; then \
- todir=$$todir/$$dir; \
- fi; \
- cp ${top_srcdir}/tools/$$file $$todir; \
- fi; \
- done;
- $(MAKE_EXE)
-
-distclean-local:
- if [ ! ${top_builddir} = ${top_srcdir} ]; then \
- for file in $(EXTRA_TOOLS); do \
- rm -f $$file; \
- done; \
- if [ -d kdeservicemenu ]; then \
- rmdir --ignore-fail-on-non-empty kdeservicemenu; \
- fi; \
- fi
-
-.PHONY: test
diff --git a/tools/README b/tools/README
@@ -1,856 +0,0 @@
-
---------------------------------------------------------------------------------
-Contents of the tools directory:
---------------------------------------------------------------------------------
-
-Action scripts:
- cm-reparent.pl Fix thread parenting for two or more messages
- cm-break.pl Remove thread parenting for one or more messages
- ddg_search.pl Search DuckDuckGo for selected text
- google_msgid.pl Search groups.google.com for selected message-id
- multiwebsearch.pl Search any search engine for the selected text
- textviewer.sh Attempt to view an attachment as plain text
- uudec Decode and display uuencoded images
- uuooffice Decode uuencoded attachments and open them with
- OpenOffice
-
-Addressbook conversion:
- csv2addressbook.pl Import Becky, Thunderbird, Kmail, Gmail and Fox
- Mail address books
- eud2gc.py Convert Eudora address book to Gnomecard
- kmail2claws-mail.pl Import a Kmail address book (KDE2)
- kmail2claws-mail_v2.pl Import a Kmail address book (KDE3)
- mew2claws-mail.pl Import a Mew address book
- outlook2claws-mail.pl Import an Outlook generated contact list
- tb2claws-mail Import The Bat! address books
- vcard2xml.py Import an Evolution vCard
-
-Mailbox conversion:
- calypso_convert.pl Import mbox files with attachments from Calypso
- convert_mbox.pl Import mbox files
- kmail-mailbox2claws-mail.pl Convert a kmail mailbox to a Claws Mail mailbox
- tbird2claws.py Integrate a Thunderbird folder tree into Claws
-
-Other tools:
- acroread2claws-mail.pl Send PDFs from Adobe Reader 7
- claws-mail-compose-insert-files.pl
- Insert files into a new Compose window
- filter_conv_new.pl Convert new-style Sylpheed filters to filtering
- filter_conv.pl Convert old-style Sylpheed filters to filtering
- fix_date.sh Replace/Add a message's Date field (coreutils,
- dos2unix, grep and sed are required in PATH)
- mairix.sh A wrapper to mairix, to enable global searches in
- mail folders
- nautilus2claws-mail.sh Send files from Nautilus
- popfile-link.sh Open messages in POPFile control center to edit
- their status
- textviewer.pl Display various attachments as text
- thunderbird-filters-convertor.pl
- Convert Thunderbird filtering rules
-
-Extra tools:
- gif2xface.pl Convert a 48x48 GIF file to an X-Face header
- update-po Update the .po files named on the command line.
-
---------------------------------------------------------------------------------
-Detailed Descriptions:
---------------------------------------------------------------------------------
-
-Action scripts
---------------
-
-* cm-reparent.pl
- WORKS ON: selected messages (two or more)
- COMMAND: cm-reparent.pl %F
- Thread the selected messages based on date, old to new
-
-* cm-break.pl
- WORKS ON: selected messages (one or more)
- COMMAND: cm-break.pl %F
- Break thread references for the selected messages
-
-* ddg_search.pl
- WORKS ON: selection
- COMMAND: |ddg_search.pl
- Search duckduckgo.com for selected text using the default Claws Mail browser
-
-* google_msgid.pl
- WORKS ON: selection
- COMMAND: |google_msgid.pl
- Lookup selected message-id in google using mozilla. Edit the script to use
- different browsers.
-
-* multiwebsearch.pl
- WORKS ON: selection
- see further down for details
-
-* textviewer.sh
- WORKS ON: current message part
- COMMAND: textviewer.sh %p |
- Attempt to view an attachment as plain text
-
-* uudec
- WORKS ON: current message (or part of multipart message)
- COMMAND: uudec %f&
- Decode and display uuencoded images using uudecode.
-
-* uuooffice
- WORKS ON: current message (or part of multipart message)
- COMMAND: uuooffice %f&
- Decode uuencoded attachments and open them with OpenOffice
-
-* More action examples can be found at the Claws Mail FAQ
- http://www.claws-mail.org/faq/index.php/Actions
-
-** multiwebsearch.pl **
-
- WHAT IT DOES
- This is an Actions script that allows you to search
- websites for the selected text. It uses the default
- Claws Mail browser as configured through Claws Mail's
- GUI and specified in ~/.claws-mail/clawsrc, and a
- configuration file called multiwebsearch.conf.
-
- CONFIGURATION
- The configuration file takes the following format:
-
- ALIAS|URL PART|URL PART
-
- ALIAS is a user-defined name; the first URL PART is the
- url before the search term; the second URL PART is
- optional and contains the remaining part of the url which
- comes after the search term. A sample configuration file
- is included.
-
- HOW TO USE IT
- Copy 'multiwebsearch.conf' to ~/.claws-mail/
-
- Configure an Action:
- a) pre-configured website
- Command: multiwebsearch.pl --where="ddg" --what="%s"
- b) dynamic
- Command: multiwebsearch.pl --where="%u" --what="%s"
-
- In type a) "ddg" refers to one of the configured aliases,
- this Action will always search the website referred to by
- the alias "ddg".
-
- In type b) you will be presented with a dialog box into
- which you type one of your configured aliases
-
-
- Contact: Paul Mangan <paul@claws-mail.org>
---------------------------------------------------------------------------------
-
-Address book conversion
------------------------
-
-* csv2addressbook.pl
-
- WHAT IT DOES
- This perl script will import a Becky, Thunderbird, Kmail, Gmail and
- Fox Mail address book.
-
- HOW TO USE IT
- (You must run claws-mail at least once before running this script.)
-
- Becky >= 2.41
- -------------
- In Becky you need to do a CSV full export with titles of your
- address book.
-
- Run the script with the following options:
-
- perl csv2addressbook.pl --type=becky --csv=/full/path/to/file.csv
-
- Addtionally you can use the option '--name="My address book"', if
- you don't use this option the new Claws address book will be
- called 'Becky address book'.
-
-
- Thunderbird >= 2.0.0.6
- ----------------------
- In Thunderbird you need to export your address book as 'comma
- separated'.
-
- Run the script with the following options:
-
- perl csv2addressbook.pl --type=thunderbird --csv=/full/path/to/file.csv
-
- Addtionally you can use the option '--name="My address book"', if
- you don't use this option the new Claws address book will be
- called 'Thunderbird address book'.
-
- Kmail >= 1.9.7 / Kaddressbook >= 3.5.7
- --------------------------------------
- In Kaddressbook you need to export your address book as 'CSV List'.
-
- Run the script with the following options:
-
- perl csv2addressbook.pl --type=kmail --csv=/full/path/to/file.csv
-
- Addtionally you can use the option '--name="My address book"', if
- you don't use this option the new Claws address book will be
- called 'Kmail address book'.
-
- WARNING: Kmail/Kaddressbook has a bug whereby it exports badly
- formatted CSV if the values are quoted.
-
- Gmail
- -----
- In the Gmail web interface you need to export your address book
- as Outlook CSV format.
-
- Run the script with the following options:
-
- perl csv2addressbook.pl --type=gmail --csv=/full/path/to/file.csv
-
- Addtionally you can use the option '--name="My address book"', if
- you don't use this option the new Claws address book will be
- called 'gmail address book'.
-
- Fox Mail
- --------
- Export your Fox Mail address book as CSV with all possible headers.
-
- Run the script with the following options:
-
- perl csv2addressbook.pl --type=foxmail --csv=/full/path/to/file.csv
-
- Addtionally you can use the option '--name="My address book"', if
- you don't use this option the new Claws address book will be
- called 'foxmail address book'.
-
- You can also run the script with '--help' to get a brief usage message.
-
- Contact: Paul Mangan <paul@claws-mail.org>
-
-* eud2gc.py
-
- WHAT IT DOES
- This python-script is a quick hack to convert an Eudora (v.3?)
- addressbook to vCard (GnomeCard) format.
-
- HOW TO USE IT
- You may do whatever you want with it! (Also regarding copying)
- However, the script is intended to use like this:
-
- eud2gc.py <Eudora-addressbook-file> <Gnomecard-file>
-
- Be careful not to overwrite your original GnomeCard.gcrd!
- (But of course you might want to add the converted stuff to it)
-
- Contact: Jeroen Versteeg <j.m.versteeg@student.utwente.nl>
-
-* kmail2claws-mail.pl
-
- WHAT IT DOES
- This perl script will convert an exported Kmail addressbook into a
- Claws Mail addressbook. If your version of Kmail is 1.37 or
- greater and/or your version of KAddressBook is 3.1beta1 or greater,
- or this script mixes up your definitions and their related data, use
- 'kmail2claws-mail_v2.pl' instead.
-
- HOW TO USE IT
- (You must run claws-mail at least once before running this script.)
-
- In Kmail's Address book choose '/File/Export List'. This will export
- your Kmail address book data to a *.csv file.
-
- If Claws Mail is running, close it.
-
- From the command line, execute the following:
-
- perl kmail2claws-mail.pl --kmailfile=/path/to/addressbook.csv
-
- Your Kmail address book data will now be contained in Claws Mail'
- address book, under the name 'Kmail Address Book'.
-
- Contact: Paul Mangan <paul@claws-mail.org>
-
-
-* kmail2claws-mail_v2.pl
-
- This script has been tested with Kmail 1.4.7 and KAddressBook 3.1beta1
-
- WHAT IT DOES
- This perl script will convert a Kmail address book that has been
- exported in csv format into a Claws Mail address book.
-
- HOW TO USE IT
- (You must run claws-mail at least once before running this script.)
-
- Open Kmail's Addressbook, /File/Address Book
- In Kmail's Addressbook choose '/File/Export/Export List...'. This
- will allow you to export your Kmail addressbook data to a *.csv file.
-
- If Claws Mail is running, close it.
-
- From the command line, execute the following:
-
- perl kmail2claws-mail_v2.pl --kmailfile=/path/to/addressbook.csv
-
- You can also use --help to see usage instructions.
-
- Your Kmail addressbook data will now be contained in Claws Mail'
- addressbook, under the name 'Kmail address book'.
-
- Contact: Paul Mangan <paul@claws-mail.org>
-
-* mew2claws-mail.pl
-
- WHAT IT DOES
- This perl script will convert a Mew address book into a Claws Mail
- address book.
-
- HOW TO USE IT
- (You must run claws-mail at least once before running this script.)
-
- If Claws Mail is running, close it.
-
- From the command line, execute the following:
-
- perl mew2claws-mail.pl --mew-addressbook=/path/to/mew/addressbook
-
- You can also use --help to see usage instructions.
-
- Your Mew addressbook data will now be contained in Claws Mail's
- addressbook, under the name 'Mew Address Book'.
-
- Contact: Jérôme Lelong <jerome.lelong@gmail.com>
-
-* outlook2claws-mail.pl
-
- WHAT IT DOES
- This perl script converts an Outlook generated contact list into a
- Claws Mail XML address book.
-
- HOW TO USE IT
- For text files:
- --------------
- You must export Outlook Express contact list as TXT file, choosing
- only "Name" and "Address" fields to export.
-
- You must exit Claws Mail before converting the contact list.
-
- From the command line, execute the following:
-
- outlook2claws-mail.pl fullpathname
-
- For csv files:
- -------------
- You must export Outlook contact list as CSV file, choosing ALL the
- fields available for exporting.
-
- You must exit Claws Mail before converting the contact list.
-
- From the command line, execute the following:
-
- outlook2claws-mail.pl --csv fullpathname
-
- LIMITATIONS
- For text files only works with fields described above. If you have
- more complex examples send them to me, and I'll try to enhance the
- script.
-
- For csv files you must export all fields (but only non empty fields
- are added to the created Claws Mail address book) and the number
- of fields expected is harcoded. Look for the $nboffields variable in
- the script and change its value if you are sure you exported all
- fields and script gives the 'unknown csv file format' error.
-
- Contact: Ricardo Mones <ricardo@mones.org>
-
-
-* tb2claws-mail
-
- WHAT IT DOES
- This perl script will convert an address book exported from The Bat!
- into a Claws Mail address book.
-
- HOW TO USE IT
- (You must run claws-mail at least once before running this script.)
-
- If Claws Mail is running, close it.
-
- Export The Bat! Address Book to CSV file format with all fields
- selected to YES and then start:
-
- tb2claws-mail --tbfile=/full/path/to/thebat/addressbook.csv
-
- The Bat! addressbook data will now be contained in Claws Mail'
- addressbook, under the name 'The Bat! Address Book'.
-
- Contact: Urke MMI <urke@gmx.net>
-
-
-* vcard2xml.py
-
- WHAT IT DOES
- This python script will convert an Evolution vCard into a Claws Mail
- address book.
-
- HOW TO USE IT
- (You must run claws-mail at least once before running this script.)
-
- If Claws Mail is running, close it.
- From the command line, execute the following:
-
- vcard2xml.py source_file [destination_file]
-
- When only <source_file> is specified it will overwrite (and
- create a backup of) the existing addressbook.
- When both arguments are suplied it will create a new additional
- addressbook named as <destination_file>.
- If the script encounters an error it will attempt to roll back
- the changes and restore the original files.
-
- Contact: Bogdan Sumanariu <bsumanariu@one5.ro>
-
---------------------------------------------------------------------------------
-
-Mailbox conversion
-------------------
-
-* calypso_convert.pl
-
- WHAT IT DOES
- This perl script imports mbox files that are exported by Calypso.
- It recreates the folder structure by scanning the "X-CalypsoFolder"
- header and reincludes the attachments referenced in the
- "X-CalypsoHtmlBody" "X-CalypsoAccount" "X-Attachment" headers.
-
- HOW TO USE IT
- Export the Calypso mailbox by selecting "Save to archive" and check
- the "Save attachments" box.
-
- Edit the script to set following variables (at the top of the file):
- $mboxdir : path to the exported mbox, e.g. 'Archive' or '.'
- $mboxfile : name of exported mbox, e.g. 'mail.txt'
- $outdir : name of the MH folder to create, e.g. 'Calypso'
-
- Run the script using
-
- perl calypso_convert.pl
-
- Finally, import that folder by either selecting "New mailbox" or
- moving it into your existing directory and recreate the folder
- structure manually (contentmenu from folderview).
-
- Contact: Thorsten Maerz <torte@netztorte.de>
-
-* convert_mbox.pl
-
- WHAT IT DOES
- This perl script converts an mbox directory's contents into
- Claws Mail' MH format.
-
- HOW TO USE IT
-
- Run the script using:
-
- perl convert_mbox.pl MBOX MH_DIR
-
- Move the outputted MH_DIR and its contents into your Claws Mail
- Mail folder; in Claws Mail right-click the top-level folder and
- choose 'Rebuild folder tree' from the popup menu.
-
- Contact: Fred Marton <Fred.Marton@uni-bayreuth.de>
-
-* kmail-mailbox2claws-mail.pl
-
- WHAT IT DOES
- This perl script converts a kmail mailbox into Claws Mail' mailbox.
-
- HOW TO USE IT
-
- Exit Claws Mail if running.
-
- Run the script using:
-
- kmail-mailbox2claws-mail.pl --kmaildir=/full/path/to/kmail/mailbox
-
- Start Claws Mail and right-click the toplevel mailbox, i.e
- "Mailbox (MH)", and select 'Rebuild folder tree'.
- You may also need to run '/File/Folder/Check for new messages
- in all folders'
-
- Additional options:
- --debug debug mode
- --dry-run test mode, nothing is actually written
- --help brief usage info
-
- Contact: Paul Mangan <paul@claws-mail.org>
-
-* tbird2claws.py
-
- WHAT IT DOES
- This python script integrates a Thunderbird folder tree into
- Claws Mail.
-
- HOW TO USE IT
-
- The script receives two parameters from command-line:
- <Thunderbird folder path> <Claws Mail folder path>
-
- The best way to use it is to go to inside your Thunderbird
- root mailfolder directory and invoke it as:
-
- <path>\python2.4 <path>\tbird2claws.py . <path to Claws Mail>\Mail
-
- Contact: Aleksandar Urosevic aka Urke MMI <urke@gmx.net>
-
---------------------------------------------------------------------------------
-
-Other tools
------------
-
-* acroread2claws-mail.pl
-
- WHAT IT DOES
- This perl script enables Adobe Reader 7 to send documents to
- Claws Mail as attachments.
-
- HOW TO USE IT
- Make sure that the script is executable (chmod +x acroread2claws-mail.pl)
- Start up Adobe Reader 7 (acroread)
- Go to /Edit/Preferences/SendMail
- Select any email client except 'System Mail (mail)'
- Enter the path to this script in the alternate location box
-
- You can then use 'File/Email' or the Email toolbar button to launch
- claws-mail (if not already launched) and open a new compose window
- with the PDF attached.
-
- Contact: Paul Mangan <paul@claws-mail.org>
-
-* claws-mail-compose-insert-files.pl
-
- WHAT IT DOES
- This script enables inserting files into the message body of a new
- Claws Mail Compose window from the command line. Additionally To,
- Cc, Bcc, Subject and files to attach to the message can be specified.
-
- HOW TO USE IT
- claws-mail-compose-insert-files.pl [options]
- Options:
- --help -h
- --to "Person One <mail@address.net>"
- --cc "Person One <mail@address.net>"
- --bcc "Person One <mail@address.net>"
- --subject "My subject"
- --attach FILE
- --insert FILE
-
- For multiple recipients separate the addresses with ','
- e.g. --to "Person One <mail@address.net>,Person Two <mail2@address.net>"
- --attach and --insert can be used multiple times
-
- Contact: Paul Mangan <paul@claws-mail.org>
-
-* filter_conv_new.pl
-
- WHAT IT DOES
- This perl script provides easy conversion of your filtering rules from
- sylpheed's new filter system (>= 0.9.99) to the filtering system used in
- Claws Mail.
- It reads '~/.sylpheed-2.0/filter.xml' or '~/.sylpheed/filter.xml' and
- writes '~/[CLAWS CONFIG DIR]/matcherrc'
-
- HOW TO USE IT
- Issue the following command from the 'tools' directory:
-
- perl filter_conv_new.pl
-
- That's it, the claws' filtering system is now implemented with your
- previous rules applied.
-
- REQUIREMENTS
- XML::SimpleObject
-
- Contact: Paul Mangan <paul@claws-mail.org>
-
-
-* filter_conv.pl
-
- WHAT IT DOES
- This perl script provides easy conversion of your filtering rules
- from sylpheed's old filter system (< 0.9.99) to the filtering system
- used in Claws Mail.
- It reads '~/.sylpheed/filterrc' and writes '~/.claws-mail/matcherrc'
-
- HOW TO USE IT
- Issue the following command from the 'tools' directory:
-
- perl filter_conv.pl
-
- That's it, the new filtering system is now implemented with your
- previous rules applied.
-
- Contact: Paul Mangan <paul@claws-mail.org>
-
-
-* fix_date.sh
-
- WHAT IT DOES
- Add a 'Date:' header to the selected email(s) when such header
- is missing. The correct date is guessed from other headers
- that contain timestamp information (preferred: Fetchinfo
- header if found) or from the file or system date as a
- fallback. The order or preference for the date value
- replacement can be changed by editing the script.
- This script can be used to fix messages that show non
- RFC-compliant Date headers as well.
- X-Original-Date is always added too if not already existing
- (if so, it's left untouched), to keep track of the original
- value if any.
- An existing Date: header is not overwritten unless you use the
- --force switch.
- Non RFC-compliant dates can be overwritten using the --rfc
- switch. Use --strict to use strict RFC matching patterns for
- date values in other headers.
-
- HOW TO USE IT
- First you have to create an action with the following command:
-
- fix_date.sh %F
-
- On main window's message list, select the messages to be fixed
- and invoke the created action.
-
- Contact: wwp <wwp@claws-mail.org>
-
-* mairix.sh
-
- WHAT IT DOES
- It's a wrapper to mairix, a tool that makes indexed searches
- and shows search results in a virtual folder. Maildir, MH and
- mbox formats are supported, see: https://github.com/rc0/mairix
-
- HOW TO USE IT
- mairix.sh
- mairix.sh <mairix rcfile> [<mairix options>..]
-
- For instance:
- mairix.sh ~/.mairixrc s:word1,word2
-
- Contact: wwp <wwp@claws-mail.org>
-
-
-* nautilus2claws-mail.sh
-
- WHAT IT DOES
- This script will recursively attach a number of selected
- files/directories from Nautilus to a new blank e-mail.
-
- HOW TO USE IT
- Copy the script to $HOME/.gnome2/nautilus-scripts, chmod u+x,
- and restart nautilus (killall -9 nautilus). You will now have
- a right-click menu item: '/Scripts/nautilus2claws-mail.sh'
-
- Contact: Reza Pakdel <hrpakdel@cpsc.ucalgary.ca>
-
-
-* popfile-link.sh
-
- WHAT IT DOES
- Open selected messages in POPFile control center to edit their
- status. Requires that POPFile is running and that the messages
- have been processed by it (X-POPFile-Link: header is expected).
- POPFile control center opens with the web browser set in
- Claws Mail prefs.
-
- HOW TO USE IT
- popfile-link.sh <filename> [<filename>..]
-
-
- Contact: wwp <wwp@claws-mail.org>
-
-
-* textviewer.pl
-
- WHAT IT DOES
- This script tries to recognise an attachment by using the 'file'
- command and/or the file extension and then uses the available
- utilities to make an effort to display it as text.
-
- $ textview.pl --list
-
- will show available conversion, the top:
-
- .awk cat
- .bin strings
- .bz2 bzip2 -d < %f | strings
- .c cat
- .cc cat
- .csv xlscat -L
-
- If there are multiple alternatives available, they are listed in
- the ordder they are tried, like for .xls:
-
- .xls xlscat -L
- .xls catdoc -x -dutf-8
- .xls wvText
-
- HOW TO USE IT
- Go to /Configuration/Message View/External Programs and enter the
- path to the script in the "Command for 'Display as text'" box.
- Now when you right-click an attachment and choose 'Display as text'
- this script will be invoked.
-
- xlscat comes with the perl module Spreadsheet::Read, which is a
- wrapper module over several parsers and supports ods, sxc, csv, xls,
- xlsx, and sq. See https://metacpan.org/release/Spreadsheet-Read
-
- Contact: H.Merijn Brand <h.m.brand@xs4all.nl>
-
-
-* thunderbird-filters-convertor.pl
-
- WHAT IT DOES
- This perl script converts Thunderbird filtering rules into Claws Mail
- filtering rules. It can be run several times, once for each filter
- configuration file in Thunderbird.
-
- HOW TO USE IT
- The script takes 3 arguments:
-
- --tbird-file=PATH TO FILE The full path to the file to be converted
- --mailbox-name=NAME The name of the Claws Mail mailbox
- --account-name=NAME The name of the account to be used (optional)
-
- --tbird-file must point to the Thunderbird filter file (msgFilterRules.dat)
- that you want to convert, it must contain the full path to the file.
- --mailbox-name should be given the name of your mailbox in Claws Mail, e.g.
- if the top-level folder is 'Mailbox (MH)' then this option should be
- 'Mailbox'.
- --account-name is optional, only needed if you are creating account-specific
- rules. This is the name of your account in Claws Mail, which should
- correspond to an account that you had in Thunderbird, e.g. the acount whose
- rules you are converting.
-
- This script presumes that your folder hierarchy in Claws Mail matches the
- one that you had in Thunderbird. If you used the tbird2claws.py script to
- convert your Thunderbird mailbox, then the folder hierarchy should match.
-
- If the Claws Mail filtering configuration file (matcherrc) does not exist,
- the script will create it; if it does exist, the newly converted rules will
- be appended to it.
-
- REQUIREMENTS
- Getopt::Long
- URI::Escape
-
- Contact: Paul Mangan <paul@claws-mail.org>
-
---------------------------------------------------------------------------------
-
-Extra tools
------------
-
-* gif2xface.pl
-
- WHAT IT DOES
- This perl script converts a monochrome (1 bit) 48x48 pixels GIF file
- into an X-Face graphic suitable for inclusion into custom headers of
- Claws Mail. An X-Face allows to quickly identify (or be identified
- as) the sender of a mail message in a xface-capable MUA (like Claws
- Mail).
-
- HOW TO USE IT
- After obtaining the desired image for your X-Face you should:
- * scale it to 48x48 pixels (Image->Scale image on Gimp)
- * down color depth to b/w (Image->Mode->Indexed selecting "Use
- Black/White palette" and the desired dithering options (prior to
- indexing doing Image->Colors->Threshold allows you to select the
- b/w level if you don't want a dithered (dotty) image))
- * save file as non-interlaced GIF
- Then do:
-
- ./gif2xface < filename.gif > filename.xface
-
- In filename.xface will be the X-Face header ready to use.
- You can add a custom header in Claws Mail through Configuration->
- Preferences per account, "Send" tab, check "Add user-defined header"
- then "Edit..." if you want to add it via the Claws Mail interface, or do
-
- echo "0:" `cat filename.xface` > ~/.claws-mail/customheaderrc
-
- if you want to create the custom headers file yourself (Warning: this
- method is valid only if you don't have any other custom header set or
- they will be lost!).
-
- Contact: Ricardo Mones <ricardo@mones.org>
-
-
-* update-po
-
- WHAT IT DOES
- This script is a message catalog translator's tool, it updates the .po
- files named on the command line.
-
- HOW TO USE IT
- This script needs to be copied to and run from the 'po' directory.
-
- ./update-po lang.po lang2.po ...
-
- to update one or more <yourlang>.po files from the sourcecode files
- named in POTFILES.in. The old .po file is save in a .po.old file.
-
- For example, when you want to update fr.po, run ./update-po fr.po,
- then edit fr.po to update your translation.
-
- Contact: Wilbert Berendsen <wilbert@oswf.org> or the Claws Mail Team
-
---------------------------------------------------------------------------------
-This file is Copyright 1999-2014 by the Claws Mail team.
-See accompanying COPYING file for license details.
-See each included script for copyright and license details.
-
-* cm-reparent.pl
-
- WHAT IT DOES
- This script tries to fix thread parenting for two or more messages
-
- HOW TO USE IT
- Define an action as
-
- Menu name: Reparent (fix threading)
- Command: cm-reparent.pl %F
-
- Then select from the message list all files that should be re-parented
-
- Then invoke the action
-
- MORE INFORMATION
- $ perldoc cm-reparent.pl
-
- REQUIREMENTS
- Date::Parse
- Getopt::Long
-
- Contact: H.Merijn Brand <h.m.brand@xs4all.nl>
-
-* cm-break.pl
-
- WHAT IT DOES
- This script tries to break thread parenting for one or more messages
-
- HOW TO USE IT
- Define an action as
-
- Menu name: Unthread (break threading)
- Command: cm-break.pl %F
-
- Then select from the message list all files that should be un-threaded
-
- Then invoke the action
-
- MORE INFORMATION
- $ perldoc cm-break.pl
-
- REQUIREMENTS
- Date::Parse
- Getopt::Long
-
- Contact: H.Merijn Brand <h.m.brand@xs4all.nl>
diff --git a/tools/acroread2claws-mail.pl b/tools/acroread2claws-mail.pl
@@ -1,47 +0,0 @@
-#!/usr/bin/perl
-
-# * Copyright 2005 Paul Mangan <paul@claws-mail.org>
-# *
-# * This file is free software; you can redistribute it and/or modify it
-# * under the terms of the GNU General Public License as published by
-# * the Free Software Foundation; either version 3 of the License, or
-# * (at your option) any later version.
-# *
-# * This program is distributed in the hope that it will be useful, but
-# * WITHOUT ANY WARRANTY; without even the implied warranty of
-# * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# * General Public License for more details.
-# *
-# * You should have received a copy of the GNU General Public License
-# * along with this program; if not, write to the Free Software
-# * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-#
-# acroread2claws-mail.pl helper script to send documents from
-# Adobe Reader 7 to claws-mail
-
-use strict;
-
-my $input = <>;
-
-my $pdf;
-my $output = $ARGV;
-
-if ($ARGV =~ m/^\//) {
- $pdf = $output;
-} elsif ($ARGV =~ m/^mailto/) {
- my @parts = split(/&[a-z]*=/, $output);
- $parts[0] =~ s/^mailto:\?attach=//;
- $pdf = $parts[0];
-} elsif ($ARGV =~ m/^to/) {
- my @parts = split(/,/, $output);
- $parts[3] =~ s/^attachment=file:\/\///;
- $pdf = $parts[3];
-} else {
- $pdf = $ENV{HOME}."/".$output;
-}
-
-exec "claws-mail --attach \"$pdf\"";
-## if necessary, change the line above to point to
-## your claws-mail executable
-
-exit;
diff --git a/tools/alternative-tlds.txt b/tools/alternative-tlds.txt
@@ -1,48 +0,0 @@
-# NameCoin
-BIT
-# EmerCoin
-BAZAR
-COIN
-EMC
-LIB
-# Name.Space
-ART
-BOOKS
-CHAT
-DESIGN
-FILM
-HELP
-INC
-LAW
-MUSIC
-NEWS
-PRESS
-RADIO
-SHOP
-TALK
-UNION
-VIDEO
-WORLD
-ZONE
-# OpenNIC
-BBS
-DYN
-FREE
-FUR
-GEEK
-GOPHER
-INDY
-ING
-MICRO
-NEO
-NULL
-OSS
-OZ
-PARODY
-PIRATE
-# Tor Project
-ONION
-# GNU Name System
-GNU
-# Invisible Internet Project
-I2P
diff --git a/tools/bash_completion/README b/tools/bash_completion/README
@@ -1,42 +0,0 @@
-Bash Programmable Completion for Claws Mail
--------------------------------------------
-
-This directory contains a script which provides argument completion
-when using Claws Mail from the command line under the bash shell.
-This is usually triggered by pressing the tab key (↹).
-
-See bash manual (https://www.gnu.org/software/bash/manual/) for more
-details about programmable completion.
-
-Usage
------
-
-Examples below assume current directory is the toplevel directory of
-either an extracted tarball or a git clone.
-
-Single user
-----------
-
-For a single user just make a directory (e.g. '.bash_completion.d')
-on your $HOME directory and copy the completion script there:
-
-$ mkdir ~/.bash_completion.d
-$ cp tools/bash_completion/claws-mail ~/.bash_completion.d/
-
-Then, source the script to enable it:
-
-$ . ~/.bash_completion.d/claws-mail
-
-To enable it permanently just add the command to the user's bashrc:
-
-$ echo '. ~/.bash_completion.d/claws-mail' >> $HOME/.bashrc
-
-All users
----------
-
-For system wide installation just copy the file to the system directory,
-which is usually located in /etc (you need to become root for that):
-
-$ sudo cp tools/bash_completion/claws-mail /etc/bash_completion.d/
-
-After login in again all users should be able to use completion.
diff --git a/tools/bash_completion/claws-mail b/tools/bash_completion/claws-mail
@@ -1,30 +0,0 @@
-# claws-mail(1) completion
-_claws-mail()
-{
- local cur prev words cword
- _init_completion || return
-
- case $prev in
- --help|-h|--version|-v|--version-full|-V)
- return
- ;;
- --alternate-config-dir)
- COMPREPLY=( $( find . -maxdepth 2 -name clawsrc | sed 's,/clawsrc,,' ) )
- return
- ;;
- --select|--status|--status-full)
- _filedir -d
- return
- ;;
- --compose-from-file|--attach)
- _filedir
- return
- ;;
- esac
-
- if [[ $cur == -* ]]; then
- COMPREPLY=( $( compgen -W '$( _parse_help "$1" )' -- "$cur" ) )
- return
- fi
-} &&
-complete -F _claws-mail claws-mail
diff --git a/tools/calypso_convert.pl b/tools/calypso_convert.pl
@@ -1,253 +0,0 @@
-#!/usr/bin/perl
-# calypso_import.pl
-# Author: Thorsten Maerz <info@netztorte.de>
-# License: GPL
-# Dependencies: MIME::Parser, LWP::MediaTypes from www.cpan.org
-# Converts mbox files as exported from Calypso to MH format. Regenerates
-# Calypso's folder structure and optionally includes the attachments.
-
-use strict ;
-
-our $mboxdir = '' || showhelp(); # enter path to exported mbox
-our $mboxfile = '' || showhelp(); # enter name of exported mbox
-our $outdir = '' || showhelp(); # enter destination path
-
-my $incl_attach = 1 ; # include attachments (needs CPAN modules)
-my $verbose = 1 ; # show some headers of processed mail
-my $testonly = 0 ; # dont create any files
-
-################################################################################
-# no user servicable parts below :)
-
-if ($incl_attach) {
- use MIME::Parser;
- use LWP::MediaTypes qw(guess_media_type);
-}
-
-my $mbox = "$mboxdir/$mboxfile";
-my $calypso_hdr = 'From \?\?\?@\?\?\? '; #Mon Apr 17 00:37:38 2000
-my $hdr_Folder = 'X-CalypsoFolder:';
-my $hdr_HTML = 'X-CalypsoHtmlBody:';
-my $hdr_Account = 'X-CalypsoAccount:';
-my $hdr_Attach = 'X-Attachment:';
-my %mail_nr;
-my $create_dirs = 1 ; # create dirs from "X-Calypso-Folder:" header
-
-################################################################################
-sub showhelp {
- die ( "You have not yet configured this script.\n"
- . "Please provide the correct path and file names, e.g\n"
- . "\tour \$mboxdir = 'Archive'\n"
- . "\tour \$mboxfile = 'mail.txt'\n"
- . "\tour \$outdir = 'Calypso'\n"
- . "at the top of $0\n"
- );
-}
-
-################################################################################
-#
-# MAIN : scan $mbox linewise
-# Create a separate message for each $calypso_hdr found (MH format)
-# $attach_full = filename with path, $attach_short = original attachment name
-# $folder = Calypso folder
-#
-################################################################################
-my ($folder, $html, $html_full, $html_short,
- $account, $attach, $attach_short, $attach_full);
-my @lines ;
-
-open (INBOX, "<".$mbox);
-while (<INBOX>) {
- s/\x0d\x0a//;
- s/\x0d//;
- s/\x0a//;
- if (m/^$calypso_hdr/) {
- if (@lines) {
- $mail_nr{$folder}++ ;
- shift @lines ; # remove blank line
- savemail();
-
- @lines = () ;
- $folder = $html = $html_full = $html_short = $account
- = $attach = $attach_short = $attach_full = "";
-
- }
- }
- else {
- if (/^$hdr_Folder /) { $folder = $' ;
- $folder =~ s/"//eg ;
- $folder =~ tr#\\#\/# ;
- }
- if (/^$hdr_HTML /) { $html = $' ;
- $html =~ s/"//eg ;
- $html =~ tr#\\#\/# ;
- if ($html =~ /; /) {
- $html_full = $` ;
- $html_short = $' ;
- }
- }
- if (/^$hdr_Account /) { $account = $' ;
- $account =~ s/"//eg ;
- }
- if (/^$hdr_Attach /) { $attach = $' ;
- $attach =~ s/"//eg ;
- $attach =~ tr#\\#\/# ;
- if ($attach =~ /; /) {
- $attach_full = $` ;
- $attach_short = $' ;
- }
- }
-
- push (@lines, $_ );
- }
-}
-close (INBOX);
-
-################################################################################
-#
-# sub:savemail
-# Saves mail in @lines to $outdir/$folder/$mail_nr
-# Folder is created unless $testonly or (not $create_dirs) is set
-#
-################################################################################
-sub savemail {
- my $mailname = $mail_nr{$folder};
- my %headers;
- my $ishead=1;
- my $lineno=0;
- my $targetdir="";
-
- # extract headers
- foreach (@lines) {
- my ($hdr,$cnt);
- $lineno++;
-
- m/^$/ and ($ishead="");
- if ( $ishead ) {
- if (m/: /) {
- ($hdr,$cnt) = ($`,$');
- $headers{$hdr}=$cnt;
- }
- }
- }
-
- if ($verbose) {
- print "MAIL : $mailname\n";
- print "FOLDER : $folder\n" if ($folder);
- print "HTML : $html_short ($html_full)\n" if ($html);
- print "ACCOUNT : $account\n" if ($account);
- print "ATTACH : $attach_short ($attach_full)\n" if ($attach);
- print "\n";
- }
- # write mail to folder
- if (! $testonly ) {
- if ($create_dirs) {
- $targetdir = $outdir.'/'.$folder ;
- my $curdir = '';
- foreach (split('/',$targetdir)) {
- $curdir .= $_ . '/';
- ( -d $curdir) || mkdir $curdir;
- }
- }
-
- open (OUTFILE, ">".$targetdir.'/'.$mailname);
- foreach (@lines) { print OUTFILE "$_\n" ; }
- close (OUTFILE);
-
- if ($incl_attach) {
- include_attachment($targetdir.'/'.$mailname);
- }
- }
-}
-
-################################################################################
-# make inline attachment from external file
-# uses MIME::Parser, LWP::MediaTypes from www.cpan.org
-# (Currently leaves a blank attachment in converted mails. Feel free to
-# improve this script)
-sub include_attachment() {
- my $mailname = shift ;
- my $parser = new MIME::Parser ;
-
- my $entity ;
- my %attachments ;
- my %CID ;
-
- $parser->output_to_core(1); # dont save to harddisk
- $entity = $parser->parse_open($mailname);
-
- # look for external attachments
- foreach ($entity->head->get('X-Attachment')) {
- if (m/["']? # 1. start with " or ' (or none)
- ([^"';]+) # word till quote or separator
- ["']? # delete quote
- \s?;\s? # separator ; (opt. spaces)
- ["']? # 2. start (s.a.)
- ([^"';]+) #
- ["']?
- /x ) { $attachments{$1} = $2 ;
- }
- }
- foreach ($entity->head->get('X-CalypsoHtmlBody')) {
- if (m/["']? # 1. start with " or ' (or none)
- ([^"';]+) # word till quote or separator
- ["']? # delete quote
- \s?;\s? # separator ; (opt. spaces)
- ["']? # 2. start (s.o.)
- ([^"';]+) #
- ["']?
- /x ) { $attachments{$1} = $2 ;
- }
- }
- foreach ($entity->head->get('X-CalypsoHtmlImg')) {
- if (m/["']? # 1. start with " or ' (or none)
- ([^"';]+) # word till quote or separator
- ["']? # delete quote
- \s?;\s? # separator ; (opt. spaces)
- ["']? # 2. start (s.a.)
- ([^"';]+) #
- ["']?
- \s?;\s? # separator ; (opt. spaces)
- ["']? # 3. start (s.a.)
- ([^"';]+) #
- ["']?
- /x ) { $attachments{$1} = $3 ;
- $CID{$1} = $2 ;
- }
- }
-
- if (%attachments) {
- # read attachment
- foreach my $key (keys (%attachments)) {
- our $attachdir;
- my $type ;
- my $enc ;
- my $fnam = $key;
- $fnam =~ tr#\\#/# if -d '/' ; # correct path names on unix like OS
- $fnam = $mboxdir .'/'. $fnam ;
- $type = guess_media_type($fnam);
-
- if ( $type =~ m/text/i ) { $enc = "8bit" }
- else { $enc = "base64" }
-
- $entity->attach(Path => $fnam,
- Type => $type,
- Encoding => $enc,
- Filename => $attachments{$key}
- );
- }
-
- my $lines = $entity->as_string ;
- # correct images names in html messages
- foreach (keys (%CID)) {
- $lines =~ s/CID:$CID{$_}/$attachments{$_}/eg;
- }
-
- print $mailname."\n";
- # qx(mv $mailname $mailname.bak);
- open ( MAIL, ">".$mailname );
- print( MAIL $lines );
- close( MAIL );
- }
-}
-
diff --git a/tools/check-appstream.sh b/tools/check-appstream.sh
@@ -1,4 +0,0 @@
-#!/bin/bash
-exec 2>&1
-files=`find $(dirname $(readlink -f $0))/../ -regextype posix-extended -regex "^.*\.(metainfo|appdata).xml(.in)?"`
-appstream-util validate ${files}
diff --git a/tools/claws-mail-compose-insert-files.pl b/tools/claws-mail-compose-insert-files.pl
@@ -1,97 +0,0 @@
-#!/usr/bin/perl -w
-
-use strict;
-
-use Getopt::Long;
-use URI::Escape;
-
-# * This file is free software; you can redistribute it and/or modify it
-# * under the terms of the GNU General Public License as published by
-# * the Free Software Foundation; either version 3 of the License, or
-# * (at your option) any later version.
-# *
-# * This program is distributed in the hope that it will be useful, but
-# * WITHOUT ANY WARRANTY; without even the implied warranty of
-# * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# * General Public License for more details.
-# *
-# * You should have received a copy of the GNU General Public License
-# * along with this program; if not, write to the Free Software
-# * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-# *
-# * Copyright 2007 Paul Mangan <paul@claws-mail.org>
-# *
-
-# This script enables inserting files into the message body of a new Claws Mail
-# Compose window from the command line. Additionally To, Cc, Bcc, Subject and
-# files to attach to the message can be specified
-
-my (@inserts,@attachments,@lines,@output) = ();
-my $body = "";
-my $attach_list = "";
-my $to = "";
-my $cc = "";
-my $bcc = "";
-my $subject = "";
-my $help = "";
-
-GetOptions("to=s" => \$to,
- "cc=s" => \$cc,
- "bcc=s" => \$bcc,
- "subject=s" => \$subject,
- "attach=s" => \@attachments,
- "insert=s" => \@inserts,
- "help|h" => \$help);
-
-if ($help) {
- help_me();
-}
-
-@attachments = split(/,/, join(',', @attachments));
-@inserts = split(/,/, join(',', @inserts));
-
-foreach my $attach (@attachments) {
- $attach_list .= "$attach ";
-}
-
-foreach my $insert (@inserts) {
- open(FILE, "<$insert") || die("can't open file\n");
- @lines = <FILE>;
- push(@output, @lines);
- close FILE;
-}
-
-foreach my $line (@output) {
- $body .= "$line";
-}
-
-$to = uri_escape($to);
-$cc = uri_escape($cc);
-$bcc = uri_escape($bcc);
-$subject = uri_escape($subject);
-$body = uri_escape($body);
-
-system("claws-mail --compose \"mailto:$to?subject=$subject&cc=$cc&bcc=$bcc&body=$body\" --attach $attach_list");
-
-exit;
-
-sub help_me {
- print<<'EOH';
-Usage:
- claws-mail-compose-insert-files.pl [options]
-Options:
- --help -h
- --to "Person One <mail@address.net>"
- --cc "Person One <mail@address.net>"
- --bcc "Person One <mail@address.net>"
- --subject "My subject"
- --attach FILE
- --insert FILE
-
-For multiple recipients separate the addresses with ','
-e.g. --to "Person One <mail@address.net>,Person Two <mail2@address.net>"
---attach and --insert can be used multiple times
-
-EOH
-exit;
-}
diff --git a/tools/claws.get.tlds.pl b/tools/claws.get.tlds.pl
@@ -1,68 +0,0 @@
-#!/usr/bin/perl -w
-=pod
-=head1
-
-claws.get.tlds.pl - IANA TLDs online list to stdout as gchar* array.
-
-Syntax:
- claws.get.tlds.pl [extra-domains.txt] > src/common/tlds.h
-
-Copyright (c) 2015 Ricardo Mones <ricardo@mones.org>
-
-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
-Free Software Foundation, either version 3 of the License, or (at your
-option) any later version.
-
-This program is distributed in the hope that it will be useful, but
-WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-General Public License for more details.
-
-You should have received a copy of the GNU General Public License along
-with this program. If not, see <http://www.gnu.org/licenses/>.
-
-=cut
-use 5.012;
-use utf8;
-use LWP::Simple;
-use constant {
- URL => "https://data.iana.org/TLD/tlds-alpha-by-domain.txt"
-};
-
-print "/*\n * This is a generated file.\n * See tools/claws.get.tlds.pl\n */\n";
-print "#ifndef __TLDS_H__\n#define __TLDS_H__\n\n";
-print "static const gchar *toplvl_domains [] = {\n\t"; # open array
-
-my $payload = get URL;
-die "Unable to retrieve IANA list of TLDs\n" unless defined $payload;
-my @lines = map { chomp; $_ } split /^/, $payload;
-my ($i, $j) = (0, 0);
-
-if (defined $ARGV[0] and -f $ARGV[0]) {
- my %domains = ();
- foreach (@lines) { $domains{$_} = "" unless (/^#.*$/) }
- open my $fh, '<', $ARGV[0] or die "Unable to open $ARGV[0] for reading\n";
- while (<$fh>) {
- chomp;
- push @lines, $_ if (/^#.*/ or not defined $domains{$_});
- }
- close $fh;
-}
-
-foreach (@lines) {
- ++$i;
- if (/^#(.*)$/) { # comments
- my $c = $1; $c =~ s/^\s+|\s+$//g;
- print "/* $c */\n\t";
- next;
- }
- next if (/^XN--.*$/); # IDNs not supported yet, see bug #1670
- my $tld = lc $_; # list comes in upper case
- print "\"$tld\""; ++$j;
- print ",\n\t" unless $i >= scalar @lines;
- print "\n" if $i >= scalar @lines;
-}
-
-print "};\n\n"; # close array
-print "#endif\n";
diff --git a/tools/claws.i18n.status.pl b/tools/claws.i18n.status.pl
@@ -1,326 +0,0 @@
-#!/usr/bin/perl
-#
-# claws.i18n.stats.pl - Generate statistics for Claws Mail po directory.
-#
-# Copyright (C) 2003-2023 by Ricardo Mones <ricardo@mones.org>,
-# Paul Mangan <paul@claws-mail.org>
-# This program is released under the GNU General Public License.
-#
-use warnings;
-use strict;
-use File::Which;
-
-# constants -----------------------------------------------------------------
-my %lang = (
- 'bg.po' => {
- 'out' => 0, 'name' => 'Bulgarian',
- 'last' => 'Yasen Pramatarov <yasen@lindeas.com>',
- },
- 'ca.po' => {
- 'out' => 1, 'name' => 'Catalan',
- 'last' => 'David Medina <opensusecatala@gmail.com>',
- },
- 'cs.po' => {
- 'out' => 1, 'name' => 'Czech',
- 'last' => 'David Vachulka <david@konstrukce-cad.com>',
- },
- 'da.po' => {
- 'out' => 1, 'name' => 'Danish',
- 'last' => 'Erik P. Olsen <epodata@gmail.com>',
- },
- 'de.po' => {
- 'out' => 1, 'name' => 'German',
- 'last' => 'Simon Legner <simon.legner@gmail.com>',
- },
- 'el_GR.po' => {
- 'out' => 1, 'name' => 'Greek',
- 'last' => 'Haris Karachristianidis <hariskar@cryptolab.net>',
- },
- 'en_GB.po' => {
- 'out' => 1, 'name' => 'British English', 'lazy' => 1,
- 'last' => 'Paul Mangan <paul@claws-mail.org>',
- },
- 'eo.po' => {
- 'out' => 0, 'name' => 'Esperanto',
- 'last' => 'Sian Mountbatten <poenikatu@fastmail.co.uk>',
- },
- 'es.po' => {
- 'out' => 1, 'name' => 'Spanish',
- 'last' => 'Ricardo Mones <ricardo@mones.org>',
- },
- 'fi.po' => {
- 'out' => 1, 'name' => 'Finnish',
- 'last' => 'Flammie Pirinen <flammie@iki.fi>',
- },
- 'fr.po' => {
- 'out' => 1, 'name' => 'French',
- 'last' => 'Tristan Chabredier <wwp@claws-mail.org>',
- },
- 'he.po' => {
- 'out' => 0, 'name' => 'Hebrew',
- 'last' => 'Isratine Citizen <genghiskhan@gmx.ca>',
- },
- 'hu.po' => {
- 'out' => 1, 'name' => 'Hungarian',
- 'last' => 'Páder Rezső <rezso@rezso.net>',
- },
- 'id_ID.po' => {
- 'out' => 1, 'name' => 'Indonesian',
- 'last' => 'MSulchan Darmawan <bleketux@gmail.com>',
- },
- 'it.po' => {
- 'out' => 1, 'name' => 'Italian',
- 'last' => 'Luigi Votta <luigi.vtt@gmail.com>',
- },
- 'ja.po' => {
- 'out' => 1, 'name' => 'Japanese',
- 'last' => 'UTUMI Hirosi <utuhiro78@yahoo.co.jp>',
- },
- 'lt.po' => {
- 'out' => 0, 'name' => 'Lithuanian',
- 'last' => 'Mindaugas Baranauskas <embar@super.lt>',
- },
- 'nb.po' => {
- 'out' => 1, 'name' => 'Norwegian Bokmål',
- 'last' => 'Petter Adsen <petter@synth.no>',
- },
- 'nl.po' => {
- 'out' => 1, 'name' => 'Dutch',
- 'last' => 'Marcel Pol <mpol@gmx.net>',
- },
- 'pl.po' => {
- 'out' => 1, 'name' => 'Polish',
- 'last' => 'Łukasz Wojniłowicz <lukasz.wojnilowicz@gmail.com>',
- },
- 'pt_BR.po' => {
- 'out' => 1, 'name' => 'Brazilian Portuguese',
- 'last' => 'Frederico Goncalves Guimaraes <fggdebian@yahoo.com.br>',
- },
- 'pt_PT.po' => {
- 'out' => 1, 'name' => 'Portuguese',
- 'last' => 'Hugo Carvalho <hugokarvalho@hotmail.com>',
- },
- 'ro.po' => {
- 'out' => 1, 'name' => 'Romanian',
- 'last' => 'Cristian Secară <liste@secarica.ro>',
- },
- 'ru.po' => {
- 'out' => 1, 'name' => 'Russian',
- 'last' => 'Mikhail Kurinnoi <viewizard@viewizard.com>',
- },
- 'sk.po' => {
- 'out' => 1, 'name' => 'Slovak',
- 'last' => 'Slavko <slavino@slavino.sk>',
- },
- 'sq.po' => {
- 'out' => 1, 'name' => 'Albanian',
- 'last' => 'Besnik Bleta <besnik@programeshqip.org>',
- },
- 'sv.po' => {
- 'out' => 1, 'name' => 'Swedish',
- 'last' => 'Andreas Rönnquist <gusnan@openmailbox.org>',
- },
- 'tr.po' => {
- 'out' => 1, 'name' => 'Turkish',
- 'last' => 'Numan Demirdöğen <if.gnu.linux@gmail.com>',
- },
- 'uk.po' => {
- 'out' => 0, 'name' => 'Ukrainian',
- 'last' => 'YUP <yupadmin@gmail.com>',
- },
- 'zh_CN.po' => {
- 'out' => 0, 'name' => 'Simplified Chinese',
- 'last' => 'Rob <rbnwmk@gmail.com>',
- },
- 'zh_TW.po' => {
- 'out' => 1, 'name' => 'Traditional Chinese',
- 'last' => 'Mark Chang <mark.cyj@gmail.com>',
- },
-);
-
-my %barcolornorm = (
- default => 'white',
- partially => 'lightblue',
- completed => 'blue',
-);
-
-my %barcoloraged = (
- default => 'white',
- partially => 'lightgrey', # ligth red '#FFA0A0',
- completed => 'grey', # darker red '#FF7070',
-);
-
-my %barcolorcheat = ( # remarks translations with revision dates in the future
- default => 'white',
- partially => 'yellow',
- completed => 'red',
-);
-
-my ($barwidth, $barheight) = (500, 12); # pixels
-
-my $transolddays = 120; # days to consider a translation is old, so probably unmaintained.
-my $transoldmonths = $transolddays / 30;
-my $transneedthresold = 0.75; # percent/100
-
-my ($msgfmt, $date, $grep, $cut) = map {
- my $bin = which($_); die "missing '$_' binary" unless defined $bin; $bin
-} qw(msgfmt date grep cut);
-
-my $averageitem = {'name' => 'Project average', 'out' => 1, 'last' => ''};
-my $contactaddress = 'translations@thewildbeast.co.uk';
-
-# code begins here ----------------------------------------------------------
-sub get_current_date {
- my $utc = qx{$date --utc};
- chop $utc;
- $utc =~ /(\S+)(\s+)(\S+)(\s+)(\S+)(\s+)(\S+)(\D+)(\d+)/;
- return "$5-$3-$9 at $7"."$8";
-}
-
-sub get_trans_age {
- my ($y, $m, $d) = @_;
- return ($y * 365) + ($m * 31) + $d;
-}
-
-my (undef, undef, undef, $mday, $mon, $year, undef, undef) = gmtime(time);
-$year += 1900;
-$mon++;
-my $cage = get_trans_age($year, $mon, $mday); # get current "age"
-
-# drawing a language status row
-sub print_lang {
- my ($langmap, $trans, $fuzzy, $untrans, $tage, $oddeven) = @_;
- return if not $langmap->{'out'};
- my $lang = $langmap->{'name'};
- my $person = $langmap->{'last'};
- my $total = $trans + $fuzzy + $untrans;
- if ($tage == 0) { $tage = $cage; } # hack for average translation
- # print STDERR $cage, " ", $tage, "\n";
- my ($barcolor, $pname, $pemail);
- if (($cage - $tage) < 0) {
- $barcolor = \%barcolorcheat;
- } else {
- $barcolor = (($cage - $tage) > $transolddays)? \%barcoloraged : \%barcolornorm ;
- }
- $_ = $person;
- if (/(.+)\s+\<(.+)\>/) {
- $pname = $1; $pemail = $2;
- } else {
- $pname = $pemail = $contactaddress;
- }
- print '<tr', ($oddeven? ' bgcolor=#EFEFEF': ''), ">\n<td>\n";
- if ($lang eq $averageitem->{'name'}) {
- print "<b>$lang</b>";
- } else {
- print "<a href=\"mailto:%22$pname%22%20<$pemail>\">$lang</a>";
- }
- print "</td>\n";
- print "<td>\n<table style='border: solid 1px black; width: $barwidth'",
- " border='0' cellspacing='0' cellpadding='0'><tr>\n";
- my $barlen = ($trans / $total) * $barwidth;
- print "<td style='width:$barlen", "px; height:$barheight",
- "px;' bgcolor=\"$$barcolor{completed}\"></td>\n";
- my $barlen2 = ($fuzzy / $total) * $barwidth;
- print "<td style='width:$barlen2", "px' bgcolor=\"$$barcolor{partially}\"></td>\n";
- my $barlen3 = $barwidth - $barlen2 - $barlen;
- print "<td style='width:$barlen3", "px' bgcolor=\"$$barcolor{default}\"></td>\n";
- print "</tr>\n</table>\n</td>\n\n<td style='text-align: right'>",
- int(($trans / $total) * 10000) / 100, "%</td>\n";
- my $transtatus = (($trans / $total) < $transneedthresold)
- ? '<font size="+1" color="red"> * </font>': '';
- print "<td>$transtatus</td>\n</tr>\n";
-}
-
-sub tens {
- my ($i) = @_;
- return (($i > 9)? "$i" : "0$i");
-}
-
-my $datetimenow = get_current_date();
-
-# get project version from changelog (project dependent code :-/ )
-my $genversion = 'Unknown';
-my $changelog = '../Changelog';
-if (-s $changelog) {
- my $head = which('head');
- if (defined $head) {
- $_ = qx{$head -1 $changelog};
- if (/\S+\s+\S+\s+(\S+)/) { $genversion = $1; }
- }
-} else {
- my $git = which('git');
- if (defined $git) {
- $_ = qx{$git describe --abbrev=0};
- if (/(\d+\.\d+\.\d)/) { $genversion = $1; }
- }
-}
-
-# start
-print qq ~<div class=indent>
- <b>Translation Status (on $datetimenow for $genversion)</b>
- <div class=indent>
- <table cellspacing=0 cellpadding=2>~;
-
-# table header
-print qq ~<tr bgcolor=#cccccc>
- <th align=left>Language</th>
- <th>Translated|Fuzzy|Untranslated</th>
- <th>Percent</th>
- <th></th>
- </tr>~;
-
-# get files
-my @pofiles;
-opendir(PODIR, ".") || die("Error: can't open current directory\n");
-push(@pofiles,(readdir(PODIR)));
-closedir(PODIR);
-
-my @sorted_pofiles = sort(@pofiles);
-# iterate them
-my ($alang, $atran, $afuzz, $auntr, $oddeven) = (0, 0, 0, 0, 0);
-foreach my $pofile (@sorted_pofiles) {
- $_ = $pofile;
- if (/.+\.po$/ && defined($lang{$pofile}) ) {
- print STDERR "Processing $_\n"; # be a little informative
- ++$alang;
- my ($transage, $tran, $fuzz, $untr) = (0, 0, 0, 0);
- $_ = qx{$msgfmt -c --statistics -o /dev/null $pofile 2>&1};
- if (/([0-9]+)\s+translated/) {
- $tran = $1;
- }
- if (/([0-9]+)\s+fuzzy/) {
- $fuzz = $1;
- }
- if (/([0-9]+)\s+untranslated/) {
- $untr = $1;
- }
- # print STDERR "Translated [$tran] Fuzzy [$fuzz] Untranslated [$untr]\n";
- $atran += $tran;
- $afuzz += $fuzz;
- $auntr += $untr;
- if ($lang{$pofile}->{'lazy'}) {
- $tran = $tran + $fuzz;
- $untr = "0";
- $fuzz = "0";
- $transage = $cage;
- } else {
- $_ = qx{$grep 'PO-Revision-Date:' $pofile | $cut -f2 -d:};
- if (/\s+(\d+)\-(\d+)\-(\d+)/) {
- $transage = get_trans_age($1, $2, $3);
- }
- }
- print_lang($lang{$pofile}, $tran, $fuzz, $untr, $transage, $oddeven);
- $oddeven = $oddeven? 0: 1;
- }
-}
-
-# average results for the project
-print "<tr>\n<td colspan=3 height=8></td>\n<tr>";
-print_lang($averageitem, $atran, $afuzz, $auntr, 0, 0);
-
-# table footer
-print "</table>\n";
-print qq ~</div>
- </div>~;
-
-# done
diff --git a/tools/cm-break.pl b/tools/cm-break.pl
@@ -1,124 +0,0 @@
-#!/usr/bin/perl
-
-use 5.14.1;
-use warnings;
-
-our $VERSION = "1.05 - 2018-10-08";
-our $cmd = $0 =~ s{.*/}{}r;
-
-sub usage {
- my $err = shift and select STDERR;
- say "usage: $cmd file ...";
- exit $err;
- } # usage
-
-use Date::Parse;
-use Getopt::Long;
-GetOptions (
- "help|?" => sub { usage (0); },
- "V|version" => sub { say "$cmd [$VERSION]"; exit 0; },
- ) or usage (1);
-
-my %f;
-foreach my $fn (@ARGV) {
-
- open my $fh, "<", $fn or die "$fn: $!\n";
- my ($hdr, $body) = split m/(?<=\n)(?=\r?\n)/ => do { local $/; <$fh> }, 2;
- close $fh;
-
- $hdr && $hdr =~ m/\b(?:In-Reply-To|References)\b/i or next;
-
- my ($mid) = $hdr =~ m{^Message-Id: (?:[\x20\t]*\n)?[\x20\t]+ (\S.*)}xmi;
- my ($dte) = $hdr =~ m{^Date: (?:[\x20\t]*\n)?[\x20\t]+ (\S.*)}xmi;
- my ($irt) = $hdr =~ m{^In-Reply-To: (?:[\x20\t]*\n)?[\x20\t]+ (\S.*)}xmi;
- my ($ref) = $hdr =~ m{^References: (?:[\x20\t]*\n)?[\x20\t]+ (\S.*)}xmi;
-
- my $stamp = str2time ($dte) or die $dte;
- my $date = $stamp ? do {
- my @d = localtime $stamp;
- sprintf "%4d-%02d-%02d %02d:%02d:%02d", $d[5] + 1900, ++$d[4], @d[3,2,1,0];
- } : "-";
- #printf "%12s %-20s %s\n", $stamp // "-", $date, $rcv;
-
- $f{$fn} = {
- msg_id => $mid,
- refs => $ref,
- irt => $irt,
- date => $dte,
- stamp => $stamp,
- sdate => $date,
-
- hdr => $hdr,
- body => $body,
- };
- }
-
-foreach my $fn (sort keys %f) {
-
- my $c = 0;
-
- my $f = $f{$fn};
- if ($f->{refs}) {
- $c++;
- $f->{hdr} =~ s{\nReferences:.*(?:\n\s+.*)*+}{}ig;
- }
- if ($f->{irt}) {
- $c++;
- $f->{hdr} =~ s{\nIn-Reply-To:.*(?:\n\s+.*)*+}{}ig;
- }
-
- $c or next; # No changes required
-
- say "$f->{msg_id} => -";
-
- my @t = stat $fn;
- open my $fh, ">", $fn or die "$fn: $!\n";
- print $fh $f->{hdr}, $f->{body};
- close $fh or die "$fn: $!\n";
- utime $t[8], $t[9], $fn;
- }
-
-__END__
-
-=head1 NAME
-
-cm-break.pl - remove mail from thread
-
-=head1 SYNOPSIS
-
- cm-break.pl ~/Mail/inbox/23 ~/Mail/inbox/45 ...
-
-=head1 DESCRIPTION
-
-This script should be called from within Claws-Mail as an action
-
-Define an action as
-
- Menu name: Unthread (break threading)
- Command: cm-break.pl %F
-
-Then select from the message list all files that should be un-threaded
-
-Then invoke the action
-
-All of those mails will be modified (if needed): their C<In-Reply-To:>
-and C<References:> header tags are removed from the header.
-
-=head1 SEE ALSO
-
-L<Date::Parse>, L<Claws Mail|http://www.claws-mail.org>
-cm-reparent.pl
-
-=head1 AUTHOR
-
-H.Merijn Brand <h.m.brand@xs4all.nl>
-
-=head1 COPYRIGHT AND LICENSE
-
- Copyright (C) 2018-2018 H.Merijn Brand. All rights reserved.
-
-This library is free software; you can redistribute and/or modify it under
-the same terms as Perl itself.
-See the L<Artistic license|http://dev.perl.org/licenses/artistic.html>.
-
-=cut
diff --git a/tools/cm-reparent.pl b/tools/cm-reparent.pl
@@ -1,186 +0,0 @@
-#!/usr/bin/perl
-
-use 5.14.1;
-use warnings;
-
-our $VERSION = "1.05 - 2018-10-08";
-our $cmd = $0 =~ s{.*/}{}r;
-
-sub usage {
- my $err = shift and select STDERR;
- say "usage: $cmd file ...";
- exit $err;
- } # usage
-
-use Date::Parse;
-use Getopt::Long;
-GetOptions (
- "help|?" => sub { usage (0); },
- "V|version" => sub { say "$cmd [$VERSION]"; exit 0; },
- ) or usage (1);
-
-my $p;
-my %f;
-foreach my $fn (@ARGV) {
-
- open my $fh, "<", $fn or die "$fn: $!\n";
- my ($hdr, $body) = split m/(?<=\n)(?=\r?\n)/ => do { local $/; <$fh> }, 2;
- close $fh;
-
- $hdr && $hdr =~ m/\b(?:Date|Received)\b/ or next;
-
- my ($mid) = $hdr =~ m{^Message-Id: (?:[\x20\t]*\n)?[\x20\t]+ (\S.*)}xmi;
- my ($dte) = $hdr =~ m{^Date: (?:[\x20\t]*\n)?[\x20\t]+ (\S.*)}xmi;
- my ($rcv) = $hdr =~ m{\nReceived: (?:[\x20\t]*\n)?[\x20\t]+ (\S.*(?:\n\s+.*)*+)}xi;
- my ($irt) = $hdr =~ m{^In-Reply-To: (?:[\x20\t]*\n)?[\x20\t]+ (\S.*)}xmi;
- my ($ref) = $hdr =~ m{^References: (?:[\x20\t]*\n)?[\x20\t]+ (\S.*)}xmi;
-
- $rcv ||= $dte;
- $rcv =~ s/[\s\r\n]+/ /g;
- $rcv =~ s/\s+$//;
- $rcv =~ s/.*;\s*//;
- $rcv =~ s/.* id \S+\s+//i;
- my $stamp = str2time ($rcv) or die $rcv;
- my $date = $stamp ? do {
- my @d = localtime $stamp;
- sprintf "%4d-%02d-%02d %02d:%02d:%02d", $d[5] + 1900, ++$d[4], @d[3,2,1,0];
- } : "-";
- #printf "%12s %-20s %s\n", $stamp // "-", $date, $rcv;
-
- $f{$fn} = {
- msg_id => $mid,
- refs => $ref,
- irt => $irt,
- date => $dte,
- rcvd => $rcv,
- stamp => $stamp,
- sdate => $date,
-
- hdr => $hdr,
- body => $body,
- };
-
- $p //= $fn;
- $stamp < $f{$p}{stamp} and $p = $fn;
- }
-
-# All but the oldest will refer to the oldest as parent
-
-$p or exit 0;
-my $pid = $f{$p}{msg_id} or die "Parent file $p has no Message-Id\n";
-
-foreach my $fn (sort keys %f) {
-
- $fn eq $p and next;
-
- my $c = 0;
-
- my $f = $f{$fn};
- if ($f->{refs}) {
- unless ($f->{refs} eq $pid) {
- $c++;
- $f->{hdr} =~ s{^(?=References:)}{References: $pid\nX-}mi;
- }
- }
- else {
- $c++;
- $f->{hdr} =~ s{^(?=Message-Id:)}{References: $pid\n}mi;
- }
- if ($f->{irt}) {
- unless ($f->{irt} eq $pid) {
- $c++;
- $f->{hdr} =~ s{^(?=In-Reply-To:)}{In-Reply-To: $pid\nX-}mi;
- }
- }
- else {
- $c++;
- $f->{hdr} =~ s{^(?=Message-Id:)}{In-Reply-To: $pid\n}mi;
- }
-
- $c or next; # No changes required
-
- unless ($f->{msg_id}) {
- warn "Child message $fn has no Message-Id, skipped\n";
- next;
- }
-
- say "$f->{msg_id} => $pid";
-
- my @t = stat $fn;
- open my $fh, ">", $fn or die "$fn: $!\n";
- print $fh $f->{hdr}, $f->{body};
- close $fh or die "$fn: $!\n";
- utime $t[8], $t[9], $fn;
- }
-
-__END__
-
-=head1 NAME
-
-cm-reparent.pl - fix mail threading
-
-=head1 SYNOPSIS
-
- cm-reparent.pl ~/Mail/inbox/23 ~/Mail/inbox/45 ...
-
-=head1 DESCRIPTION
-
-This script should be called from within Claws-Mail as an action
-
-Define an action as
-
- Menu name: Reparent (fix threading)
- Command: cm-reparent.pl %F
-
-Then select from the message list all files that should be re-parented
-
-Then invoke the action
-
-All but the oldest of those mails will be modified (if needed) to
-reflect that the oldest mail is the parent of all other mails by
-adding or altering the header lines C<In-Reply-To:> and C<References:>
-
-Given 4 files A, B, C, and D like
-
- File Message-Id Date
- A 123AC_12 2016-06-01 12:13:14
- B aFFde2993 2016-06-01 13:14:15
- C 0000_1234 2016-06-02 10:18:04
- D foo_bar_12 2016-06-03 04:00:00
-
-The new tree will be like
-
- A 123AC_12 2016-06-01 12:13:14
- +- B aFFde2993 2016-06-01 13:14:15
- +- C 0000_1234 2016-06-02 10:18:04
- +- D foo_bar_12 2016-06-03 04:00:00
-
-and not like
-
- A 123AC_12 2016-06-01 12:13:14
- +- B aFFde2993 2016-06-01 13:14:15
- +- C 0000_1234 2016-06-02 10:18:04
- +- D foo_bar_12 2016-06-03 04:00:00
-
-Existing entries of C<References:> and C<In-Reply-To:> in the header
-of any of B, C, or D will be preserved as C<X-References:> or
-C<X-In-Reply-To:> respectively.
-
-=head1 SEE ALSO
-
-L<Date::Parse>, L<Claws Mail|http://www.claws-mail.org>
-cm-break.pl
-
-=head1 AUTHOR
-
-H.Merijn Brand <h.m.brand@xs4all.nl>
-
-=head1 COPYRIGHT AND LICENSE
-
- Copyright (C) 2016-2018 H.Merijn Brand. All rights reserved.
-
-This library is free software; you can redistribute and/or modify it under
-the same terms as Perl itself.
-See the L<Artistic license|http://dev.perl.org/licenses/artistic.html>.
-
-=cut
diff --git a/tools/convert_mbox.pl b/tools/convert_mbox.pl
@@ -1,188 +0,0 @@
-#!/usr/bin/perl
-# convert_mbox.pl
-# perl script to convert mbox file to files in a new MH directory
-# aka another mbox -> MH conversion tool
-# 29 April 2003
-# Fred Marton <Fred.Marton@uni-bayreuth.de>
-#
-# Fixed (hopefully) to account for From lines
-# that are of various length and that might have
-# time zone info at the end
-# 20 January 2004
-#
-# Note: Running this with the -w flag generates the following warnings:
-# Scalar value @word[1] better written as $word[1] at /path/to/convert_mbox.pl line 54
-# Scalar value @word[0] better written as $word[1] at /path/to/convert_mbox.pl line 56
-# Making these changes requires further changes in the script
-# that results in much longer run-times.
-#
-# Copyright (c) 2003 Fred Marton
-# Copyright (c) 2009 Ricardo Mones, based on the bash script
-# by Daniel Dickinson [1]
-#
-# 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 Free Software Foundation; either version 3
-# of the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
-# 02111-1307, USA.
-#
-# [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;filename=convert_mbox.sh;att=1;bug=461435
-
-use File::Path;
-use File::Basename;
-
-# check for arguments
-&usage if ($#ARGV < 1);
-if ($ARGV[0] eq "-R") {
- # recursive, need more args
- &usage if ($#ARGV < 2);
- &usage unless (-d $ARGV[1]);
- &usage unless (-d $ARGV[2]);
- &convert_all ($ARGV[1], $ARGV[2]);
-}
-else {
- # default behaviour
- &convert_mbox ($ARGV[0], $$ARGV[1]);
-}
-
-sub strip_sbd {
- # raw translation of bash, probably doable in real Perl better
- $dirname = shift;
- $nosbddir = "";
- $dirleft = $dirname;
- while ($dirleft ne "." and $dirleft ne "") {
- $enddir = &basename ($dirleft, ['.sbd']);
- if ($nosbddir ne "") {
- $nosbddir = "$enddir/$nosbddir";
- }
- else {
- $nosbddir = $enddir;
- }
- $dirleft = &dirname ($dirleft);
- }
- print "$nosbddir\n";
-}
-
-sub convert_all {
- ($mboxdir, $targetdir) = @_;
- $tmpbase = '/tmp/frommbox';
- $tmplist = '/tmp/.convert_mbox.filelist';
- $curdir = qx/pwd/;
- chdir ($mboxdir);
- qx/find * -type -d -a ! -name '*.*'i | sort > $tmplist/;
- open (FLH, "<$tmplist") or die "cannot open $tmplist: $!\n";
- while (<FLH>) {
- chomp;
- &convert_one ($_, $targetdir, $tmpbase);
- }
- close (FLH);
- unlink ($tmplist);
- chdir ($curdir);
-}
-
-sub convert_one {
- # targetdir isn't used in the original bash script, maybe a bug?
- ($file, $targetdir, $tmpbase) = @_;
- $dirname = &dirname ($file);
- $filename = &basename ($file);
- if ($dirname eq $filename) {
- $dirname = "";
- }
- $dirname = &strip_sbd ($dirname);
- if ($dirname ne "") {
- $dirname = "/$dirname";
- }
- &mkpath ($tmpbase . $dirname);
- $basefile = &basename ($file);
- $base1 = &basename ($file, ['.cmeta']);
- $base2 = &basename ($base1, ['.ibex.index']);
- $base3 = &basename ($base2, ['.ibex.index.data']);
- $base5 = &basename ($base3, ['.ev-summary']);
- $base4 = &basename ($base5, ['.ev-summary-meta']);
- $subdir = &basename ($dirname);
- $basedir = "/" . &dirname ($dirname);
- if ( $basedir eq '/.' or $basedir eq '/' ) {
- $basedir = $dirname;
- $subdir = "";
- }
- $basedir = $tmpbase . $basedir;
- &mkpath ($basedir);
- $dirisfile = 0;
- if ( -f "$basedir/$subdir" ) {
- $dirisfile = 1;
- qx/mv \"$basedir\/$subdir\" \"$basedir\/$subdir.tmp\"/;
- &mkpath ("$basedir/$subdir");
- }
- if ( ! -d "$basedir/$subdir/$base4" ) {
- print "$basedir/$subdir/$base4\n";
- &convert_mbox ($file, "$basedir/$subdir/$base4", 'quiet');
- if ($dirisfile == 1) {
- qx/mv \"$basedir\/$subdir.tmp\/*\" \"$basedir\/$subdir\/\"/;
- }
- }
-}
-
-
-sub convert_mbox {
- ($mbox, $mh, $quiet) = @_;
- # check to make sure there isn't something named MH already
- if (-e $mh) {
- die (" The directory \"$mh\" already exists. Exiting.\n");
- }
- else {
- mkdir $mh;
- }
- # start numbering
- $i = 0;
- # open the mbox file
- open (IN, $mbox);
- while ($line = <IN>) {
- # check for the beginning of an e-mail
- @word = split(/ +/m,$line);
- # some lines might start with "From ", so check
- # to see if the [second-to-]last word is a year
- @word2 = split(/:/,$line);
- chomp($word2[$#word2]);
- @word3 = split(/ /,$word2[2]);
- $year = @word3[1];
- # ignore the MAILER-DAEMON message from pine
- if (@word[1] ne "MAILER-DAEMON") {
- # start a new file, assuming $year is > 1970
- if (@word[0] eq "From" && $year > 1970) {
- $i++;
- close (OUT);
- open (OUT, ">$mh/$i");
- print OUT $line;
- }
- else {
- # continue the file
- print OUT $line;
- }
- }
- }
- close (OUT);
- close (IN);
- # and we're done
- if (! defined($quiet)) {
- print "\n If it isn't there already, please move the directory \"$mh\"\n"
- . " into your MH directory and rebuild your folder tree.\n\n";
- }
-}
-
-sub usage {
- die ("Usage: convert_mbox.pl MBOX MH_DIR\n"
- . " convert_mbox.pl -R MBOXDIR MH_DIR\n"
- . "Where: \n"
- . " -R Converts recursively a directory of mboxes\n");
-}
-
-
diff --git a/tools/csv2addressbook.pl b/tools/csv2addressbook.pl
@@ -1,423 +0,0 @@
-#!/usr/bin/perl -w
-
-use strict;
-use Getopt::Long qw(:config pass_through);
-use Text::CSV_XS;
-
-# * This file is free software; you can redistribute it and/or modify it
-# * under the terms of the GNU General Public License as published by
-# * the Free Software Foundation; either version 3 of the License, or
-# * (at your option) any later version.
-# *
-# * This program is distributed in the hope that it will be useful, but
-# * WITHOUT ANY WARRANTY; without even the implied warranty of
-# * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# * General Public License for more details.
-# *
-# * You should have received a copy of the GNU General Public License
-# * along with this program; if not, write to the Free Software
-# * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-# *
-# * Copyright 2007/2008 Paul Mangan <paul@claws-mail.org>
-# *
-
-#
-# Import CSV exported address books to Claws Mail
-# Supported address books:
-# Becky >= 2.41
-# Thunderbird >= 2.0.0.6
-# Kmail >= 1.9.7 / Kaddressbook >= 3.5.7
-# ** kmail bug: can export badly formatted csv **
-# Gmail
-# Fox Mail
-#
-
-# Becky: full export with titles
-# thunderbird: export as 'comma separated'
-# kmail/kaddressbook: Export CSV list
-# gmail: export Outlook format
-# foxmail: export with all possible headers
-# basic: a csv file only containing these fields 'First Name', 'Last Name', 'Nickname', 'Email Address'
-
-###
-my $quote_char = '"';
-my $esc_char = '"';
-my $sep_char = ',';
-###
-
-my $script = "csv2addressbook.pl";
-my $type = '';
-my $csvfile = '';
-my $bookname = '';
-my $iNeedHelp = '';
-
-my $known_types = qr/^(?:becky|thunderbird|kmail|gmail|foxmail|basic)$/;
-
-GetOptions("type=s" => \$type,
- "csv=s" => \$csvfile,
- "name=s" => \$bookname,
- "help" => \$iNeedHelp);
-
-my @becky_fields = ('Name','E-mail Address', 'Nickname (Input shortcut)',
- 'Web Page','Notes','Company','Department','Job Title',
- 'Job Role','Last Name','First Name','Middle Name',
- 'Birthday','Home Phone','Business Phone','Mobile Phone',
- 'Fax','Street','City','State','Postal Code','Country',
- 'Delivery Label');
-my @tbird_fields = ('First Name','Last Name','Display Name','Nickname',
- 'Primary Email','Secondary Email','Work Phone',
- 'Home Phone','Fax Number','Pager Number','Mobile Number',
- 'Home Address','Home Address 2','Home City','Home State',
- 'Home ZipCode','Home Country','Work Address','Work Address 2',
- 'Work City','Work State','Work ZipCode','Work Country',
- 'Job Title','Department','Organization','Web Page 1',
- 'Web Page 2','Birth Year','Birth Month','Birth Day',
- 'Custom 1','Custom 2','Custom 3','Custom 4','Notes',
- 'Anniversary Year','Anniversary Month','Anniversary Day',
- 'Category','Spouse name');
-my @kmail_fields = ('Formatted Name','Family Name','Given Name',
- 'Additional Names','Honorific Prefixes','Honorific Suffixes',
- 'Nick Name','Birthday','Home Address Street',
- 'Home Address City','Home Address Region',
- 'Home Address Post Code','Home Address Country',
- 'Home Address Label','Business Address Street',
- 'Business Address City','Business Address Region',
- 'Business Address Post Code','Business Address Country',
- 'Business Address Label','Home Phone','Business Phone',
- 'Mobile Phone','Home Fax','Business Fax','Car Phone','ISDN',
- 'Pager','Email Address','Mail Client','Title','Role',
- 'Organisation','Department','Note','Homepage','Profession',
- 'Assistant\'s Name','Manager\'s Name','Partner\'s Name',
- 'Office','IM Address','Anniversary','Blog');
-my @gmail_fields = ('Name','E-mail Address','Notes','E-mail 2 Address',
- 'E-mail 3 Address','Mobile Phone','Pager','Company',
- 'Job Title','Home Phone','Home Phone 2','Home Fax',
- 'Home Address','Business Phone','Business Phone 2',
- 'Business Fax','Business Address','Other Phone','Other Fax',
- 'Other Address','junk');
-my @foxmail_fields = ('First Name','Last Name','Name','Nickname','e-mail Address',
- 'Mobile Phone','Pager Number','QQ','ICQ','Personal Home Page',
- 'Sex','Birthday','Interest','Home Country','Home Province',
- 'Home City','Home Postal Code','Home Street Address',
- 'Home Telephone 1','Home Telephone 2','Home Fax','Office Company',
- 'Office Country','Office Province','Office City',
- 'Office Postal Code','Office Address','Office HomePage',
- 'Office Position','Office Department','Office Telephone 1',
- 'Office Telephone 2','Office Fax','Memo','foxaddrID');
-my @basic_fields = ('Nickname','e-mail Address');
-
-if (grep m/claws-mail/ => `ps -U $ENV{USER}`) {
- die("You must quit claws-mail before running this script\n");
-}
-
-if ($csvfile eq "" || $type eq "" || $type !~ m/$known_types/ || $iNeedHelp) {
- if (!$iNeedHelp) {
- if ($csvfile eq "") {
- print "ERROR: Option csv is missing!\n";
- }
- if ($type eq "") {
- print "ERROR: Option type is missing!\n";
- }
- if ($type && $type !~ m/$known_types/) {
- print "ERROR: \"$type\" is an unknown type!\n";
- }
- }
- print qq~
-Usage:
- $script [OPTIONS]
-Options:
- --help Show this screen
- --type=becky|thunderbird|kmail|gmail|foxmail|basic
- Type of exported address book
- --csv=FILENAME Full path to CSV file
- --name="My new address book" Name of new Claws address book (optional)
-~;
-exit;
-}
-
-open(INPUT, "<$csvfile") || die("Can't open the CSV file [$csvfile]\n");
- my @csvlines = <INPUT>;
-close INPUT;
-
-my $config_dir = `claws-mail --config-dir` || die("ERROR:
- You don't appear to have Claws Mail installed\n");
-chomp $config_dir;
-
-my $claws_version = `claws-mail --version`;
-$claws_version =~ s/^Claws Mail version //;
-
-my ($major, $minor) = split(/\./, $claws_version);
-
-my $addr_dir;
-
-if (($major == 3 && $minor >= 1) || $major > 3) {
- $addr_dir = "$config_dir/addrbook";
-} else {
- $addr_dir = $config_dir;
-}
-
-my $addr_index = "$addr_dir/addrbook--index.xml";
-my $csv = Text::CSV_XS->new({binary => 1,
- quote_char => $quote_char,
- escape_char => $esc_char,
- sep_char => $sep_char});
-
-my $csvtitles = shift(@csvlines);
-
-$csv->parse($csvtitles);
-my @csvfields = $csv->fields;
-
-check_fields();
-
-my $new_addrbook = $bookname || get_book_name();
-
-my $xmlobject = write_xml();
-
-chdir;
-
-my @filelist = ();
-opendir(ADDR_DIR, $addr_dir) || die("Can't open $addr_dir directory\n");
- push(@filelist, (readdir(ADDR_DIR)));
-closedir(ADDR_DIR);
-
-my @files = ();
-foreach my $file (@filelist) {
- if ($file =~ m/^addrbook/ && $file =~ m/[0-9].xml$/) {
- push(@files, "$file");
- }
-}
-
-my @sorted_files = sort {$a cmp $b} @files;
-my $latest_file = pop(@sorted_files);
-$latest_file =~ s/^addrbook-//;
-$latest_file =~ s/.xml$//;
-$latest_file++;
-my $new_addrbk = "addrbook-"."$latest_file".".xml";
-
-open (NEWADDR, ">$addr_dir/$new_addrbk");
-print NEWADDR $xmlobject;
-close NEWADDR;
-
-open (ADDRIN, "<$addr_index") || die("can't open $addr_index for reading");
- my @addrindex_file = <ADDRIN>;
-close ADDRIN;
-
-my $rw_addrindex;
-foreach my $addrindex_line (@addrindex_file) {
- if ($addrindex_line =~ m/<\/book_list>/) {
- $rw_addrindex .= " <book name=\"$new_addrbook\" "
- ."file=\"$new_addrbk\" />\n </book_list>\n";
- } else {
- $rw_addrindex .= "$addrindex_line";
- }
-}
-
-open (NEWADDRIN, ">$addr_index") || die("Can't open $addr_index for writing");
-print NEWADDRIN "$rw_addrindex";
-close NEWADDRIN;
-
-print "Done. Address book imported successfully.\n";
-
-exit;
-
-sub get_book_name {
- if ($type eq "becky") {
- return("Becky address book");
- } elsif ($type eq "thunderbird") {
- return("Thunderbird address book");
- } elsif ($type eq "kmail") {
- return("Kmail address book");
- } elsif ($type eq "gmail") {
- return("gmail address book");
- } elsif ($type eq "foxmail") {
- return("foxmail address book");
- } elsif ($type eq "basic") {
- return("basic address book");
- }
-}
-
-sub check_fields {
- if ($type eq "becky") {
- if ($#csvfields != $#becky_fields) {
- die("ERROR:\n\tInvalid field count!\n"
- ."\tYou need to do a Full Export With Titles\n");
- }
- } elsif ($type eq "thunderbird") {
- if ($#csvfields != $#tbird_fields) {
- die("ERROR:\n\tInvalid field count!\n"
- ."\tProblem with your exported CSV file\n");
- }
- } elsif ($type eq "kmail") {
- if ($#csvfields != $#kmail_fields) {
- die("ERROR:\n\tInvalid field count!\n"
- ."\tProblem with your exported CSV file\n");
- }
- } elsif ($type eq "gmail") {
- if ($#csvfields != $#gmail_fields) {
- die("ERROR:\n\tInvalid field count!\n"
- ."\tProblem with your exported CSV file\n");
- }
- } elsif ($type eq "foxmail") {
- if ($#csvfields != $#foxmail_fields) {
- die("ERROR:\n\tInvalid field count!\n"
- ."\tProblem with your exported CSV file\n");
- }
- } elsif ($type eq "basic") {
- if ($#csvfields != $#basic_fields) {
- die("ERROR:\n\tInvalid field count!\n"
- ."\tProblem with your exported CSV file\n");
- }
- }
-}
-
-sub write_xml {
- my @std_items = get_items();
- my @input_fields = get_fields();
-
- my $time = time;
- my $xml = "<?xml version=\"1.0\" encoding=\"UTF-8\" ?>\n"
- ."<address-book name=\"$new_addrbook\" >\n ";
-
- my $prev_line;
-
- foreach my $line (@csvlines) {
- $csv->parse($line);
- my @fields = $csv->fields;
- # check if an entry contains line breaks
- if ($#fields != $#input_fields) {
- if ($prev_line) {
- my $concat_line = $prev_line.$line;
- $csv->parse($concat_line);
- @fields = $csv->fields;
- if ($#fields != $#input_fields) {
- $concat_line =~ s/\r\n$/ /;
- $concat_line =~ s/\n$/ /;
- $prev_line = $concat_line;
- next;
- }
- } else {
- $line =~ s/\r\n$/ /;
- $line =~ s/\n$/ /;
- $prev_line = $line;
- next;
- }
- }
- $prev_line = '';
-
- @fields = escape_fields(@fields);
-
- $xml .= "<person uid=\"$time\" "
- ."first-name=\"$fields[$std_items[0]]\" "
- ."last-name=\"$fields[$std_items[1]]\" "
- ."nick-name=\"$fields[$std_items[2]]\" "
- ."cn=\"$fields[$std_items[3]]\">\n ";
- $time++;
- if ($type eq "thunderbird") {
- $xml .= "<address-list>\n "
- ."<address uid=\"$time\" alias=\"\" "
- ."email=\"$fields[$std_items[4]]\" "
- ."remarks=\"\" /> \n";
- $time++;
- if ($fields[$std_items[5]]) {
- $xml .=" <address uid=\"$time\" alias=\"\" "
- ."email=\"$fields[$std_items[5]]\" "
- ."remarks=\"\" /> \n";
- }
- $xml .= " </address-list> \n";
- } elsif ($type eq "foxmail") {
- $xml .= "<address-list>\n ";
- if ($fields[$std_items[4]] =~ m/,/) {
- my @addrs = split(",", $fields[$std_items[4]]);
- my $addr_one = pop(@addrs);
- $xml .= "<address uid=\"$time\" alias=\"\" "
- ."email=\"$addr_one\" "
- ."remarks=\"$fields[$std_items[5]]\" /> \n";
- foreach my $eaddr (@addrs) {
- $time++;
- $xml .= "<address uid=\"$time\" alias=\"\" "
- ."email=\"$eaddr\" "
- ."remarks=\"\" /> \n";
- }
- } else {
- $xml .= "<address uid=\"$time\" alias=\"\" "
- ."email=\"$fields[$std_items[4]]\" "
- ."remarks=\"$fields[$std_items[5]]\" /> \n";
- }
- $xml .= "</address-list> \n";
- } else {
- $xml .= "<address-list>\n "
- ."<address uid=\"$time\" alias=\"\" "
- ."email=\"$fields[$std_items[4]]\" "
- ."remarks=\"$fields[$std_items[5]]\" /> \n"
- ."</address-list> \n";
- }
- $xml .= "<attribute-list>\n";
- foreach my $item (@std_items) {
- delete($fields[$item]);
- }
- foreach my $field (0 .. $#fields) {
- if ($fields[$field]) {
- $time++;
- $xml .= " <attribute uid=\"$time\" "
- ."name=\"$input_fields[$field]\">"
- ."$fields[$field]</attribute>\n";
- }
- }
- $xml .= " </attribute-list>\n "
- ."</person>\n";
- $time++;
- }
-
- $xml .= "</address-book>\n";
-
- return $xml;
-}
-
-sub get_items {
- if ($type eq "becky") {
- return ('10','9','2','0','1','4');
- } elsif ($type eq "thunderbird") {
- return ('0','1','3','2','4','5','38');
- } elsif ($type eq "kmail") {
- return ('2','1','6','0','28','34');
- } elsif ($type eq "gmail") {
- return('0','0','0','0','1','2');
- } elsif ($type eq "foxmail") {
- return ('0','1','3','2','4','33');
- } elsif ($type eq "basic") {
- return ('0','0','0','0','1','0');
- }
-}
-
-sub get_fields {
- if ($type eq "becky") {
- return(@becky_fields);
- } elsif ($type eq "thunderbird") {
- return(@tbird_fields);
- } elsif ($type eq "kmail") {
- return(@kmail_fields);
- } elsif ($type eq "gmail") {
- return(@gmail_fields);
- } elsif ($type eq "foxmail") {
- return(@foxmail_fields);
- } elsif ($type eq "basic") {
- return (@basic_fields);
- }
-}
-
-sub escape_fields {
- my (@fields) = @_;
-
- for (my $item = 0; $item <= $#fields; $item++) {
- $fields[$item] =~ s/^"//;
- $fields[$item] =~ s/"$//;
- $fields[$item] =~ s/"/"/g;
- $fields[$item] =~ s/&/&/g;
- $fields[$item] =~ s/'/'/g;
- $fields[$item] =~ s/</</g;
- $fields[$item] =~ s/>/>/g;
- }
-
- return @fields;
-}
-
diff --git a/tools/ddg_search.pl b/tools/ddg_search.pl
@@ -1,62 +0,0 @@
-#!/usr/bin/perl
-
-# * Copyright 2003-2019 Paul Mangan <paul@claws-mail.org>
-# *
-# * This file is free software; you can redistribute it and/or modify it
-# * under the terms of the GNU General Public License as published by
-# * the Free Software Foundation; either version 3 of the License, or
-# * (at your option) any later version.
-# *
-# * This program is distributed in the hope that it will be useful, but
-# * WITHOUT ANY WARRANTY; without even the implied warranty of
-# * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# * General Public License for more details.
-# *
-# * You should have received a copy of the GNU General Public License
-# * along with this program; if not, write to the Free Software
-# * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-# *
-
-# Changes:
-# Feb 2007: add support for non ISO-8859-1 compatible locales
-# by Alex Gorbachenko <agent_007@immo.ru>
-#
-
-use URI::Escape;
-use POSIX qw(locale_h);
-use locale;
-use Text::Iconv;
-
-my $ddg = "https://duckduckgo.com/?q";
-$_ = <>;
-
-$locale = setlocale(LC_CTYPE);
-$locale =~ s/\S+\.//;
-
-$converter = Text::Iconv->new("$locale", "UTF-8");
-$safe=uri_escape($converter->convert("$_"));
-
-my $config_dir = `claws-mail --config-dir` or die("ERROR:
- You don't appear to have Claws Mail installed\n");
-chomp $config_dir;
-
-chdir($ENV{HOME} . "/$config_dir") or die("ERROR:
- Claws Mail config directory not found [~/$config_dir]
- You need to run Claws Mail once, quit it, and then rerun this script\n");
-
-open (CMRC, "<clawsrc") || die("Can't open the clawsrc file\n");
- @rclines = <CMRC>;
-close CMRC;
-
-foreach $rcline (@rclines) {
- if ($rcline =~ m/^uri_open_command/) {
- chomp $rcline;
- @browser = split(/=/, $rcline);
- $browser[1] =~ s/%s/$ddg=$safe/;
- }
-}
-system("$browser[1]&");
-
-exit;
-
-
diff --git a/tools/eud2gc.py b/tools/eud2gc.py
@@ -1,69 +0,0 @@
-#!/usr/bin/env python3
-
-import string, sys
-
-
-def lReadEfile(sFileName):
- try:
- sLines = open(sFileName).read()
- except:
- print ('Error opening %s' %sFileName)
- lLines = []
- lLines = sLines.split('\n')
- return lLines
-
-
-def dElines2Dict(lElines):
- dAliases = {}
- for sEntry in lElines:
- if '"' in sEntry:
- lChunks = sEntry.split('"')
- else:
- lChunks = sEntry.split(' ')
- if lChunks[0] != 'alias':
- print ('ignoring invalid line: %s' %sEntry)
- else:
- sAdresses = lChunks[2:].join(',')
- print ('Entry added: %s %s' %(lChunks[1],sEntry))
- dAliases[lChunks[1]]=sAdresses
- return dAliases
-
-
-def vWriteGfile(dAliases, sFileName):
- try:
- oFile = open(sFileName, 'w')
- except:
- print ('Error opening %s' %sFileName)
- return 0
- for sKey in dAliases.keys():
- #print ('BEGIN:VCARD')
- #print ('N:;%s' %sKey)
- #print ('BDAY:')
- #print ('ADR;HOME:;;;;;;')
- #print ('TEL:;')
- #print ('EMAIL;INTERNET:%s' %dAliases[sKey])
- #print ('END:VCARD')
- oFile.write ('BEGIN:VCARD\n')
- oFile.write ('FN:%s\n' %sKey)
- oFile.write ('N:;%s\n' %sKey)
- oFile.write ('BDAY:\n')
- oFile.write ('ADR;HOME:;;;;;;;\n')
- oFile.write ('TEL:;\n')
- oFile.write ('EMAIL;INTERNET:%s\n' %dAliases[sKey])
- oFile.write ('END:VCARD\n')
- oFile.close()
- return 1
-
-
-if __name__ == '__main__':
- if len(sys.argv) >= 3:
- sEfileName = sys.argv[1]
- sGfileName = sys.argv[2]
- lAliases = lReadEfile(sEfileName)
- dAliases = dElines2Dict(lAliases)
- if vWriteGfile(dAliases, sGfileName) == 1:
- print ('Done!')
- else:
- print ('Error saving output-file')
- else:
- print ('Usage:\n %s <Eudora addressbook> <Gnomecard file>' %sys.argv[0])
diff --git a/tools/filter_conv.pl b/tools/filter_conv.pl
@@ -1,172 +0,0 @@
-#!/usr/bin/perl -w
-use strict;
-
-# * Copyright 2002 Paul Mangan <paul@claws-mail.org>
-# *
-# * Reimplemented by Torsten Schoenfeld <kaffeetisch@web.de>
-# *
-# * This file is free software; you can redistribute it and/or modify it
-# * under the terms of the GNU General Public License as published by
-# * the Free Software Foundation; either version 3 of the License, or
-# * (at your option) any later version.
-# *
-# * This program is distributed in the hope that it will be useful, but
-# * WITHOUT ANY WARRANTY; without even the implied warranty of
-# * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# * General Public License for more details.
-# *
-# * You should have received a copy of the GNU General Public License
-# * along with this program; if not, write to the Free Software
-# * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-# *
-
-my $old_config_dir = "$ENV{HOME}/.sylpheed";
-my $config_dir = `claws-mail --config-dir`;
-chomp $config_dir;
-
-chdir($ENV{ HOME } . "/$config_dir")
- or die("You don't appear to have Claws Mail installed\n");
-
-###############################################################################
-
-my $normal_headers = qr/^(?:Subject|From|To|Cc)$/;
-
-my @new_filters = ("[global]\n");
-
-###############################################################################
-
-my $mailbox;
-
-open(FOLDERLIST, "<$old_config_dir/folderlist.xml")
- or die("Can't find '$old_config_dir/folderlist.xml'\n");
- while (<FOLDERLIST>) {
- if (m/<folder type="mh" name="([^"]+)" path="[^"]+"/) {
- $mailbox = $1;
- last;
- }
- }
-close FOLDERLIST;
-
-###############################################################################
-
-open(FILTERRC, "<$old_config_dir/filterrc")
- or die("Can't find your old filter rules ('$old_config_dir/filterrc')\n");
- while (<FILTERRC>) {
- chomp();
-
- my ($header_one,
- $value_one,
- $op,
- $header_two,
- $value_two,
- $destination,
- $mode_one,
- $mode_two,
- $action) = split(/\t/);
-
- $value_one =~ s/\"/\\\"/g ;
- $value_two =~ s/\"/\\\"/g ;
- $action = $action eq "m" ? "move" : "delete";
- $destination = $destination =~ m!^\#mh/! ?
- $destination :
- "#mh/$mailbox/$destination";
-
- my ($predicate_one,
- $predicate_two,
- $match_type_one,
- $match_type_two,
- $new_filter);
-
- ###########################################################################
-
- if ($mode_one % 2 == 0) {
- $predicate_one = "~";
- }
- else {
- $predicate_one = "";
- }
-
- if ($mode_one <= 1) {
- $match_type_one = "matchcase";
- }
- else {
- $match_type_one = "regexpcase";
- }
-
- ###########################################################################
-
- if ($mode_two % 2 == 0) {
- $predicate_two = "~";
- }
- else {
- $predicate_two = "";
- }
-
- if ($mode_two <= 1) {
- $match_type_two = "matchcase";
- }
- else {
- $match_type_two = "regexpcase";
- }
-
- ###########################################################################
-
- if ($header_one eq "To" && $header_two eq "Cc" ||
- $header_one eq "Cc" && $header_two eq "To" and
- $value_one eq $value_two and
- $mode_one eq $mode_two and
- $op eq "|") {
- if ($action eq "move") {
- $new_filter = $predicate_one . qq(to_or_cc $match_type_one "$value_one" move "$destination"\n);
- }
- else {
- $new_filter = $predicate_one . qq(to_or_cc $match_type_one "$value_one" delete\n);
- }
- }
- else {
- if ($header_one =~ m/$normal_headers/) {
- $new_filter .= $predicate_one . lc($header_one) . qq( $match_type_one "$value_one");
- }
- else {
- $new_filter .= $predicate_one . qq(header "$header_one" $match_type_one "$value_one");
- }
-
- if ($op ne " ") {
- if ($header_two =~ m/$normal_headers/) {
- $new_filter .= qq( $op ) . $predicate_two . lc($header_two) . qq( $match_type_two "$value_two");
- }
- else {
- $new_filter .= qq( $op ) . $predicate_two . qq(header "$header_two" $match_type_two "$value_two");
- }
- }
-
- if (defined($new_filter)) {
- if ($action eq "move") {
- $new_filter .= qq( move "$destination"\n);
- }
- else {
- $new_filter .= qq(delete\n);
- }
- }
- }
-
- ###########################################################################
-
- push(@new_filters, $new_filter) if (defined($new_filter));
- }
-close(FILTERRC);
-
-###############################################################################
-
-open(MATCHERRC, ">>matcherrc");
- print MATCHERRC @new_filters;
-close(MATCHERRC);
-
-print "Converted $#new_filters filters\n";
-
-if ($old_config_dir eq $config_dir) {
- rename("filterrc", "filterrc.old");
- print "Renamed your old filter rules ('filterrc' to 'filterrc.old')\n";
-}
-###############################################################################
-
diff --git a/tools/filter_conv_new.pl b/tools/filter_conv_new.pl
@@ -1,279 +0,0 @@
-#!/usr/bin/perl -w
-
-use strict;
-use XML::SimpleObject;
-
-# * This file is free software; you can redistribute it and/or modify it
-# * under the terms of the GNU General Public License as published by
-# * the Free Software Foundation; either version 3 of the License, or
-# * (at your option) any later version.
-# *
-# * This program is distributed in the hope that it will be useful, but
-# * WITHOUT ANY WARRANTY; without even the implied warranty of
-# * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# * General Public License for more details.
-# *
-# * You should have received a copy of the GNU General Public License
-# * along with this program; if not, write to the Free Software
-# * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-# *
-# * Copyright 2006 Paul Mangan <paul@claws-mail.org>
-# *
-
-#
-# Convert new style Sylpheed filter rules (Sylpheed >= 0.9.99) to
-# Claws Mail filtering rules
-#
-
-#
-# TABLE OF EQUIVALENTS
-#
-# SYLPHEED : Claws Mail
-#------------------------------------------------------
-#
-# NAME
-#
-# name : rulename
-#
-# CONDITION LIST
-#
-# bool or : |
-# bool and : &
-#
-# match-header (name From) : from
-# match-header (name To) : to
-# match-header (name Cc) : cc
-# match-header (name Subject) : subject
-# else...
-# match-header : header
-#
-# match-header (type contains) : [nothing]
-# match-header (type not-contain) : [append with ~]
-# match-header (type is) : [no equivalent] (use type contains)
-# match-header (type is-not) : [no equivalent] (use type not-contain)
-# match-header (type regex) : regexpcase
-# match-header (type not-regex) : regexpcase [append with ~]
-#
-# matcher-any-header ; headers-part
-# match-to-or-cc : to_or_cc
-# match-body-text : body_part
-# command-test : test
-# size (type gt) : size_greater
-# size (type lt) : size_smaller
-# age (type gt) : age_greater
-# age (type lt) : age_lower
-#
-# ACTION LIST
-#
-# move : move
-# copy : copy
-# not-receive : [no equivalent] (use type delete)
-# delete : delete
-# mark : mark
-# color-label : color
-# mark-as-read : mark_as_read
-# exec : execute
-# stop-eval : stop
-#
-
-my $old_config = "$ENV{HOME}/.sylpheed-2.0/filter.xml";
-my $older_config = "$ENV{HOME}/.sylpheed/filter.xml";
-my $old_filters;
-
-my $config_dir = `claws-mail --config-dir` or die("ERROR:
- You don't appear to have Claws Mail installed\n");
-chomp $config_dir;
-
-chdir($ENV{HOME} . "/$config_dir") or die("ERROR:
- Claws Mail config directory not found [~/$config_dir]
- You need to run Claws Mail once, quit it, and then rerun this script\n");
-
-if (-e $old_config) {
- $old_filters = $old_config;
-} elsif (-e $older_config) {
- $old_filters = $older_config;
-} else {
- print "ERROR:\n\tSylpheed filter not found\n\t[$old_config]\n\t[$older_config]\n";
- exit;
-}
-
-my $claws_version = `claws-mail --version`;
-$claws_version =~ s/^Claws Mail version //;
-
-my ($major, $minor) = split(/\./, $claws_version);
-
-my $version_test = 0;
-if ($major > 2 || ($major == 2 && $minor >= 3)) {
- $version_test = 1;
-}
-
-my $parser = XML::Parser->new(ErrorContext => 2, Style => "Tree");
-my $xmlobj = XML::SimpleObject->new($parser->parsefile($old_filters));
-
-my @conditions = ('match-header','match-to-or-cc','match-any-header',
- 'match-body-text','command-test','size','age');
-
-my @actions = ('copy','not-receive','mark','color-label','mark-as-read',
- 'exec','stop-eval','move','delete');
-
-my $standard_headers = qr/^(?:Subject|From|To|Cc)$/;
-my $negative_matches = qr/^(?:not-contain|is-not|not-regex)$/;
-my $numeric_matches = qr/^(?:size|age)$/;
-my $exact_matches = qr/^(?:move|copy|delete|mark)$/;
-
-my @new_filters = ("[filtering]");
-
-my $disabled = 0;
-my $bool;
-
-## rules list
-foreach my $element ($xmlobj->child("filter")->children("rule")) {
- my $new_filter = "\n";
- if ($element->attribute("enabled")) {
- if ($element->attribute("enabled") eq "false") {
- if ($version_test) {
- $new_filter .= "disabled ";
- } else {
- $disabled++;
- next; # skip disabled rules
- }
- } elsif ($version_test) {
- $new_filter .= "enabled ";
- }
- }
- if ($element->attribute("name")) {
- my $name = $element->attribute("name");
- $name = clean_me($name);
- $new_filter .= "rulename \"$name\" ";
- }
-## condition list
- foreach my $parent ($element->children("condition-list")) {
- if ($parent->attribute("bool")) {
- $bool = $parent->attribute("bool");
- $bool =~ s/or/|/;
- $bool =~ s/and/&/;
- }
- foreach my $condition (@conditions) {
- my $new_condition = 0;
- my $type;
- if ($parent->children("$condition")) {
- foreach my $sibling ($parent->children("$condition")) {
- if ($new_condition) {
- $new_filter .= " $bool ";
- }
- if ($sibling->attribute("type")) {
- $type = $sibling->attribute("type");
- if ($type =~ m/$negative_matches/) {
- $new_filter .= '~';
- }
- }
- if ($sibling->attribute("name")) {
- my $name = $sibling->attribute("name");
- if ($condition eq "match-header") {
- if ($name =~ m/$standard_headers/) {
- $new_filter .= lc($name) . " ";
- } else {
- $new_filter .= "header \"$name\" ";
- }
- }
- }
- if ($condition eq "match-any-header") {
- $new_filter .= "headers_part ";
- } elsif ($condition eq "match-header-content") {
- $new_filter .= "headers_cont ";
- } elsif ($condition eq "match-to-or-cc") {
- $new_filter .= "to_or_cc ";
- } elsif ($condition eq "match-body-text") {
- $new_filter .= "body_part ";
- } elsif ($condition eq "command-test") {
- $new_filter .= "test ";
- } elsif ($condition eq "size") {
- if ($type eq "gt") {
- $new_filter .= "size_greater ";
- } else {
- $new_filter .= "size_smaller ";
- }
- } elsif ($condition eq "age") {
- if ($type eq "gt") {
- $new_filter .= "age_greater ";
- } else {
- $new_filter .= "age_lower ";
- }
- }
- if ($condition !~ m/$numeric_matches/ &&
- $condition ne "command-test") {
- if ($type =~ m/regex/) {
- $new_filter .= "regexpcase ";
- } else {
- $new_filter .= "matchcase ";
- }
- }
- my $value = clean_me($sibling->value);
- if ($condition =~ m/$numeric_matches/) {
- $new_filter .= "$value";
- } else {
- $new_filter .= "\"$value\"";
- }
- $new_condition++;
- }
- }
- }
- }
-## end of condition list
-## action list
- foreach my $parent ($element->children("action-list")) {
- foreach my $action (@actions) {
- if ($parent->children("$action")) {
- foreach my $sibling ($parent->children("$action")) {
- if ($action =~ m/$exact_matches/) {
- $new_filter .= " $action";
- } elsif ($action eq "not-receive") {
- $new_filter .= " delete";
- } elsif ($action eq "color-label") {
- $new_filter .= " color";
- } elsif ($action eq "mark-as-read") {
- $new_filter .= " mark_as_read";
- } elsif ($action eq "exec") {
- $new_filter .= " execute";
- } elsif ($action eq "stop-eval") {
- $new_filter .= " stop";
- }
- if ($sibling->value) {
- my $value = clean_me($sibling->value);
- if ($action eq "color-label") {
- $new_filter .= " $value";
- } else {
- $new_filter .= " \"$value\"";
- }
- }
- }
- }
- }
- }
-## end of action list
- push(@new_filters, $new_filter) if (defined($new_filter));
-}
-## end of rules list
-push(@new_filters, "\n");
-
-# write new config
-open(MATCHERRC, ">>matcherrc");
- print MATCHERRC @new_filters;
-close(MATCHERRC);
-
-print "Converted ". ($#new_filters-1) . " filters\n";
-if ($disabled) {
- print "[$disabled disabled filter(s) not converted]\n";
-}
-
-exit;
-
-sub clean_me {
- my ($dirty) = @_;
-
- $dirty =~ s/\"/\\\"/g;
- $dirty =~ s/\n/ /g;
-
- return $dirty;
-}
-
diff --git a/tools/fix_date.sh b/tools/fix_date.sh
@@ -1,275 +0,0 @@
-#!/bin/sh
-
-# * Copyright 2004 Tristan Chabredier <wwp@claws-mail.org>
-# *
-# * This file is free software; you can redistribute it and/or modify it
-# * under the terms of the GNU General Public License as published by
-# * the Free Software Foundation; either version 3 of the License, or
-# * (at your option) any later version.
-# *
-# * This program is distributed in the hope that it will be useful, but
-# * WITHOUT ANY WARRANTY; without even the implied warranty of
-# * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# * General Public License for more details.
-# *
-# * You should have received a copy of the GNU General Public License
-# * along with this program; if not, write to the Free Software
-# * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-#
-# fix_date.sh helper script to fix non-standard date or add missing
-# date header to emails
-
-# usage: fix_date.sh <filename> [<filename> ..]
-# It will replace the Date: value w/ the one picked up from more recent
-# Fetchinfo time header, Received: field.. Otherwise, it will take the file
-# modification time (using a RFC 2822-compliant form).
-# Any already existing X-Original-Date is kept, if missing we're adding it
-# if the Date: was set (even if set w/ non conform value)
-
-# TODO: fallback to X-OriginalArrivalTime: ?
-
-VERSION="0.1.4"
-
-
-version()
-{
- echo "$VERSION"
- exit 0
-}
-
-usage()
-{
- echo "usage:"
- echo " ${0##*/} [<switches>] <filename> [<filename> ..]"
- echo "switches:"
- echo " -h --help display this help then exit"
- echo " -v --version display version information then exit"
- echo " -d --debug turn on debug information (be more verbose)"
- echo " -f --force always force (re-)writing of Date: header"
- echo " -r --rfc force re-writing of Date: header when it's not RFC-compliant"
- echo " -s --strict use RFC-strict matching patterns for dates"
- echo " -- end of switches (in case a filename starts with a -)"
- echo "this script requires coreutils (cat, cut, head, tr), dos2unix, grep and set"
- echo "in PATH to work"
- exit $1
-}
-
-date_valid()
-{
- test $STRICT -eq 1 && \
- REGEXP="$DATE_REGEXP_STRICT" || \
- REGEXP="$DATE_REGEXP"
-
- echo "$1" | grep -qEim 1 "$REGEXP"
- DATE_VALID=$?
-}
-
-dump_date_fields()
-{
- test -z "$X_ORIGINAL_DATE" -a -n "$DATE" && \
- echo "X-Original-Date:$DATE" >> "$TMP"
- echo "Date:$REPLACEMENT_DATE" >> "$TMP"
-}
-
-
-# use --force to always (re-)write the Date header
-# otherwise, the Date header will be written if only it doesn't exist
-FORCE=0
-# use --rfc to (re-)write the Date header when it's not RFC-compliant
-# otherwise, the Date header will be written if only it doesn't exist
-RFC=0
-# use --debug to display more information about what's performed
-DEBUG=0
-# use --strict to use strict matching patterns for date validation
-STRICT=0
-# 0 = valid, always valid until --strict is used, then date_valid overrides this value
-DATE_VALID=0
-# max header lines (300 is a reasonable minimum value but 600 has already been encountered, set to 1000 by security)
-MAX_HEADER_LINES=1000
-
-while [ -n "$1" ]
-do
- case "$1" in
- -h|--help) usage 0;;
- -v|--version) version;;
- -f|--force) FORCE=1;;
- -d|--debug) DEBUG=1;;
- -r|--rfc) RFC=1;;
- -s|--strict) STRICT=1;;
- --) shift
- break;;
- -*) echo "error: unrecognized switch '$1'"
- usage 1;;
- *) break;;
- esac
- shift
-done
-
-if [ $FORCE -eq 1 -a $RFC -eq 1 ]
-then
- echo "error: use either --force or --rfc, but not both at the same time"
- usage 1
-fi
-
-test $# -lt 1 && \
- usage 1
-
-for PROG in dos2unix grep sed
-do
- type "$PROG" >/dev/null 2>&1 || \
- { echo "error: $PROG not found in PATH"; exit 1; }
-done
-
-TMPDIR="/tmp"
-TMP="$TMPDIR/${0##*/}.$$.tmp"
-echo > "$TMP" >/dev/null 2>&1
-if [ $? -eq 0 ]
-then
- rm -f "$TMP" >/dev/null 2>&1
-else
- TMPDIR="$HOME"
- TMP="$TMPDIR/${0##*/}.$$.tmp"
-fi
-HEADERS="$TMPDIR/${0##*/}.$$.headers.tmp"
-BODY="$TMPDIR/${0##*/}.$$.body.tmp"
-
-DATE_REGEXP='( (Mon|Tue|Wed|Thu|Fri|Sat|Sun),)? [0-9]+ (Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec) [0-9]+ [0-9]+:[0-9]+:[0-9]+ [+-]?[0-9]+'
-DATE_REGEXP_STRICT='(Mon|Tue|Wed|Thu|Fri|Sat|Sun), [0-9]+ (Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec) [0-9]+ [0-9]+:[0-9]+:[0-9]+ [+-]?[0-9]+'
-
-while [ -n "$1" ]
-do
- # skip if file is empty or doesn't exist
- if [ ! -s "$1" ]
- then
- test $DEBUG -eq 1 && \
- echo "$1: no found or empty, skipping"
- shift
- continue
- fi
- SKIP=0
-
- # split headers and body
- # find the empty line that separates body (if any) from headers,
- # work on a temporary dos2unix'ed copy because body might
- # contain DOS CRLF and grep '^$' won't work
- head -$MAX_HEADER_LINES "$1" | dos2unix > "$TMP"
- SEP=`grep -nEm1 "^$" "$TMP" 2>/dev/null | cut -d ':' -f 1`
- rm -f "$TMP"
- if [ -z "$SEP" -o "$SEP" = "0" -o $? -ne 0 ]
- then
- cp -f "$1" "$HEADERS"
- :> "$BODY"
- test $DEBUG -eq 1 && \
- echo "$1: no body part could be found before line $MAX_HEADER_LINES"
- else
- sed -n '1,'`expr $SEP - 1`'p' "$1" > "$HEADERS"
- sed '1,'`expr $SEP - 1`'d' "$1" > "$BODY"
- fi
-
- # work on headers only
-
- # get the Date and X-Original-Date
- X_ORIGINAL_DATE=`sed -n '/^X-Original-Date:/,/^[^\t]/p' "$HEADERS" | head -n -1 | cut -d ':' -f 2-`
- DATE=`sed -n '/^Date:/,/^[^\t]/p' "$HEADERS" | head -n -1 | cut -d ':' -f 2-`
-
- # work on headers, minus Date and X-Original-Date
- test -n "$X_ORIGINAL_DATE" && \
- sed -i '/^X-Original-Date:/,/^[^\t]/d' "$HEADERS"
- test -n "$DATE" && \
- sed -i '/^Date:/,/^[^\t]/d' "$HEADERS"
-
- # find a replacement date in Fetchinfo: header
- FETCH_DATE=`grep -im1 'X-FETCH-TIME: ' "$HEADERS" | cut -d ' ' -f 2-`
-
- # or in Received: headers ..
- test $STRICT -eq 1 && \
- REGEXP="$DATE_REGEXP" || \
- REGEXP="$DATE_REGEXP_STRICT"
- RECEIVED_DATE=`sed -n '/^Received:/,/^[^\t]/p' "$HEADERS" | head -n -1 | grep -Eoim 1 "$REGEXP"`
-
- # .. or from file properties
- FILE_DATE=`LC_ALL=POSIX LANG=POSIX ls -l --time-style="+%a, %d %b %Y %X %z" "$1" | tr -s ' ' | cut -d ' ' -f 6-11`
- # we could also use the system date as a possible replacement
- SYSTEM_DATE="`date -R`"
-
- # determine which replacement date to use
- if [ -z "$FETCH_DATE" ]
- then
- if [ -z "$RECEIVED_DATE" ]
- then
- # don't forget the leading whitespace here
- REPLACEMENT_DATE=" $FILE_DATE"
- REPLACEMENT="file date"
-# REPLACEMENT_DATE=" $SYSTEM_DATE"
-# REPLACEMENT="system date"
- else
- REPLACEMENT_DATE="$RECEIVED_DATE"
- REPLACEMENT="received date"
- fi
- else
- # don't forget the leading whitespace here
- REPLACEMENT_DATE=" $FETCH_DATE"
- REPLACEMENT="Fetchinfo time header"
- fi
-
- # ensure that the original X-Original-Date is kept
- :> "$TMP"
- if [ -n "$X_ORIGINAL_DATE" ]
- then
- echo "X-Original-Date:$X_ORIGINAL_DATE" >> "$TMP"
- fi
-
- # replace/set the date and write all lines
- test $RFC -eq 1 && \
- date_valid "$DATE"
- if [ -z "$DATE" ]
- then
- test $DEBUG -eq 1 && \
- echo "$1: date not found, using $REPLACEMENT now"
- dump_date_fields
- else
- if [ $FORCE -eq 1 ]
- then
- test $DEBUG -eq 1 && \
- echo "$1: date already found, replacing with $REPLACEMENT"
- dump_date_fields
- else
- if [ $RFC -eq 1 ]
- then
- if [ $DATE_VALID -ne 0 ]
- then
- test $DEBUG -eq 1 && \
- echo "$1: date already found but not RFC-compliant, replacing with $REPLACEMENT"
- dump_date_fields
- else
- test $DEBUG -eq 1 && \
- echo "$1: date already found and RFC-compliant, skipping"
- SKIP=1
- fi
- else
- test $DEBUG -eq 1 && \
- echo "$1: date already found, skipping"
- SKIP=1
- fi
- fi
- fi
-
- if [ $SKIP -eq 0 ]
- then
- # uncomment the following line to backup the original file
- #mv -f "$1" "$1.bak"
-
- cat "$HEADERS" >> "$TMP"
- cat "$BODY" >> "$TMP"
- mv -f "$TMP" "$1"
- if [ $? -ne 0 ]
- then
- echo "error while moving '$TMP' to '$1'"
- exit 1
- fi
- fi
- rm -f "$HEADERS" "$BODY" "$TMP" >/dev/null 2>&1
-
- shift
-done
-exit 0
diff --git a/tools/gif2xface.pl b/tools/gif2xface.pl
@@ -1,98 +0,0 @@
-#!/usr/bin/perl
-#
-# gif2xface -- converts a 48x48 GIF file to an X-Face mail header
-#
-# Author: Ricardo Mones <ricardo@mones.org>
-#
-# This is a hack over the original xbm2face script. The xbm files generated
-# by some graphic tools (notably The Gimp version 1.2.1) aren't suitable to
-# feed the compface program. Starting with a GIF and using some filters does
-# the trick. A little help screen also added.
-# This requieres giftopnm and pbmtoxbm (both in libgr-progs package).
-#
-# The original xbm2face author's comment follows:
-#
-# xbm2xface -- converts a 48x48 xbm file to an X-Face mail header
-#
-# Author: Jonathan Stigelman <Stig@hackvan.com>
-#
-# URL: http://hackvan.com/pub/stig/src/linux/
-# FTP: hackvan.com:/pub/stig/src/linux/
-#
-# This is a Perl script that I wrote to convert 48x48 xbm (X bitmap) files
-# into X-Face: headers suitable for inclusion in RFC822 internet
-# electronic mail. A 48x48 bitmap is awfully small, but X-Faces are still
-# good enough for other people to visually establish your identity in
-# email without having to carefully read your name.
-#
-# Basically, it gets you noticed...either as the person with the cool
-# X-Face or as that jerk with modem noise in all of his email messages.
-#
-# People will start looking over your shoulder and say "Hey Cool! How'd
-# you do that?" When they do, you just send 'em to my URL for this
-# utility and tell 'em to upgrade to a real mail reader: XEmacs and VM.
-#
-# It also requires the 'compface' utility.
-#
-
-sub check_for_help {
- local($param) = @_;
-
- # is a filter, no args must be present
- if (defined($param))
- {
- print "\n", 'gif2xface -- A filter for converting an 48x48 gif into a xface string', "\n\n" ;
- print 'Usage: gif2xface < input.gif > output.xface', "\n\n";
- exit;
- }
-}
-
-sub reverse_byte {
- local($byte) = @_;
- local($n, $b);
- for ( $b= $n= 0; $b<8; ++$b) {
- $n |= (($byte & 1) << (7-$b));
- $byte >>= 1;
- }
- return($n);
-}
-
-
-&check_for_help($ARGV[0]);
-
-# printf "0x%02x\n", &reverse_byte(0xF0);
-
-$ra = rand;
-$tf = "/tmp/gif2xface.$ra";
-open(GP,"|giftopnm|pbmtoxbm>$tf");
-
-while (<>) {
- print GP $_;
-}
-close(GP);
-open(GP,"<$tf");
-<GP>;
-m/^#define \w+_width (\d+)/ && ($width=$1);
-<GP>;
-m/^#define \w+_height (\d+)/ && ($height=$1);
-<GP>;
-m/^static.* = \{/ && (( $width == 48 && $height == 48 )
- || die $0, ": sorry, xfaces must be 48x48 pixels" );
-
-$| = 1; print "X-Face:";
-
-open(CF,"|compface");
-
-while (<GP>) {
- $st="";
- while (s/(0x..)(,|\};)\s*//) {
- $st .= sprintf("0x%02x, ", &reverse_byte(eval($1)));
- }
- $_=$st;
- s/(0x..), 0x(..)/\1\2/g;
- s/\s*(0x...., 0x...., 0x....)(,|\};)\s/\1,\n/g;
- print CF $_;
-}
-close (CF);
-close (GP);
-unlink $tf;
diff --git a/tools/gitlog2changelog.py b/tools/gitlog2changelog.py
@@ -1,145 +0,0 @@
-#!/usr/bin/env python3
-# Copyright 2008 Marcus D. Hanwell <marcus@cryos.org>
-# Adapted for Claws Mail - Copyright 2013 Colin Leroy <colin@colino.net>
-# Distributed under the terms of the GNU General Public License v2 or later
-
-import string, re, os, sys
-
-curRev = ""
-prevVer = ""
-
-if len(sys.argv) == 3:
- curRev = sys.argv[2]
- prevVer = sys.argv[1]
-else:
- curRevCmd = os.popen("git describe")
- curRev = curRevCmd.read()
- curRev = curRev[0:len(curRev)-1]
- curRevCmd.close()
- if len(sys.argv) == 2:
- prevVer = sys.argv[1]
- else:
- prevVer = re.split('-', curRev, 1)[0]
-
-# Execute git log with the desired command line options.
-fin = os.popen('git log ' + prevVer + '..' + curRev +' --summary --stat --no-merges --date=short', 'r')
-# Create a ChangeLog file in the current directory.
-fout = sys.stdout
-
-# Set up the loop variables in order to locate the blocks we want
-authorFound = False
-dateFound = False
-messageFound = False
-filesFound = False
-message = ""
-commit = ""
-messageNL = False
-files = ""
-prevAuthorLine = ""
-
-# The main part of the loop
-for line in fin:
- # The commit line marks the start of a new commit object.
- if re.match('^commit', line):
- # Start all over again...
- authorFound = False
- dateFound = False
- messageFound = False
- messageNL = False
- message = ""
- filesFound = False
- files = ""
- commitCmd = os.popen("git describe "+re.split(' ', line, 1)[1])
- commit = commitCmd.read()
- commitCmd.close()
- commit = commit[0:len(commit)-1]
- continue
- # Match the author line and extract the part we want
- elif re.match('^Author:', line):
- authorList = re.split(': ', line, 1)
- author = re.split('<', authorList[1], 1)[0]
- author = "[" + author[0:len(author)-1]+"]"
- authorFound = True
- continue
- # Match the date line
- elif re.match('^Date:', line):
- dateList = re.split(': ', line, 1)
- date = dateList[1]
- date = date[0:len(date)-1]
- dateFound = True
- continue
- # The svn-id lines are ignored
- elif re.match(' git-svn-id:', line):
- continue
- # The sign off line is ignored too
- elif re.search('Signed-off-by', line) != None:
- continue
- # Extract the actual commit message for this commit
- elif authorFound & dateFound & messageFound == False:
- # Find the commit message if we can
- if len(line) == 1:
- if messageNL:
- messageFound = True
- else:
- messageNL = True
- elif len(line) == 4:
- messageFound = True
- else:
- if len(message) == 0:
- message = message + line.strip()
- else:
- message = message + " " + line.strip()
- # If this line is hit all of the files have been stored for this commit
- elif re.search('file(s)? changed', line) != None:
- filesFound = True
- continue
- # Collect the files for this commit. FIXME: Still need to add +/- to files
- elif authorFound & dateFound & messageFound:
- fileList = re.split(' \| ', line, 2)
- if len(fileList) > 1:
- if len(files) > 0:
- files = files + "\n\t* " + fileList[0].strip()
- else:
- files = "\t* " + fileList[0].strip()
- # All of the parts of the commit have been found - write out the entry
- if authorFound & dateFound & messageFound & filesFound:
- # First the author line, only outputted if it is the first for that
- # author on this day
- authorLine = date + " " + author
- if len(prevAuthorLine) != 0:
- fout.write("\n");
- fout.write(authorLine + " " + commit + "\n\n")
-
- # Assemble the actual commit message line(s) and limit the line length
- # to 80 characters.
- commitLine = message
- i = 0
- commit = ""
- while i < len(commitLine):
- if len(commitLine) < i + 70:
- commit = commit + "\n\t\t" + commitLine[i:len(commitLine)]
- break
- index = commitLine.rfind(' ', i, i+70)
- if index > i:
- commit = commit + "\n\t\t" + commitLine[i:index]
- i = index+1
- else:
- commit = commit + "\n\t\t" + commitLine[i:70]
- i = i+71
-
- # Write out the commit line
- fout.write(files + "\t\t" + commit + "\n")
-
- #Now reset all the variables ready for a new commit block.
- authorFound = False
- dateFound = False
- messageFound = False
- messageNL = False
- message = ""
- filesFound = False
- files = ""
- prevAuthorLine = authorLine
-
-# Close the input and output lines now that we are finished.
-fin.close()
-fout.close()
diff --git a/tools/google_msgid.pl b/tools/google_msgid.pl
@@ -1,7 +0,0 @@
-#!/usr/bin/perl
-my $browser = 'mozilla';
-my $google_id = 'http://groups.google.com/groups?as_umsgid';
-$_ = <>;
-chomp;
-s/<|>//eg;
-system("$browser '$google_id=$_' &");
diff --git a/tools/jhbuild/README b/tools/jhbuild/README
@@ -1,17 +0,0 @@
-Building Claws Mail with JHBuild
---------------------------------
-
-Claws Mail can be built with JHBuild. This way, it's easy to do
-sandboxed builds, for example in order to try out different versions
-of low-level dependencies like gtk+ or glib without messing up a production
-system. It's also useful to build older dependencies that are otherwise hard
-to get on a more recent distribution.
-
-In order to use JHBuild for building Claws Mail, first, JHBuild itself
-must be built and installed, see
-https://developer.gnome.org/jhbuild/stable/getting-started.html
-
-JHBuild needs a configuration file, either as ~/.jhbuildrc or given with the
-parameter -f on the command line. You can use the file
-sample.jhbuildrc-claws-mail as a starting point, but you'll have to modify
-it to suit your local environment.
diff --git a/tools/jhbuild/claws-mail.modules b/tools/jhbuild/claws-mail.modules
@@ -1,74 +0,0 @@
-<?xml version="1.0"?>
-<!DOCTYPE moduleset SYSTEM "moduleset.dtd">
-<?xml-stylesheet type="text/xsl" href="moduleset.xsl"?>
-<moduleset>
-
- <repository type="git" name="git.claws-mail.org" href="git://git.claws-mail.org/" default="yes"/>
- <repository type="git" name="git.gnome.org" href="git://git.gnome.org/"/>
- <repository type="git" name="github.com" href="git://github.com/"/>
-
- <autotools id="claws-mail">
- <branch module="claws"/>
- <dependencies>
- <dep package="gtk+"/>
- </dependencies>
- <suggests>
- <dep package="libchamplain"/>
- <dep package="libgdata"/>
- </suggests>
- </autotools>
-
- <!-- Dependencies -->
-
- <autotools id="libetpan">
- <branch repo="github.com" module="dinhviethoa/libetpan" checkoutdir="libetpan"/>
- </autotools>
-
- <autotools id="gtk+">
- <branch repo="git.gnome.org" revision="gtk-2-24"/>
- <dependencies>
- <dep package="glib"/>
- </dependencies>
- </autotools>
-
- <autotools id="glib">
- <branch repo="git.gnome.org"/>
- </autotools>
-
- <autotools id="libgdata">
- <pkg-config>libgdata.pc</pkg-config>
- <branch repo="git.gnome.org"/>
- <dependencies>
- <dep package="glib"/>
- <dep package="liboauth"/>
- <dep package="m4-common"/>
- </dependencies>
- </autotools>
-
- <tarball id="liboauth" version="0.9.4">
- <pkg-config>oauth.pc</pkg-config>
- <source href="http://downloads.sourceforge.net/liboauth/liboauth-0.9.4.tar.gz" hash="sha256:77e372359caca5375fbcc63ac638f349e6c93c98d291992d8ebb9bb8291ca549"
- md5sum="973ded7a1af348c5bfe4e3b6b7e47bd3"
- size="459597"/>
- </tarball>
-
- <autotools id="m4-common">
- <branch repo="github.com" module="desrt/m4-common.git"/>
- </autotools>
-
- <tarball id="libchamplain" version="0.8.3" makeargs="LDFLAGS='-lgthread-2.0'">
- <source href="ftp://ftp.gnome.org/pub/GNOME/sources/libchamplain/0.8/libchamplain-0.8.3.tar.gz"
- hash="sha256:e4d7e89195ac91e1e348187be1718dbb7569d1d40fde007cd276256f92e53710"
- size="863691"/>
- <dependencies>
- <dep package="clutter-gtk"/>
- </dependencies>
- </tarball>
-
- <tarball id="clutter-gtk" version="0.10.8" makeargs="LDFLAGS='-lm -lgthread-2.0'">
- <source href="ftp://ftp.gnome.org/pub/GNOME/sources/clutter-gtk/0.10/clutter-gtk-0.10.8.tar.gz"
- hash="sha256:8ef57c1a0c6227704e89350805d10caaa9cc3f1bea6263211b05acd473fdfdc4"
- size="391461"/>
- </tarball>
-
-</moduleset>
diff --git a/tools/jhbuild/sample.jhbuildrc-claws-mail b/tools/jhbuild/sample.jhbuildrc-claws-mail
@@ -1,46 +0,0 @@
-# -*- mode: python -*-
-#
-# Sample jhbuildrc configuration file for building Claws Mail and
-# some of its dependencies.
-
-# Select module set to use
-moduleset = os.path.expanduser('~/src/claws-mail/claws/tools/jhbuild/claws-mail.modules')
-
-# repo login in case of write access
-#repos["git.claws-mail.org"] = 'ssh://git.claws-mail.org/home/git/'
-
-# default modules
-modules = ['claws-mail']
-
-# what directory should the source be checked out to?
-checkoutroot = os.path.expanduser('~/src/claws-mail')
-
-# the prefix to configure/install modules to (must have write access)
-prefix = '/opt/claws-mail'
-
-# make arguments (e.g. concurrent build)
-#makeargs = '-j4'
-
-# environment vars (e.g. CFLAGS)
-#os.environ['CFLAGS'] = '-g -O0'
-
-# module-specific autofoo args
-#module_autogenargs['claws-mail'] = " ".join([autogenargs, "--disable-manual"])
-#module_autogenargs['libgdata'] = " ".join([autogenargs, "--disable-always-build-tests"])
-
-# path for building (if None, build in-tree)
-#buildroot = None
-
-# skip building of dependant modules (system-installed ones will be used)
-skip = [
- "glib"
- , "gtk+"
- , "libgdata"
- , "libchamplain"
- ]
-
-# speficif branches/tags of modules that should be built
-#branches['libgdata'] = (None, 'LIBGDATA_0_17_1')
-
-# module specific extra environment variables
-#module_extra_env = { "clutter-gtk" : {"LDFLAGS" : "-lm -lgthread-2.0"} }
diff --git a/tools/kdeservicemenu/README b/tools/kdeservicemenu/README
@@ -1,62 +0,0 @@
-claws-mail-kdeservicemenu.pl
-Version: 1.6
-Claws Mail servicemenu for Konqueror
-
-FILES
-o README You're reading it
-o install.sh installer script
-o claws-mail-kdeservicemenu.pl perl program
-o claws-attach-files.desktop.template
- .desktop file template
-
-DESCRIPTION
-Enables attaching files from Konqueror to a new compose window.
-
-Adds the following right-click menu item to Konqueror:
-/Claws Mail/Attach File(s)
-
-REQUIREMENTS
-Perl 5.x.x
-
-INSTALL
-o cd claws-mail/tools/kdeservicemenu
-o ./install.sh (for kdialog prompt)
- -or-
-o ./install.sh --global
- ./install.sh --local
- (systemwide or home directory installation)
-
-UNINSTALL
-o cd claws-mail/tools/kdeservicemenu
-o ./install.sh (for kdialog prompt)
- -or-
-o ./install.sh --uninstall-global
- ./install.sh --uninstall-local
- (systemwide or home directory uninstallation)
-
-
-LICENSE
-GNU GENERAL PUBLIC LICENSE
-
-THANKS
-install.sh was originally based on the install.sh script written by Dylan
-Schrader <dschrader@conception.edu>, and released under the GPL, as part
-of his 'Attach to email' service Menu for Konqueror, version 0.6.13
-<http://themes.kde.org/content/show.php?content=11234>, it has since been
-heavily adapted.
-
-Translators:
-[de] Thomas Gilgin <thg@karate-muellheim.de>
-[es] Ricardo Mones Lastra <mones@aic.uniovi.es>
-[fr] Fabien Vantard <fzz@ifrance.com>
-[it] Andrea Spadaccini <lupin85@email.it>
-[pt_BR] Frederico Goncalves Guimaraes <fggdebian@yahoo.com.br>
-[sk] Andrej Kacian <andrej@kacian.sk>
-
-LINKS
-Claws Mail <http://www.claws-mail.org/>
-Perl <http://www.perl.org>
-KDE <http://www.kde.org>
-
-CONTACT
-Paul Mangan <paul@claws-mail.org>
diff --git a/tools/kdeservicemenu/claws-mail-attach-files.desktop.kde4template b/tools/kdeservicemenu/claws-mail-attach-files.desktop.kde4template
@@ -1,14 +0,0 @@
-[Desktop Entry]
-Type=Service
-Actions=AttachFiles;
-Comment=kde service menu for attaching files to Claws Mail
-Encoding=UTF8
-Name=Claws Mail attach files
-ServiceTypes=KonqPopupMenu/Plugin,all/allfiles
-X-KDE-Priority=TopLevel
-X-KDE-Submenu=Claws Mail
-
-[Desktop Action AttachFiles]
-Exec=SCRIPT_PATH %F
-Icon=claws-mail
-Name=Attach File(s)
diff --git a/tools/kdeservicemenu/claws-mail-attach-files.desktop.template b/tools/kdeservicemenu/claws-mail-attach-files.desktop.template
@@ -1,13 +0,0 @@
-[Desktop Entry]
-Actions=AttachFiles;
-Comment=kde service menu for attaching files to Claws Mail
-Encoding=UTF8
-Name=Claws Mail attach files
-ServiceTypes=all/allfiles
-X-KDE-Priority=TopLevel
-X-KDE-Submenu=Claws Mail
-
-[Desktop Action AttachFiles]
-Exec=SCRIPT_PATH %F
-Icon=claws-mail
-Name=Attach File(s)
diff --git a/tools/kdeservicemenu/claws-mail-kdeservicemenu.pl b/tools/kdeservicemenu/claws-mail-kdeservicemenu.pl
@@ -1,38 +0,0 @@
-#!/usr/bin/perl
-
-# * Copyright 2004-2006 Paul Mangan <paul@claws-mail.org>
-# *
-# * This file is free software; you can redistribute it and/or modify it
-# * under the terms of the GNU General Public License as published by
-# * the Free Software Foundation; either version 3 of the License, or
-# * (at your option) any later version.
-# *
-# * This program is distributed in the hope that it will be useful, but
-# * WITHOUT ANY WARRANTY; without even the implied warranty of
-# * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# * General Public License for more details.
-# *
-# * You should have received a copy of the GNU General Public License
-# * along with this program; if not, write to the Free Software
-# * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-
-unless ($ARGV[0]) { exit; }
-
-my $claws = "claws-mail --compose --attach";
-my $sel = split_parts();
-
-exec "$claws $sel";
-
-exit;
-
-sub split_parts {
- my $selectedParts = "";
- my $count = 0;
-
- while ($ARGV[$count]) {
- $selectedParts .= "\"$ARGV[$count]\" ";
- $count++;
- }
-
- return ($selectedParts);
-}
diff --git a/tools/kdeservicemenu/install.sh b/tools/kdeservicemenu/install.sh
@@ -1,138 +0,0 @@
-#!/usr/bin/env bash
-
-PERL_SCRIPT="claws-mail-kdeservicemenu.pl"
-DESKTOP="claws-mail-attach-files.desktop"
-
-function check_environ {
-echo "Checking for kde4-config..."
-if [ ! -z "$(type 'kde4-config' 2> /dev/null)" ]; then
- echo "Found kde4-config..."
- SERVICEMENU_DIR="share/kde4/services/ServiceMenus"
- DESKTOP_TEMPLATE="claws-mail-attach-files.desktop.kde4template"
- KDECONFIG="kde4-config"
-else
- echo "kde4-config not found..."
- echo "Checking for kde-config..."
- if [ ! -z "$(type 'kde-config' 2> /dev/null)" ]; then
- echo "Found kde-config..."
- SERVICEMENU_DIR="share/apps/konqueror/servicemenus"
- DESKTOP_TEMPLATE="claws-mail-attach-files.desktop.template"
- KDECONFIG="kde-config"
- else
- echo "kde-config not found..."
- echo "asking user to find kde4-config or kde-config..."
- KDECONFIG=$(kdialog --title "Locate kde-config or kde4-config" --getopenfilename / )
- test -z $KDECONFIG && exit 1
- if [[ $KDECONFIG == *4-config ]]; then
- SERVICEMENU_DIR="share/kde4/services/ServiceMenus"
- DESKTOP_TEMPLATE="claws-mail-attach-files.desktop.kde4template"
- else
- SERVICEMENU_DIR="share/apps/konqueror/servicemenus"
- DESKTOP_TEMPLATE="claws-mail-attach-files.desktop.template"
- fi
- fi
-fi
-}
-
-function install_all {
-echo "Generating $DESKTOP ..."
-SED_PREFIX=${PREFIX//\//\\\/}
-sed "s/SCRIPT_PATH/$SED_PREFIX\\/bin\\/$PERL_SCRIPT/" $DESKTOP_TEMPLATE > $DESKTOP
-echo "Installing $PREFIX/$SERVICEMENU_DIR/$DESKTOP"
-mv -f $DESKTOP $PREFIX/$SERVICEMENU_DIR/$DESKTOP
-if [[ $? -ne 0 ]]
-then
- kdialog --error "Could not complete installation."
- exit
-fi
-echo "Installing $PREFIX/bin/$PERL_SCRIPT"
-cp -f $PERL_SCRIPT $PREFIX/bin/
-echo "Setting permissions ..."
-chmod 0644 $PREFIX/$SERVICEMENU_DIR/$DESKTOP
-chmod 0755 $PREFIX/bin/$PERL_SCRIPT
-echo "Finished installation."
-kdialog --msgbox "Finished installation."
-}
-
-function uninstall_all {
-echo "Removing $PREFIX/$SERVICEMENU_DIR/$DESKTOP"
-rm $PREFIX/$SERVICEMENU_DIR/$DESKTOP
-if [[ $? -ne 0 ]]
-then
- kdialog --error "Could not complete uninstall."
- exit
-fi
-echo "Removing $PREFIX/bin/$PERL_SCRIPT"
-rm $PREFIX/bin/$PERL_SCRIPT
-echo "Finished uninstall."
-kdialog --msgbox "Finished uninstall."
-}
-
-function show_help {
- echo "Usage: $0 [--global|--local|--uninstall-global|--uninstall-local]"
- echo
- echo " --global attempts a system-wide installation."
- echo " --local attempts to install in your home directory."
- echo " --uninstall-global attempts a system-wide uninstallation."
- echo " --uninstall-local attempts to uninstall in your home directory."
- echo
- exit 0
-}
-
-if [ -z $1 ]
- then option="--$(kdialog --menu "Please select installation type" \
- local "install for you only" \
- global "install for all users" \
- uninstall-local "uninstall for you only" \
- uninstall-global "uninstall for all users" 2> /dev/null)"
- else option=$1
-fi
-
-case $option in
- "--global" )
- check_environ
- PREFIX=$($KDECONFIG --prefix)
- echo "Installing in $PREFIX/$SERVICEMENU_DIR ..."
- if [ "$(id -u)" != "0" ]; then
- exec kdesu "$0 --global"
- fi
- install_all
- ;;
- "--local" )
- check_environ
- PREFIX=$($KDECONFIG --localprefix)
- echo "Installing in $PREFIX$SERVICEMENU_DIR ..."
- if [ ! -d $PREFIX/bin ]; then
- mkdir $PREFIX/bin
- fi
- if [ ! -d $PREFIX/$SERVICEMENU_DIR ]; then
- mkdir $PREFIX/$SERVICEMENU_DIR
- fi
- install_all
- ;;
- "--uninstall-global" )
- check_environ
- PREFIX=$($KDECONFIG --prefix)
- echo "Uninstalling from $PREFIX/$SERVICEMENU_DIR ..."
- if [ "$(id -u)" != "0" ]; then
- exec kdesu "$0 --uninstall-global"
- fi
- uninstall_all
- ;;
- "--uninstall-local" )
- check_environ
- PREFIX=$($KDECONFIG --localprefix)
- echo "Uninstalling from $PREFIX$SERVICEMENU_DIR ..."
- uninstall_all
- ;;
- "-h" )
- show_help
- ;;
- "--help" )
- show_help
- ;;
- * )
- show_help
-esac
-
-echo "Done."
diff --git a/tools/kmail-mailbox2claws-mail.pl b/tools/kmail-mailbox2claws-mail.pl
@@ -1,155 +0,0 @@
-#!/usr/bin/perl -w
-
-# * This file is free software; you can redistribute it and/or modify it
-# * under the terms of the GNU General Public License as published by
-# * the Free Software Foundation; either version 3 of the License, or
-# * (at your option) any later version.
-# *
-# * This program is distributed in the hope that it will be useful, but
-# * WITHOUT ANY WARRANTY; without even the implied warranty of
-# * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# * General Public License for more details.
-# *
-# * You should have received a copy of the GNU General Public License
-# * along with this program; if not, write to the Free Software
-# * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-# *
-# * Copyright 2003-2007 Paul Mangan <paul@claws-mail.org>
-# *
-# * 2007-02-25: several fixes for kmail 1.9.6
-# --kmaildir now expects the full path
-# renamed from maildir2claws-mail.pl to kmail-mailbox2claws-mail.pl
-# * 2003-10-01: add --debug and --dry-run options
-# * 2003-09-30: updated/improved by Matthias Förste <itsjustme@users.sourceforge.net>
-# * 2003-05-27: version one
-
-## script name : kmail-mailbox2claws-mail.pl
-
-## script purpose : convert a Kmail mailbox into a Claws Mail mailbox
-
-## USAGE: kmail-mailbox2claws-mail.pl --kmaildir=/full/path/to/kmail/mailbox
-
-## tested with Kmail version 1.9.6
-
-use strict;
-
-use Getopt::Long;
-use File::Find;
-
-my $kmaildir = '';
-my $iNeedHelp = '';
-# dont actually change anything if set(useful in conjunction with debug)
-my $PRETEND = '';
-# print debug info if set
-my $DEBUG = '';
-
-my $claws_tmpdir = "$ENV{HOME}/claws_tmp";
-
-GetOptions("kmaildir=s" => \$kmaildir,
- "help" => \$iNeedHelp,
- "dry-run" => \$PRETEND,
- "debug" => \$DEBUG);
-
-if ($kmaildir eq "" || $iNeedHelp) {
- if (!$iNeedHelp) {
- print "No directory name given\n";
- }
- print "Use the following format:\n";
- print "\tkmail-mailbox2claws-mail.pl --kmaildir=full-path-to-kmail-dir\n\n";
- exit;
-}
-
-
-my $count = 1;
-my $MAIL_dir = "$kmaildir";
-
-my $find_opts = { wanted => \&process };
-
-if (-d $MAIL_dir) {
- find($find_opts , ($MAIL_dir));
-} else {
- print "\n$MAIL_dir is not a directory !\n";
- exit;
-}
-
-unless ($PRETEND) {
- mkdir("$claws_tmpdir", 0755);
- system("mv $claws_tmpdir $ENV{HOME}/Mail");
-
- print "\n\nSucessfully converted mailbox \"$MAIL_dir\"\n";
- print "Start claws-mail and right-click \"Mailbox (MH)\" and ";
- print "select \"Rebuild folder tree\"\n";
- print "You may also need to run \"/File/Folder/Check for ";
- print "new messages in all folders\"\n\n";
-}
-
-print "\n";
-exit;
-
-sub process() {
- if (-d) {
- process_dir($File::Find::dir);
- } else {
- process_file($File::Find::name);
- }
-}
-
-sub process_dir() {
- my $direc = shift();
- $DEBUG && print "\nDIR $direc";
-
- if ($direc !~ m/^drafts$/ &&
- $direc !~ m/^outbox$/ &&
- $direc !~ m/^trash$/ &&
- $direc !~ m/^inbox$/) {
- my $tmpdir = $direc;
- $tmpdir =~ s/^$MAIL_dir//;
- $tmpdir =~ s/\/sent-mail$/sent/;
- $tmpdir =~ s/\/cur$//;
- $tmpdir =~ s/\/new$//;
- $tmpdir =~ s/^\///;
- $tmpdir =~ s/\.directory//g;
- $tmpdir =~ s/\.//g;
-
- my $newdir = "$claws_tmpdir/$tmpdir";
- $DEBUG && print qq{\n>>> -e "$newdir" || mkdir("$newdir")};
- $PRETEND || -e "$newdir" || mkdir("$newdir");
- }
-
-}
-
-sub process_file {
- my $file = shift;
- $DEBUG && print "\nFILE $file";
-
- my $nfile;
- my $tmpfile = $file;
-
- $tmpfile =~ s|^$kmaildir||;
-
- if ($tmpfile =~ m/\/cur\// ||
- $tmpfile =~ m/\/new\//) {
-
- $tmpfile =~ s/\/new//;
- $tmpfile =~ s/\/cur//;
-
- my @spl_str = split("/", $tmpfile);
- pop(@spl_str);
- push(@spl_str, "$count");
-
- foreach my $spl_str (@spl_str) {
- $spl_str =~ s/\.directory$//;
- $spl_str =~ s/^\.//;
- $spl_str =~ s/^sent-mail$/sent/;
- }
- $nfile = join("/", @spl_str);
- $nfile = $claws_tmpdir.$nfile;
- }
-
- if (-e "$file" && $nfile ne "") {
- $DEBUG && print qq{\n+++ cp "$file" "$nfile"};
- $PRETEND || system("cp \"$file\" \"$nfile\"");
- $count++;
- }
-
-}
diff --git a/tools/kmail2claws-mail.pl b/tools/kmail2claws-mail.pl
@@ -1,211 +0,0 @@
-#!/usr/bin/perl
-
-# * Copyright 2002 Paul Mangan <paul@claws-mail.org>
-# *
-# * This file is free software; you can redistribute it and/or modify it
-# * under the terms of the GNU General Public License as published by
-# * the Free Software Foundation; either version 3 of the License, or
-# * (at your option) any later version.
-# *
-# * This program is distributed in the hope that it will be useful, but
-# * WITHOUT ANY WARRANTY; without even the implied warranty of
-# * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# * General Public License for more details.
-# *
-# * You should have received a copy of the GNU General Public License
-# * along with this program; if not, write to the Free Software
-# * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-
-## script name : kmail2claws-mail.pl
-
-## script purpose : convert a Kmail addressbook into a Claws Mail addressbook
-
-use Getopt::Long;
-
-$kmailfile = '';
-
-GetOptions("kmailfile=s" => \$kmailfile);
-
-$time = time;
-
-$claws_addr = "<?xml version=\"1.0\" encoding=\"US-ASCII\" ?>\n";
-$claws_addr .= "<address-book name=\"Kmail Address Book\" >\n";
-
-chdir;
-
-opendir(CLAWS, ".claws-mail") || die("Can't open .claws-mail directory\n");
- push(@cached,(readdir(CLAWS)));
-closedir(CLAWS);
-
-foreach $cached (@cached) {
- if ($cached =~ m/^addrbook/ && $cached =~ m/[0-9].xml$/) {
- push(@addr, "$cached");
- }
-}
-
-@sorted = sort {$a cmp $b} @addr;
-$last_one = pop(@sorted);
-$last_one =~ s/^addrbook-//;
-$last_one =~ s/.xml$//;
-$last_one++;
-$new_addrbk = "addrbook-"."$last_one".".xml";
-
-open (KFILE, "<$kmailfile") || die("Can't find the kmail file\n");
- @kmaillines = <KFILE>;
-close KFILE;
-
-$dross = shift(@kmaillines);
-
-foreach $kmailline (@kmaillines) {
- (@kmaildata) = split(/,/,$kmailline);
- foreach $kmaildata (@kmaildata) {
- $kmaildata =~ s/^"//;
- $kmaildata =~ s/"$//;
- $kmaildata =~ s/"/"/g;
- $kmaildata =~ s/&/&/g;
- $kmaildata =~ s/'/'/g;
- $kmaildata =~ s/</</g;
- $kmaildata =~ s/>/>/g;
- }
- $claws_addr .= " <person uid=\"$time\" first-name=\"$kmaildata[0]\""
- ." last-name=\"$kmaildata[1]\" nick-name=\"$kmaildata[7]\""
- ." cn=\"$kmaildata[0] $kmaildata[1]\" >\n"
- ." <address-list>\n";
- $time++;
- $claws_addr .= " <address uid=\"$time\" alias=\"\" email=\"$kmaildata[6]\""
- ." remarks=\"$kmaildata[8]\" />\n"
- ." </address-list>\n";
- if ($kmaildata[13] ne "" || $kmaildata[9] ne "" || $kmaildata[21] ne "" ||
- $kmaildata[16] ne "" || $kmaildata[5] ne "" || $kmaildata[24] ne "" ||
- $kmaildata[19] ne "" || $kmaildata[12] ne "" || $kmaildata[10] ne "" ||
- $kmaildata[4] ne "" || $kmaildata[2] ne "" || $kmaildata[11] ne "" ||
- $kmaildata[3] ne "" || $kmaildata[14] ne "" || $kmaildata[22] ne "" ||
- $kmaildata[17] ne "" || $kmaildata[20] ne "" || $kmaildata[15] ne "" ||
- $kmaildata[23] ne "" || $kmaildata[18] ne "") {
- $claws_addr .= " <attribute-list>\n";
-
- if ($kmaildata[3] ne "" || $kmaildata[2] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Full Name\" >"
- ."$kmaildata[3] $kmaildata[0] $kmaildata[2] $kmaildata[1]</attribute>\n";
- }
- if ($kmaildata[15] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Home Street Address\" >"
- ."$kmaildata[15]</attribute>\n";
- }
- if ($kmaildata[16] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Home City Address\" >"
- ."$kmaildata[16]</attribute>\n";
- }
- if ($kmaildata[17] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Home State Address\" >"
- ."$kmaildata[17]</attribute>\n";
- }
- if ($kmaildata[18] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Home Zip Address\" >"
- ."$kmaildata[18]</attribute>\n";
- }
- if ($kmaildata[19] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Home Country Address\" >"
- ."$kmaildata[19]</attribute>\n";
- }
- if ($kmaildata[10] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Home Phone\" >"
- ."$kmaildata[10]</attribute>\n";
- }
- if ($kmaildata[12] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Home Fax\" >"
- ."$kmaildata[12]</attribute>\n";
- }
- if ($kmaildata[11] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Mobile Phone\" >"
- ."$kmaildata[11]</attribute>\n";
- }
- if ($kmaildata[14] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Pager\" >"
- ."$kmaildata[14]</attribute>\n";
- }
- if ($kmaildata[5] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Company\" >"
- ."$kmaildata[5]</attribute>\n";
- }
- if ($kmaildata[4] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Job Title\" >"
- ."$kmaildata[4]</attribute>\n";
- }
- if ($kmaildata[20] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Business Street Address\" >"
- ."$kmaildata[20]</attribute>\n";
- }
- if ($kmaildata[21] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Business City Address\" >"
- ."$kmaildata[21]</attribute>\n";
- }
- if ($kmaildata[22] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Business State Address\" >"
- ."$kmaildata[22]</attribute>\n";
- }
- if ($kmaildata[23] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Business Zip Address\" >"
- ."$kmaildata[23]</attribute>\n";
- }
- if ($kmaildata[24] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Business Country Address\" >"
- ."$kmaildata[24]</attribute>\n";
- }
- if ($kmaildata[9] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Business Phone\" >"
- ."$kmaildata[9]</attribute>\n";
- }
- if ($kmaildata[13] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Business Fax\" >"
- ."$kmaildata[13]</attribute>\n";
- }
- $claws_addr .= " </attribute-list>\n";
- }
- $claws_addr .= " </person>\n";
- $time++;
-}
-$claws_addr .= "</address-book>\n";
-
-open (NEWADDR, ">.claws-mail/$new_addrbk");
-print NEWADDR $claws_addr;
-close NEWADDR;
-
-open (ADDRIN, "<.claws-mail/addrbook--index.xml") || die("can't open addrbook--index.xml");
- @addrindex_file = <ADDRIN>;
-close ADDRIN;
-
-foreach $addrindex_line (@addrindex_file) {
- if ($addrindex_line =~ m/<\/book_list>/) {
- $rewrite_addrin .= " <book name=\"Kmail Address Book\" file=\"$new_addrbk\" />\n"
- ." </book_list>\n";
- } else {
- $rewrite_addrin .= "$addrindex_line";
- }
-}
-
-open (NEWADDRIN, ">.claws-mail/addrbook--index.xml");
-print NEWADDRIN "$rewrite_addrin";
-close NEWADDRIN;
-
-print "\nYou have sucessfully converted your Kmail addressbook\n";
-exit;
diff --git a/tools/kmail2claws-mail_v2.pl b/tools/kmail2claws-mail_v2.pl
@@ -1,156 +0,0 @@
-#!/usr/bin/perl
-
-# * Copyright 2002 Paul Mangan <paul@claws-mail.org>
-# *
-# * This file is free software; you can redistribute it and/or modify it
-# * under the terms of the GNU General Public License as published by
-# * the Free Software Foundation; either version 3 of the License, or
-# * (at your option) any later version.
-# *
-# * This program is distributed in the hope that it will be useful, but
-# * WITHOUT ANY WARRANTY; without even the implied warranty of
-# * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# * General Public License for more details.
-# *
-# * You should have received a copy of the GNU General Public License
-# * along with this program; if not, write to the Free Software
-# * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-
-## script name : kmail2claws-mail_v2.pl
-
-## script purpose : convert an exported Kmail addressbook csv file
-## into a Claws Mail addressbook
-
-## tested with Kmail 1.4.7 and KAddressBook 3.1beta1
-
-use Getopt::Long;
-
-$kmailfile = '';
-$iNeedHelp = '';
-
-GetOptions("kmailfile=s" => \$kmailfile,
- "help" => \$iNeedHelp);
-
-if ($kmailfile eq "" || $iNeedHelp) {
- if (!$iNeedHelp) {
- print "No filename given\n";
- }
- print "Use the following format:\n";
- print "\tkmail2claws-mail_v2.pl --kmailfile=/path/to/addressbook.csv\n";
- exit;
-}
-
-$claws_dir = ".claws-mail";
-$addr_index = "$claws_dir/addrbook--index.xml";
-$new_addressbook = "Kmail address book";
-
-$time = time;
-
-chdir;
-
-opendir(CLAWS, $claws_dir) || die("Can't open $claws_dir directory\n");
- push(@cached,(readdir(CLAWS)));
-closedir(CLAWS);
-
-foreach $cached (@cached) {
- if ($cached =~ m/^addrbook/ && $cached =~ m/[0-9].xml$/) {
- push(@addr, "$cached");
- }
-}
-
-@sorted = sort {$a cmp $b} @addr;
-$last_one = pop(@sorted);
-$last_one =~ s/^addrbook-//;
-$last_one =~ s/.xml$//;
-$last_one++;
-$new_addrbk = "addrbook-"."$last_one".".xml";
-
-open (KFILE, "<$kmailfile") || die("Can't open the kmail file [$kmailfile]\n");
- @kmaillines = <KFILE>;
-close KFILE;
-
-$count = 0;
-$defs = shift(@kmaillines);
-@extra_def = (3,4,5,7 ... 27,29 ... 32,34 ... 42);
-
-(@kmaildefs) = split(/,/,$defs);
-
-$claws_addr = "<?xml version=\"1.0\" encoding=\"US-ASCII\" ?>\n";
-$claws_addr .= "<address-book name=\"Kmail address book\" >\n";
-
-foreach $kmailline (@kmaillines) {
- (@kmaildata) = split(/,/,$kmailline);
- foreach $kmaildata (@kmaildata) {
- $kmaildata =~ s/^"//;
- $kmaildata =~ s/"$//;
- $kmaildata =~ s/"/"/g;
- $kmaildata =~ s/&/&/g;
- $kmaildata =~ s/'/'/g;
- $kmaildata =~ s/</</g;
- $kmaildata =~ s/>/>/g;
- $kmaildata =~ s/\\n/, /g;
- chomp $kmaildata;
- }
- $claws_addr .= " <person uid=\"$time\" first-name=\"$kmaildata[2]\""
- ." last-name=\"$kmaildata[1]\" nick-name=\"$kmaildata[6]\""
- ." cn=\"$kmaildata[2] $kmaildata[1]\" >\n"
- ." <address-list>\n";
- $time++;
- $claws_addr .= " <address uid=\"$time\" alias=\"\" email=\"$kmaildata[28]\""
- ." remarks=\"$kmaildata[33]\" />\n"
- ." </address-list>\n";
-
- foreach $extra_def (@extra_def) {
- if ($kmaildata[$extra_def] ne "") {
- push (@def_exist, $extra_def);
- }
- }
- if ($def_exist[0]) {
- $claws_addr .= " <attribute-list>\n";
- }
- foreach $def_exist (@def_exist) {
- $kmaildefs[$def_exist] =~ s/^"//;
- $kmaildefs[$def_exist] =~ s/"$//;
- $kmaildefs[$def_exist] =~ s/'/'/g;
-
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"$kmaildefs[$def_exist]\" >"
- ."$kmaildata[$def_exist]</attribute>\n";
- $attribs = 1;
- }
- if ($attribs == 1) {
- $claws_addr .= " </attribute-list>\n";
- }
- $claws_addr .= " </person>\n";
- $time++;
- $count++;
-}
-$claws_addr .= "</address-book>\n";
-
-open (NEWADDR, ">$claws_dir/$new_addrbk");
-print NEWADDR $claws_addr;
-close NEWADDR;
-
-open (ADDRIN, "<$addr_index")
- || die("can't open $addr_index for reading");
- @addrindex_file = <ADDRIN>;
-close ADDRIN;
-
-foreach $addrindex_line (@addrindex_file) {
- if ($addrindex_line =~ m/<\/book_list>/) {
- $rw_addrindex .= " <book name=\"$new_addressbook\" file=\"$new_addrbk\" />\n"
- ." </book_list>\n";
- } else {
- $rw_addrindex .= "$addrindex_line";
- }
-}
-
-open (NEWADDRIN, ">$addr_index")
- || die("Can't open $addr_index for writing");
-print NEWADDRIN "$rw_addrindex";
-close NEWADDRIN;
-
-print "Done. $count address(es) converted successfully.\n";
-
-exit;
-
diff --git a/tools/mairix.sh b/tools/mairix.sh
@@ -1,38 +0,0 @@
-#!/bin/sh
-
-# * Copyright 2007 Tristan Chabredier <wwp@claws-mail.org>
-# *
-# * This file is free software; you can redistribute it and/or modify it
-# * under the terms of the GNU General Public License as published by
-# * the Free Software Foundation; either version 3 of the License, or
-# * (at your option) any later version.
-# *
-# * This program is distributed in the hope that it will be useful, but
-# * WITHOUT ANY WARRANTY; without even the implied warranty of
-# * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# * General Public License for more details.
-# *
-# * You should have received a copy of the GNU General Public License
-# * along with this program; if not, write to the Free Software
-# * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-#
-# mairix.sh mairix wrapper for Claws Mail
-
-# if any param is passed, $1 must be the mairixrc file to use
-# if no param is passed, ~/.mairixrc is assumed
-
-read TEXT
-test -z "$TEXT" && \
- exit 0
-
-if [ $# -ge 1 ]
-then
- RCFILE="$1"
- shift
-else
- RCFILE=~/.mairixrc
-fi
-
-mairix -f "$RCFILE" --purge && \
- mairix -f "$RCFILE" "$@" $TEXT
-exit $?
diff --git a/tools/make.themes.project b/tools/make.themes.project
@@ -1,257 +0,0 @@
-#!/usr/bin/env bash
-#
-# Generate the source directory for claws-mail-themes package
-# from the theme tarballs in http://www.claws-mail.org/themes.php
-#
-# Copyright (c) 2006-2010 Ricardo Mones <ricardo@mones.org>
-# Paul Mangan <paul@claws-mail.org>
-#
-# 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 Free Software Foundation; either version 3 of the License, or
-# (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-#
-
-test x$1 = x && echo "Error: version number not given" && exit 1;
-
-VERS=$1
-shift;
-SITE=http://www.claws-mail.org
-NAME=claws-mail-themes
-DDIR=$NAME-$VERS
-PAGE=themes.php
-LIST=themes.list
-WLOG=themes.wget.log
-
-function getListFromPage()
-{
- test -f ${PAGE} && rm -f ${PAGE};
- wget -q -a ${WLOG} ${SITE}/${PAGE}
- test ! -f ${PAGE} && echo "Error: couldn't get ${PAGE}." && exit 1;
-
- grep 'download.php?file=' ${PAGE} \
- | cut -f2 -d\" \
- > ${LIST}
-}
-
-function makeRoomForThemes()
-{
- test -d ${DDIR} \
- && rm -rf ${DDIR} \
- && echo "Removing previous destination";
- mkdir ${DDIR};
-}
-
-function downloadThemes()
-{
- for theme in `cat ${LIST} `;
- do tarf=`echo $theme | cut -f2 -d/ `;
- test $tarf = "png" \
- && tarf=`echo $theme | cut -f3 -d/ `;
- echo -n "Downloading... ";
- wget -q -a ${WLOG} -O ${DDIR}/$tarf ${SITE}/$theme
- test ! -f ${DDIR}/$tarf && echo "Error: couldn't get $tarf" && exit 1;
- pushd ${DDIR} > /dev/null
- tarops="";
- test ${tarf} = ${tarf/.tar.bz2/} && tarops="xzf" || tarops="xjf";
- echo -n "unpacking... " \
- && tar $tarops $tarf \
- && echo -n "deleting tarball... " \
- && rm -f $tarf \
- && echo "Ok ($tarf)";
- popd > /dev/null
- done;
-}
-
-function removeWhitespaces()
-{
- cd ${DDIR};
- for dir in *;
- do test -d "$dir" \
- && test ! "${dir}" = "${dir/ /_}" \
- && mv "${dir}" "${dir// /_}";
- done;
- cd "..";
-}
-
-function fixPermissions()
-{
- find ${DDIR} -type d -exec chmod 755 '{}' +
- find ${DDIR} -type f -exec chmod 644 '{}' +
-}
-
-function createProject()
-{
- touch ${DDIR}/${NAME}
-}
-
-function createThemeMakefileAm()
-{
- echo "Making $1";
- MA="/tmp/tmp.makefile.am";
- cd "$1"
- dir="$1";
- echo 'themedir = $(prefix)/share/claws-mail/themes/'${dir} > $MA
- echo "" >> $MA
- echo -n 'dist_theme_DATA =' >> $MA
- count_png=`ls -1 *.png 2> /dev/null | wc -l `
- count_xpm=`ls -1 *.xpm 2> /dev/null | wc -l `
- ext="xpm"
- count=$count_xpm
- if [ $count_png -gt $count_xpm ];
- then ext="png";
- count=$count_png;
- fi
- i=1;
- for px in `ls -1 *.${ext} `;
- do if [ $i -lt $count ];
- then echo " $px \\" >> $MA;
- else echo " $px" >> $MA;
- fi;
- i=$((1 + $i));
- done;
- echo "" >> $MA;
- count=`ls * | grep -v "\.${ext}$" | wc -l `;
- if [ $count -gt 0 ];
- then echo -n 'EXTRA_DIST =' >> $MA;
- i=1;
- for npx in `ls -1 * | grep -v "\.${ext}$" `;
- do if [ $i -lt $count ];
- then echo " $npx \\" >> $MA;
- else echo " $npx" >> $MA;
- fi;
- i=$((1 + $i));
- done;
- echo "" >> $MA;
- fi;
- mv $MA Makefile.am
- cd ".."
-}
-
-function createAutogenSh()
-{
- cat<<EOA > ${DDIR}/autogen.sh
-#!/bin/sh
-
-aclocal \
- && automake --add-missing --foreign --copy \
- && autoconf \
- && ./configure --enable-maintainer-mode $@
-EOA
- chmod +x ${DDIR}/autogen.sh
- echo "Created autogen.sh"
-}
-
-function createMakefileAm()
-{
- cd ${DDIR}
- MA=Makefile.am
- if [ -f INSTALL ]
- then echo "EXTRA_DIST = INSTALL "${NAME} > $MA
- else echo "EXTRA_DIST = "${NAME} > $MA
- fi
- echo "" >> $MA
- echo -n "SUBDIRS =" >> $MA
- for dir in *;
- do test -d "$dir" && echo -n " ${dir}" >> $MA;
- done;
- cd ".."
- echo "Created Makefile.am"
-}
-
-function createConfigureAc()
-{
- cd ${DDIR}
- CA=configure.ac
- echo 'AC_PREREQ(2.59d)' > $CA
- echo 'AC_INIT('${NAME}')' >> $CA
- echo 'AM_INIT_AUTOMAKE('${NAME}', '${VERS}')' >> $CA
- cat >> $CA <<EOC
-
-AM_MAINTAINER_MODE
-
-dnl Checks for programs.
-AC_PROG_INSTALL
-
-AC_OUTPUT([
-Makefile
-EOC
- # the list of Makefiles
- for dir in *;
- do test -d "$dir" \
- && echo "${dir}/Makefile" >> $CA \
- && createThemeMakefileAm "$dir";
- done;
- echo "])" >> $CA
- cd "..";
- echo "Created $CA";
-}
-
-function cleanMine()
-{
- find ${DDIR} -name Makefile.am -delete
- rm -f \
- ${DDIR}/autogen.sh \
- ${DDIR}/configure.ac \
- ${DDIR}/${NAME}
-}
-
-function cleanGenerated()
-{
- find ${DDIR} -name Makefile.in -delete
- find ${DDIR} -name Makefile -delete
- rm -rf ${DDIR}/autom4te.cache
- rm -f \
- ${DDIR}/aclocal.m4 \
- ${DDIR}/install-sh \
- ${DDIR}/missing \
- ${DDIR}/config.status \
- ${DDIR}/configure \
- ${DDIR}/config.log
-}
-
-case "$1" in
- --clean)
- cleanMine;
- echo "Cleaned.";
- ;;
- --clean-all)
- cleanMine;
- cleanGenerated;
- echo "Cleaned all.";
- ;;
- --download)
- getListFromPage;
- makeRoomForThemes;
- downloadThemes;
- echo "Downloaded.";
- ;;
- --autotoolize)
- removeWhitespaces;
- fixPermissions;
- createProject;
- createAutogenSh;
- createMakefileAm;
- createConfigureAc;
- echo "Autotoolized.";
- ;;
- --all)
- $0 $VERS --download
- $0 $VERS --autotoolize
- echo "Done.";
- ;;
- *)
- echo "Syntax: ";
- echo " $0 vers {--clean[-all]|--download|--autotoolize|--all}"
- ;;
-esac
-
diff --git a/tools/mew2claws-mail.pl b/tools/mew2claws-mail.pl
@@ -1,175 +0,0 @@
-#!/usr/bin/perl
-
-# * Copyright 2007 Jérôme Lelong <jerome.lelong@gmail.com>
-# *
-# * This file is free software; you can redistribute it and/or modify it
-# * under the terms of the GNU General Public License as published by
-# * the Free Software Foundation; either version 3 of the License, or
-# * (at your option) any later version.
-# *
-# * This program is distributed in the hope that it will be useful, but
-# * WITHOUT ANY WARRANTY; without even the implied warranty of
-# * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# * General Public License for more details.
-# *
-# * You should have received a copy of the GNU General Public License
-# * along with this program; if not, write to the Free Software
-# * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-
-## script name : mew2claws-mail.pl
-
-## script purpose : convert a Mew addressbook into a Claws Mail addressbook
-
-## This script assumes your Mew addressbook is Latin-1 encoded and not
-## unicode. In this latter case, you will have to hack this script a
-## little.
-
-use Getopt::Long;
-
-## Process the command line options
-## the program expects one argument: the Mew addressbook file
-
-my $help=0;
-my $mewfile='';
-GetOptions("mew-addressbook=s" => \$mewfile,
- "help" => \$help);
-
-if ($help==1)
-{
- print("usage : perl mew2claws-mail.pl [--help] [--mew-addressbook=file] \n");
- print("\t--help: displays this help\n");
- print("\t--mew-addressbook=file : file is the filename of your Mew addressbook\n");
- exit 0;
-}
-if ($mewfile ne '' && !-f $mewfile)
-{
- print("file $mewfile does not exists\n");
- exit 1;
-}
-
-$time=time;
-$claws_addr='';
-$home = glob("~");
-$clawsdir=`claws-mail --config-dir`;
-chomp($clawsdir);
-$clawsdir = $home . '/' . $clawsdir . '/' . 'addrbook/';
-
-opendir(CLAWS, $clawsdir) || die("Can't open $clawsdir directory\n");
-push(@cached,(readdir(CLAWS)));
-closedir(CLAWS);
-
-## find the first availabel name for a new addressbook in claws-mail
-foreach $cached (@cached)
-{
- if ($cached =~ m/^addrbook/ && $cached =~ m/[0-9].xml$/)
- {
- push(@addr, "$cached");
- }
-}
-@sorted = sort {$a cmp $b} @addr;
-$last_one = pop(@sorted);
-$last_one =~ s/^addrbook-//;
-$last_one =~ s/.xml$//;
-$last_one++;
-$new_addrbk = "addrbook-"."$last_one".".xml";
-
-
-open (MEWFILE, "<$mewfile") || die("Can't find the Mew addressbook file\n");
-@mewentries = <MEWFILE>;
-close MEWFILE;
-
-$claws_addr .= "<?xml version=\"1.0\" encoding=\"ISO8859-1\" ?>\n"
-. "<address-book name=\"Mew Address Book\" >";
-
-
-chomp(@mewentries);
-foreach $line (@mewentries)
-{
- $line =~ s/ *\t/ /g;
- $line =~ s/ *$//g;
- (@fields) = split(/ +/,$line);
- $nickname= shift(@fields);
- @emails=();
- $alias='';
- $firstname='';
- $lastname='';
- while (1)
- {
- $field = shift(@fields);
- if ($field =~ m/@/)
- {
- $field =~ s/,$//;
- push(@emails, $field);
- } else
- {
- unshift(@fields, $field);
- last;
- }
- }
- $alias = shift(@fields);
- if ($alias eq "\*")
- {
- print($alias . "\n");
- $alias='';
- }
-
-
- $firstname=shift(@fields); $firstname =~ s/"//g;
- foreach (@fields)
- {
- $lastname .= "$_ ";
- }
- $lastname =~ s/"//g;
- $lastname =~ s/ *$//g;
-
- $claws_addr .= " <person uid=\"$time\" first-name=\"$firstname\""
- ." last-name=\"$lastname\" nick-name=\"$nickname\""
- ." cn=\"$firstname $lastname\" >\n"
- ." <address-list>\n";
- $time++;
-
- foreach $email (@emails)
- {
- $claws_addr .= " <address uid=\"$time\" alias=\"$alias\" email=\"$email\""
- ." remarks=\"\" />\n";
- $time++;
- }
- $claws_addr .= " </address-list>\n"
- . " <attribute-list>\n"
- . " </attribute-list>\n";
- $claws_addr .= " </person>\n";
- $time++;
-}
-$claws_addr .= "</address-book>\n";
-
-open (NEWADDR, ">$clawsdir/$new_addrbk") ;
-print NEWADDR ($claws_addr);
-close NEWADDR;
-
-open (ADDRIN, "<$clawsdir/addrbook--index.xml") || die("can't open addrbook--index.xml");
-@addrindex_file = <ADDRIN>;
-close ADDRIN;
-
-foreach $addrindex_line (@addrindex_file)
-{
- if ($addrindex_line =~ m/<book name=\"Mew Address Book\"/)
- {
- print("An entry already exists for \"Mew Address Book\", you may duplicate it\n");
- print("Continuing anyway...\n");
- }
- if ($addrindex_line =~ m/<\/book_list>/)
- {
- $rewrite_addrin .= " <book name=\"Mew Address Book\" file=\"$new_addrbk\" />\n"
- ." </book_list>\n";
- } else
- {
- $rewrite_addrin .= "$addrindex_line";
- }
-}
-
-open (NEWADDRIN, ">$clawsdir/addrbook--index.xml");
-print NEWADDRIN "$rewrite_addrin";
-close NEWADDRIN;
-
-print "\nYou have sucessfully converted your Mew addressbook\n";
-exit;
diff --git a/tools/multiwebsearch.conf b/tools/multiwebsearch.conf
@@ -1,5 +0,0 @@
-cpan|http://search.cpan.org/search?mode=module&query=
-ddg|https://duckduckgo.com/?q=
-rfc|http://www.ietf.org/rfc/rfc|.txt
-sf|http://sourceforge.net/search/?type_of_search=soft&words=
-usenet|http://groups.google.com/groups?q=|&meta=site%3Dgroups
diff --git a/tools/multiwebsearch.pl b/tools/multiwebsearch.pl
@@ -1,79 +0,0 @@
-#!/usr/bin/perl
-
-# * Copyright 2003-2007 Paul Mangan <paul@claws-mail.org>
-# *
-# * This file is free software; you can redistribute it and/or modify it
-# * under the terms of the GNU General Public License as published by
-# * the Free Software Foundation; either version 3 of the License, or
-# * (at your option) any later version.
-# *
-# * This program is distributed in the hope that it will be useful, but
-# * WITHOUT ANY WARRANTY; without even the implied warranty of
-# * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# * General Public License for more details.
-# *
-# * You should have received a copy of the GNU General Public License
-# * along with this program; if not, write to the Free Software
-# * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-# *
-
-# Changes:
-# Feb 2007: add support for non ISO-8859-1 compatible locales
-# by Alex Gorbachenko <agent_007@immo.ru>
-#
-
-use Getopt::Long;
-use URI::Escape;
-use POSIX qw(locale_h);
-use Text::Iconv;
-
-my $where = '';
-my $what = '';
-
-GetOptions("where=s" => \$where,
- "what=s" => \$what);
-
-$locale = setlocale(LC_CTYPE);
-$locale =~ s/\S+\.//;
-
-$converter = Text::Iconv->new("$locale", "UTF-8");
-$safe=uri_escape($converter->convert("$what"));
-$what=$safe;
-
-chdir($ENV{HOME} . "/.claws-mail")
- || die("Can't find your ~/.claws-mail directory\n");
-
-open (CONF, "<multiwebsearch.conf")
- || die("Can't open ~/.claws-mail/multiwebsearch.conf\n");
- @conflines = <CONF>;
-close CONF;
-
-foreach $confline (@conflines) {
- if ($confline =~ m/^$where\|/) {
- chomp $confline;
- @parts = split(/\|/, $confline);
- $url = $parts[1];
- if ($parts[2]) {
- $what .= $parts[2];
- }
- }
-}
-
-if (!$url) {
- die("No url found with the alias \"$where\"\n");
-}
-
-open (SYLRC, "<clawsrc")
- || die("Can't open ~/.claws-mail/clawsrc\n");
- @rclines = <SYLRC>;
-close SYLRC;
-
-foreach $rcline (@rclines) {
- if ($rcline =~ m/^uri_open_command/) {
- chomp $rcline;
- @browser = split(/=/, $rcline);
- $browser[1] =~ s/%s/$url$what/;
- }
-}
-system("$browser[1]&");
-exit;
diff --git a/tools/nautilus2claws-mail.sh b/tools/nautilus2claws-mail.sh
@@ -1,54 +0,0 @@
-#!/usr/bin/env bash
-
-# nautilus2claws-mail.sh
-# Copyright 2004 Reza Pakdel <hrpakdel@cpsc.ucalgary.ca>
-
-# 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 Free Software Foundation; either version 3
-# of the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
-# 02111-1307, USA.
-
-# This script will recursively attach a number of selected
-# files/directories from Nautilus to a new blank e-mail.
-
-# Authors: Reza Pakdel <hrpakdel@cpsc.ucalgary.ca>
-# Stephan Sachse <white@teg-clan.de>
-#
-# Fixes:
-# Stephan Sachse : files/directorys with whitspaces
-
-
-SELECTED_PATHS="${NAUTILUS_SCRIPT_SELECTED_FILE_PATHS}"
-NB_SELECTED_PATHS=`echo -n "${SELECTED_PATHS}" | wc -l | awk '{print $1}'`
-
-ATTACHMENTS=""
-
-for ((i=${NB_SELECTED_PATHS}; i>0; i--)) ; do
- CURRENT_PATH=`echo -n "${SELECTED_PATHS}" | head -n${i} | tail -n1`
- if test -d "${CURRENT_PATH}" ; then
- FILES_FOUND=`find "${CURRENT_PATH}" -type f`
- NB_FILES_FOUND=`echo "${FILES_FOUND}" | wc -l | awk '{print $1}'`
- for ((j=${NB_FILES_FOUND}; j>0; j--)) ; do
- CURRENT_FILE=`echo "${FILES_FOUND}" | head -n${j} | tail -n1`
- ATTACHMENTS="${ATTACHMENTS} \"${CURRENT_FILE}\""
- done
- else
- ATTACHMENTS="${ATTACHMENTS} \"${CURRENT_PATH}\""
- fi
-done
-
-echo "-----------"
-echo ${ATTACHMENTS}
-
-eval "claws-mail --compose --attach ${ATTACHMENTS}"
-
diff --git a/tools/outlook2claws-mail.pl b/tools/outlook2claws-mail.pl
@@ -1,219 +0,0 @@
-#!/usr/bin/perl -w
-
-# Copyright 2002-2003 Ricardo Mones <ricardo@mones.org>
-#
-# This file is free software; you can redistribute it and/or modify it
-# under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 3 of the License, or
-# (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful, but
-# WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-#
-# outlook2claws-mail.pl -- perl script to convert an Outlook generated
-# contact list into a Claws Mail XML address book.
-#
-# This script is based on:
-# out2syl.sh by Rafael Lossurdo <mugas@via-rs.net>
-# kmail2claws-mail.pl by Paul Mangan <paul@claws-mail.org>
-#
-# See README file for details and usage.
-#
-
-$nboffields = 28; # change this only if you did read README
-
-# parse parameters
-$do_csv = 0;
-die "Error: required filename missing\n" unless (defined($ARGV[0]));
-$_=$ARGV[0];
-if (/--csv/) {
- die "Error: required filename missing\n" unless (defined($ARGV[1]));
- $do_csv = 1;
- $outl_file = $ARGV[1];
-}
-else {
- $outl_file = $ARGV[0];
-}
-# some init
-$clawsconf = ".claws-mail/addrbook";
-$indexname = "$clawsconf/addrbook--index.xml";
-
-# the next is mostly Paul's code
-$time = time;
-
-chdir;
-opendir(CLAWS, $clawsconf) || die("Error: can't open $clawsconf directory\n");
- push(@cached,(readdir(CLAWS)));
-closedir(CLAWS);
-
-foreach $cached (@cached) {
- if ($cached =~ m/^addrbook/ && $cached =~ m/[0-9].xml$/) {
- push(@addr, "$cached");
- }
-}
-
-@sorted = sort {$a cmp $b} @addr;
-$last_one = pop(@sorted);
-$last_one =~ s/^addrbook-//;
-$last_one =~ s/.xml$//;
-$last_one++;
-$new_book = "/addrbook-"."$last_one".".xml";
-
-# some subs
-# warning: output file is global
-sub write_header {
- print NEWB "<?xml version=\"1.0\" encoding=\"US-ASCII\" ?>\n";
- print NEWB "<address-book name=\"Outlook Address Book\" >\n";
-}
-
-sub write_footer {
- print NEWB "</address-book>\n";
-}
-
-sub write_person_h {
- my($fn, $ln, $nn, $cn) = @_;
- # one of them must be given
- if (($fn eq "") and ($ln eq "") and ($nn eq "") and ($cn eq "")) {
- $cn = "No name provided";
- # but return may break XML structure
- }
- print NEWB " <person uid=\"", $time++, "\" first-name=\"", $fn, "\" ";
- print NEWB "last-name=\"", $ln, "\" nick-name=\"", $nn, "\" cn=\"", $cn, "\" >\n";
-}
-
-sub write_person_f {
- print NEWB " </person>\n";
-}
-
-sub write_addrlist_h {
- print NEWB " <address-list>\n";
-}
-
-sub write_addrlist_f {
- print NEWB " </address-list>\n";
-}
-
-sub write_address {
- my($al, $em, $re) = @_;
- if ($em eq "") {
- $em = "No e-mail address";
- # email is a must -> no address breaks claws-mail display
- # (claws-mail says file is ok but no name is shown)
- # maybe this is a bug on claws-mail?
- }
- print NEWB " <address uid=\"", $time++, "\" ";
- print NEWB "alias=\"", $al, "\" email=\"", $em, "\" remarks=\"", $re, "\" />\n";
-}
-
-sub write_attrlist_h {
- print NEWB " <attribute-list>\n";
-}
-
-sub write_attrlist_f {
- print NEWB " </attribute-list>\n";
-}
-
-sub write_attribute {
- my($aname, $aval) = @_;
- if (($aname eq "") or ($aval eq "")) { return; } # both are must
- print NEWB " <attribute uid=\"", $time++, "\" ";
- print NEWB "name=\"", $aname, "\" >", $aval, "</attribute>\n";
-}
-
-sub process_text {
- write_header();
- $count = 0;
- while (<OUTL>) {
- chomp;
- if (/\s+[0-9]+\s+(.+)/) { $_ = $1; }
- else { $count += 2 and die "Error: wrong format at line $count \n"; }
- @field = split(/;/); # first is name, second mail addr
- write_person_h("","","",$field[0]);
- write_addrlist_h();
- $field[1] =~ s/\r//; # beware, dangerous chars inside ;)
- write_address("",$field[1],"");
- write_addrlist_f();
- write_person_f();
- ++$count;
- }
- write_footer();
-}
-
-sub process_csv {
- write_header();
- $count = 0;
- while (<OUTL>) {
- chomp;
- # do something useful: quote XML chars
- s/\&/&/g;
- s/\</</g;
- s/\>/>/g;
- s/\'/'/g;
- s/\"/"/g;
- @field = split(/,/);
- if ($#field != $nboffields) { $count += 2 and die "Error: wrong format at line $count \n"; }
- # First Name, Last Name, Nickname, Name
- write_person_h($field[0],$field[1],$field[4],$field[3]);
- write_addrlist_h();
- write_address("",$field[5],$field[$nboffields - 1]);
- write_addrlist_f();
- write_attrlist_h(); # the remaining values as attributes
- foreach $a (2, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27) {
- # add only filled fields (should be trimmed?)
- if (defined($field[$a]) && $field[$a] ne "") {
- write_attribute($headerline[$a],$field[$a]);
- }
- }
- write_attrlist_f();
- write_person_f();
- ++$count;
- }
- write_footer();
-}
-
-# ok, was enough, do some more bit bashing now
-open(OUTL, $outl_file)
- or die "Error: can't open $outl_file for reading\n";
-# 1st line: file format checking (csv) or discarding (default)
-$_ = <OUTL>;
-chomp;
-if ($do_csv) {
- @headerline = split(/,/);
- # check before creating output file
- die "Error: unknown csv file format\n"
- unless ($#headerline == $nboffields);
-}
-open(NEWB, '>', "$clawsconf/$new_book")
- or die "Error: can't open $clawsconf/$new_book for writing\n";
-if ($do_csv) { process_csv(); }
-else { process_text(); }
-
-close NEWB;
-close OUTL;
-
-# update index (more Paul's code :)
-
-open(INDX, $indexname)
- or die "Error: can't open $indexname for reading\n";
-@index_file = <INDX>;
-close INDX;
-
-foreach $index_line (@index_file) {
- if ($index_line =~ m/<\/book_list>/) {
- $new_index .= " <book name=\"Outlook Address Book\" file=\"$new_book\" />\n"." </book_list>\n"; } else {
- $new_index .= "$index_line";
- }
-}
-open (INDX, '>', $indexname)
- or die "Error: can't open $indexname for writing\n";
-print INDX "$new_index";
-close INDX;
-
-print "Done. $count address(es) converted successfully.\n";
-
diff --git a/tools/popfile-link.sh b/tools/popfile-link.sh
@@ -1,70 +0,0 @@
-#!/usr/bin/env bash
-
-# * Copyright 2007 Tristan Chabredier <wwp@claws-mail.org>
-# *
-# * This file is free software; you can redistribute it and/or modify it
-# * under the terms of the GNU General Public License as published by
-# * the Free Software Foundation; either version 3 of the License, or
-# * (at your option) any later version.
-# *
-# * This program is distributed in the hope that it will be useful, but
-# * WITHOUT ANY WARRANTY; without even the implied warranty of
-# * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# * General Public License for more details.
-# *
-# * You should have received a copy of the GNU General Public License
-# * along with this program; if not, write to the Free Software
-# * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-#
-# popfile-link.sh helper script to open messages in POPFile's control center
-# in order to edit their status
-
-# Requires that POPFile is running and that the message has been processed
-# by it (X-POPFile-Link: header present). POPFile control center opens with
-# the web browser set in Claws Mail prefs.
-
-
-open_page()
-{
- TMPCMD=$(echo $OPEN_CMD | sed "s|\"%s\"|$1|")
- $TMPCMD &
-}
-
-
-SESSION_ID=""
-if [ "$1" = "--ask-session-id" ]
-then
- shift
- SESSION_ID=$(gxmessage -entry -center -wrap -buttons "OK:0,Cancel:1" -default "OK" \
- -name "popfile-link" -title "POPFile session ID" "Type in the ID of a running POPFile session to use")
- test -z "$SESSION_ID" -o $? -ne 0 && \
- exit 0
-fi
-
-test -z "$1" && \
- exit 1
-
-CM_DIR=$(claws-mail --config-dir)
-test -z "$CM_DIR" -o ! -d "$HOME/$CM_DIR" && \
- exit 1
-
-OPEN_CMD=$(grep -Em 1 "^uri_open_command=" "$HOME/$CM_DIR/clawsrc" | cut -d '=' -f 2-)
-test -z "$OPEN_CMD" && \
- exit 1
-
-while [ -n "$1" ]
-do
- LINK=$(grep -Eim 1 "^X\-POPFile\-Link: " "$1")
- if [ -n "$LINK" ]
- then
- LINK=${LINK:16}
- if [ -n "$SESSION_ID" ]
- then
- open_page "${LINK}\\&session=$SESSION_ID"
- else
- open_page "$LINK"
- fi
- fi
- shift
-done
-exit 0
diff --git a/tools/tb2claws-mail b/tools/tb2claws-mail
@@ -1,278 +0,0 @@
-#!/usr/bin/perl
-
-# Script name : tb2claws-mail
-# Script version: 1.0.2
-# Script based on : script kmail2claws-mail.pl
-# Script purpose : convert The Bat! addressbook into Claws Mail addressbook
-# Author : Aleksandar Urosevic aka Urke MMI <urke@gmx.net>
-# Licence : GPL
-#
-# Thanks goes to : Paul Mangan <paul@claws-mail.org>
-#
-# Usage: Export The Bat! Address Book to CSV file format
-# with all fields selected to YES and then start:
-# tb2claws-mail --tbfile=/full/path/to/thebat/addressbook.csv
-#
-# Change Log:
-#
-# 18-12-2003 v 1.0.2
-# - bugfix: added missing attribute-list start
-#
-# 01-01-2003 v 1.0.1
-# - bugfix: no more empty Business Homepage entry
-# - bugfix: no more \0D\0A´s in Notes entry
-# - bugfix: no more double space in Full Name entry
-# - code utilization
-# - add info about number of converted addresses
-#
-# 15-08-2002 v 1.0.0
-# - first public release
-#
-# TODO:
-#
-# * Add switch for Full Name entry on atrybute part
-#
-
-use Getopt::Long;
-
-GetOptions("tbfile=s" => \$tbfile);
-
-#$tbfile = '/home/urke/bin/claws-mail/tb2ldif/thebat-addressbook.csv';
-$total_addresses = 0;
-
-chdir;
-
-# check is Claws-Mail instrtalled
-opendir(CLAWS, ".claws-mail/addrbook") || die("Can't open Claws Mail directory! Conversion aborted\n");
- push(@cached, (readdir(CLAWS)));
-closedir(CLAWS);
-
-# get last existing addressbook filename
-# to set filename for newest addressbook
-
-# get all existing addressbook filenames
-foreach $cached (@cached) {
- if ($cached =~ m/^addrbook/ && $cached =~ m/[0-9].xml$/) {
- push(addr, "$cached");
- }
-}
-# sort filenames, get last and set newest filename
-@sorted = sort {$a cmp $b} @addr;
-$last_one = pop(@sorted);
-$last_one =~ s/^addrbook-//;
-$last_one =~ s/.xml$//;
-$last_one++;
-$new_addrbk = "addrbook-"."$last_one".".xml";
-
-# open thebat file to stack
-open (TBFILE, "<$tbfile") || die("Specified Address Book file does not exist.\n\033[5m\033[31mYou must specify full path to input file!\033[0m\nConversion aborted.\n");
- @tblines = <TBFILE>;
-close TBFILE;
-
-# shift firs line from file because this is field names
-$dross = shift(@tblines);
-
-# set time mark and header of addressbook
-$time = time;
-$claws_addr = "<?xml version=\"1.0\" encoding=\"ISO-8859-2\" ?>\n";
-$claws_addr .= "<address-book name=\"The Bat! Address Book\" >\n";
-
-# create addressbook entry from The Bat! addressbook
-foreach $tbline (@tblines) {
- $total_addresses += 1;
- (@tbdata) = split(/,/,$tbline);
- foreach $tbdata (@tbdata) {
- # fix nonacceptable characters
- $tbdata =~ s/^"//;
- $tbdata =~ s/"$//;
- $tbdata =~ s/"/"/g;
- $tbdata =~ s/&/&/g;
- $tbdata =~ s/'/'/g;
- $tbdata =~ s/</</g;
- $tbdata =~ s/>/>/g;
- $tbdata =~ s/\\2C\ /, /g;
- $tbdata =~ s/(\\0D\\0A){1,}/, /g;
- $tbdata =~ s/\ {2,}/ /g;
- }
- # set addressbook field values
- $claws_addr .= " <person uid=\"$time\" first-name=\"$tbdata[1]\""
- ." last-name=\"$tbdata[2]\" nick-name=\"$tbdata[5]\""
- ." cn=\"$tbdata[0]\" >\n"
- ." <address-list>\n";
- $time++;
- $claws_addr .= " <address uid=\"$time\" alias=\"$tbdata[5]\" email=\"$tbdata[4]\""
- ." remarks=\"\" />\n"
- ." </address-list>\n";
-
- # find is need to make entry attributes
- $check = 0;
- for($i=6; $i<=31; $i++) {
- $tbdata[$i] =~ s/^\s+//;
- $tbdata[$i] =~ s/\s+$//;
- if ($tbdata[$i] ne "") { $check += 1; }
- }
-
- if ($check > 0) {
- $claws_addr .= " <attribute-list>\n";
- if ($tbdata[1] ne "" || $tbdata[2] ne "") {
- $time++;
- if($tbdata[29] ne "" && $tbdata[1] ne "") { $full_name = "$tbdata[29] $tbdata[1]"; } else { $full_name = "$tbdata[1]"; }
- if($tbdata[3] ne "") { $full_name .= " $tbdata[3]"; }
- if($tbdata[2] ne "") { $full_name .= " $tbdata[2]"; }
- if($tbdata[28] ne "") { $full_name .= " $tbdata[28]"; }
-
- $claws_addr .= " <attribute uid=\"$time\" name=\"Full Name\" >"
- ."$full_name</attribute>\n";
- }
- if ($tbdata[15] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Home Street Address\" >"
- ."$tbdata[15]</attribute>\n";
- }
- if ($tbdata[16] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Home City Address\" >"
- ."$tbdata[16]</attribute>\n";
- }
- if ($tbdata[17] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Home State Address\" >"
- ."$tbdata[17]</attribute>\n";
- }
- if ($tbdata[18] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Home Zip Address\" >"
- ."$tbdata[18]</attribute>\n";
- }
- if ($tbdata[19] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Home Country Address\" >"
- ."$tbdata[19]</attribute>\n";
- }
- if ($tbdata[9] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Home Phone\" >"
- ."$tbdata[9]</attribute>\n";
- }
- if ($tbdata[10] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Home Fax\" >"
- ."$tbdata[10]</attribute>\n";
- }
- if ($tbdata[11] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Mobile Phone\" >"
- ."$tbdata[11]</attribute>\n";
- }
- if ($tbdata[30] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Personal Homepage\" >"
- ."$tbdata[30]</attribute>\n";
- }
- if ($tbdata[14] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Pager\" >"
- ."$tbdata[14]</attribute>\n";
- }
- if ($tbdata[7] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Bussines Company\" >"
- ."$tbdata[7]</attribute>\n";
- }
- if ($tbdata[8] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Bussines Job Title\" >"
- ."$tbdata[8]</attribute>\n";
- }
- if ($tbdata[20] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Business Department\" >"
- ."$tbdata[20]</attribute>\n";
- }
- if ($tbdata[21] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Business Office\" >"
- ."$tbdata[21]</attribute>\n";
- }
- if ($tbdata[22] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Business Street Address\" >"
- ."$tbdata[22]</attribute>\n";
- }
- if ($tbdata[23] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Business City Address\" >"
- ."$tbdata[23]</attribute>\n";
- }
- if ($tbdata[24] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Business State Address\" >"
- ."$tbdata[24]</attribute>\n";
- }
- if ($tbdata[25] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Business Zip Address\" >"
- ."$tbdata[25]</attribute>\n";
- }
- if ($tbdata[26] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Business Country Address\" >"
- ."$tbdata[26]</attribute>\n";
- }
- if ($tbdata[12] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Business Phone\" >"
- ."$tbdata[12]</attribute>\n";
- }
- if ($tbdata[13] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Business Fax\" >"
- ."$tbdata[13]</attribute>\n";
- }
- if ($tbdata[31] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Business Homepage\" >"
- ."$tbdata[31]</attribute>\n";
- }
- if ($tbdata[27] ne "") {
- $time++;
- $claws_addr .= " <attribute uid=\"$time\" name=\"Notes\" >"
- ."$tbdata[27]</attribute>\n";
- }
- $claws_addr .= " </attribute-list>\n";
- }
-# if ( $check > 0 ) {
-# $claws_addr .= "</attribute-list>\n";
-# }
-
- $claws_addr .= " </person>\n";
- $time++;
-}
-$claws_addr .= "</address-book>\n";
-
-# print new addressbook to file
-open (NEWADDR, ">.claws-mail/addrbook/$new_addrbk");
- print NEWADDR $claws_addr;
-close NEWADDR;
-
-# add new addressbook to index
-open (ADDRIN, "<.claws-mail/addrbook/addrbook--index.xml") || die("Can't open addrbook--index.xml");
- @addrindex_file = <ADDRIN>;
-close ADDRIN;
-
-foreach $addrindex_line (@addrindex_file) {
- if ($addrindex_line =~ m/<\/book_list>/) {
- $rewrite_addrin .= " <book name=\"The Bat! Address Book\" file=\"$new_addrbk\" />\n"
- ." </book_list>\n";
- } else {
- $rewrite_addrin .= "$addrindex_line";
- }
-}
-
-open (NEWADDRIN, ">.claws-mail/addrbook/addrbook--index.xml");
- print NEWADDRIN "$rewrite_addrin";
-close NEWADDRIN;
-print "You have sucessfully converted your The Bat! addressbook\n";
-print "New addressbook file name: $new_addrbk\n";
-print "Total addresses converted: $total_addresses\n";
-exit;
diff --git a/tools/tbird2claws.py b/tools/tbird2claws.py
@@ -1,133 +0,0 @@
-#!/usr/bin/env python3
-
-# Script name : tbird2claws.py
-# Script purpose : Integrate a Thunderbird folder tree to Claws Mail
-# Author : Aleksandar Urosevic aka Urke MMI <urke@gmx.net>
-# Licence : GPL
-# Author: Rodrigo Dias Arruda Senra
-
-#The script receives two parameters from command-line:
-#<Thunderbird folder path> <Claws Mail folder path>
-
-#Best way to use it is to go to inside yout Thunderbird
-#root mailfolder directory and invoke it as:
-
-#<path>\python3 <path>\tbird2claws.py . <path to claws-mail>\Mail
-
-import os
-import sys
-import importlib
-
-__author__ = 'Rodrigo Senra <rsenra@acm.org>'
-__date__ = '2005-03-23'
-__version__ = '0.3'
-
-__doc__ = r"""
-This module integrates your Mozilla Thunderbird 1.0 tree to
-your Claws Mail MH mailbox tree.
-
-The script receives two parameters from command-line:
- <Thunderbird folder path> <Claws Mail folder path>
-
-Best way to use it is to go to inside your Thunderbird
-root mailfolder directory and invoke it as:
-
- <path>\python3 <path>\tbird2claws.py . <path to claws mail>\Mail
-
-This idiom will avoid the creation of the folder Thunderbird inside
-your Claws Mail folder tree.
-
-If the names of your directories match in both trees, files should
-be placed in the correct folder.
-
-This is an alpha release, so it may be a little rough around the edges.
-Nevertheless, I used it with great success to convert a very large and
-deep folder tree.
-
-Please, do backup your claws-mail (destination) folder tree before trying
-this out. Live safe and die old!
-
-This code is released in the public domain.
-"""
-
-def harvest_offsets(filepath):
- """Given the filepath, this runs through the file finding
- the number of the line where a message begins.
-
- The function returns a list of integers corresponding to
- the beginning of messages.
- """
- offsets = []
- i = 0
- state = 'begin'
- for i,line in enumerate(open(filepath)):
- if line.startswith('From - ') and state!='found_head':
- offsets.append(i)
- continue
-# elif line.startswith('Return-Path') and state=='found_head':
-# state = 'found_offset'
-# offsets.append(i)
-# continue
- offsets.append(i)
- return offsets
-
-def make_messages(outputdir, filepath, offsets, start):
- """Given a filepath holding several messages in Thunderbird format,
- extract the messages and create individual files for them, inside
- outputdir with appropriate the appropriate naming scheme.
- """
- if not os.path.exists(outputdir):
- os.makedirs(outputdir)
- if not os.path.exists(filepath):
- raise Exception('Cannot find message file %s'%(filepath))
- lines = open(filepath).readlines()
- aux = offsets[:]
- msgoffs = zip(offsets[:-1], aux[1:])
- for i,j in msgoffs:
- fd = open(os.path.join(outputdir,"%d"%start),"w")
- fd.write(''.join(lines[i:j-1])) #-1 to remove first from line
- fd.close()
- start +=1
-
-def process_file(filepath, outputdir):
- """Integrates a Thunderbird message file into a claws-mail message directory.
- """
- offs = harvest_offsets(filepath)
- make_messages(outputdir, filepath, offs, 1)
-
-def clean_path(path):
- """Rename all directories and subdirectories <X>.sbd to <X>
- """
- l = []
- f = os.path.basename(path)
- while f and f != "":
- if f.endswith('.sbd'):
- f = f[:-4]
- l.append(f)
- path = os.path.dirname(path)
- f = os.path.basename(path)
- l.reverse()
- r = os.path.join(*l)
- return r
-
-
-
-def convert_tree(in_treepath, out_treepath):
- """Traverse your thunderbird tree, converting each message file found into
- a claws-mail message directory.
- """
- for path,subs,files in os.walk(in_treepath):
- outpath = clean_path(path)
- if files:
- for f in [x for x in files if not x.endswith('.msf')]:
- process_file(os.path.join(path,f),
- os.path.join(out_treepath,outpath,f))
-
-if __name__=='__main__':
- if len(sys.argv)<3:
- print (__doc__)
- else:
- if sys.version[0] == '2':
- importlib.reload(sys)
- sys.setdefaultencoding('utf8')
- convert_tree(sys.argv[1], sys.argv[2])
diff --git a/tools/textviewer.pl b/tools/textviewer.pl
@@ -1,178 +0,0 @@
-#!/usr/bin/perl
-
-# COPYRIGHT AND LICENSE
-# Copyright (C) 2005-2018 H.Merijn Brand
-#
-# This script is free software; you can redistribute it and/or modify it
-# under the same terms as Perl and/or Claws Mail itself. (GPL)
-
-use 5.14.1;
-use warnings;
-
-our $VERSION = "1.01 - 2018-10-08";
-our $CMD = $0 =~ s{.*/}{}r;
-
-sub usage {
- my ($err, $str) = (@_, "");
- $err and select STDERR;
- say "usage: $CMD [--html] [--type=<type>] file\n",
- " --html Generate HTML (if supported)\n",
- " --type=X X as mimetype (msword => doc)\n",
- " $CMD --list will show all implemented conversions";
- $str and say $str;
- exit $err;
- } # usage
-
-use Getopt::Long qw(:config bundling nopermute);
-my $opt_v = 0;
-my $opt_h = "text";
-GetOptions (
- "help|?" => sub { usage (0); },
- "V|version" => sub { say "$CMD [$VERSION]"; exit 0; },
-
- "v|verbose:1" => \$opt_v,
- "t|type|mimetype=s" => \my $opt_t,
- "h|html" => sub { $opt_h = "html" },
- "l|list!" => \my $opt_l,
- ) or usage (1);
-
-$opt_v and say "$0 @ARGV";
-
-# anon-list contains all possible commands to show content
-# plain text is a reference to same type (alias)
-# %f will be replaced with file. If no %f, file will be the last arg
-my %fh = (
- text => {
- bin => [ "strings" ], # fallback for binary files
-
- txt => [ "cat" ], # Plain text
-
- html => [ "htm2txt",
- "html2text" ], # HTML
-
- msword => "doc",
- doc => [ "catdoc -x -dutf-8",
- "wvText",
- "antiword -w 72" ], # M$ Word
- "vnd.ms-excel" => "xls",
- "ms-excel" => "xls",
- docx => [ "unoconv -f text --stdout" ], # MS Word
- xlsx => "xls",
- xls => [ "xlscat -L",
- "catdoc -x -dutf-8",
- "wvText" ], # M$ Excel
-# ppt => [ "ppthtml" ], # M$ PowerPoint
-# ppthtml "$1" | html2text
- csv => "xls", # Comma Separated Values
-
- ics => [ "ics2txt" ], # ICS calendar request
-
- rtf => [ "rtf2text",
- "unrtf -t text" ], # RTF
- pdf => [ "pdftotext %f -" ], # Adobe PDF
-
- ods => "xls", # OpenOffice spreadsheet
- sxc => "xls", # OpenOffice spreadsheet
- odt => [ "oo2pod %f | pod2text",
- "ooo2txt" ], # OpenOffice writer
- rtf => [ "rtf2text" ], # RTF
-
- pl => [ "perltidy -st -se",
- "cat" ], # Perl
- pm => "pl",
-
- jsn => [ "json_pp" ], # JSON
- json => "jsn",
-
- xml => [ "xml_pp" ], # XML
-
- ( map { $_ => "txt" } qw(
- patch diff
- c h ic ec cc
- sh sed awk
- plain
- yml yaml
- )),
-
- bz2 => [ "bzip2 -d < %f | strings" ],
-
- zip => [ "unzip -l %f" ], # ZIP
-
- test => [ \&test ], # Internal
-
- tgz => [ "tar tvf" ], # Tar uncompressed
- tgz => [ "tar tzvf" ], # Tar GZ compressed
- tbz => [ "tar tjvf" ], # Tar BZip2 compressed
- txz => [ "tar tJvf" ], # Tar XZ compressed
-
- rar => [ "unrar l" ], # RAR
- },
-
- html => {
- rtf => [ "rtf2html" ],
- },
- );
-
-if ($opt_l) {
- my %tc = %{$fh{text}};
- foreach my $ext (sort keys %tc) {
- my $exe = $tc{$ext};
- ref $exe or $exe = $tc{$exe};
- printf " .%-12s %s\n", $ext, $_ for @$exe;
- }
- exit 0;
- }
-
-my $file = shift or usage (1, "File argument is missing");
--f $file or usage (1, "File argument is not a plain file");
--r $file or usage (1, "File argument is not a readable file");
--s $file or usage (1, "File argument is an empty file");
-
-my $ext = $file =~ m/\.(\w+)$/ ? lc $1 : "";
-$opt_t && exists $fh{text}{lc $opt_t} and $ext = lc$opt_t;
-unless (exists $fh{text}{$ext}) {
- my $ftype = `file --brief $file`;
- $ext =
- $ftype =~ m/^pdf doc/i ? "pdf" :
- $ftype =~ m/^ascii( english)? text/i ? "txt" :
- $ftype =~ m/^(utf-8 unicode|iso-\d+)( english)? text/i ? "txt" :
- $ftype =~ m/^xml doc/i ? "xml" :
- $ftype =~ m/^\w+ compress/i ? "bin" :
- "bin" ;
- # \w+ archive
- # \w+ image
- # ...
- }
-$ext ||= "txt";
-exists $fh{$opt_h}{$ext} or $opt_h = "text";
-exists $fh{$opt_h}{$ext} or $ext = "txt";
-my $ref = $fh{$opt_h}{$ext};
-ref $ref or $ref = $fh{$opt_h}{$ref};
-
-$opt_v and warn "[ @$ref ] $file\n";
-
-sub which {
- (my $cmd = shift) =~ s/\s.*//; # Only the command. Discard arguments here
- foreach my $path (split m/:+/, $ENV{PATH}) {
- -x "$path/$cmd" and return "$path/$cmd";
- }
- return 0;
- } # which
-
-my $cmd = "cat -ve";
-foreach my $c (@$ref) {
- if (ref $c) {
- $c->($file);
- exit;
- }
-
- my $cp = which ($c) or next;
- $cmd = $c;
- last;
- }
-
-my @cmd = split m/ +/ => $cmd;
-grep { s/%f\b/$file/ } @cmd or push @cmd, $file;
-#$cmd =~ s/%f\b/$file/g or $cmd .= " $file";
-$opt_v and say "@cmd";
-exec @cmd;
diff --git a/tools/textviewer.sh b/tools/textviewer.sh
@@ -1,243 +0,0 @@
-#!/usr/bin/env bash
-
-# textviewer.sh
-# Copyright 2003 Luke Plant <L.Plant.98@cantab.net>
-# and Johann Koenig <johann@mental-graffiti.com>
-
-# 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 Free Software Foundation; either version 3
-# of the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
-# 02111-1307, USA.
-
-##############################################################################
-#
-# This script is a text viewer designed to be used with claws-mail actions
-# Set up an action with the command line: textviewer.sh %p |
-#
-# The script will try to detect file type automatically, and then
-# invokes a relevant program to print the file in plain text to
-# the standard output.
-#
-# From v 0.9.7claws7, claws-mail sets the temporary file
-# of a part to XXXXXX.mimetmp.[filename of attachment]
-# This means we can use the extension of the filename for checking.
-# Also use the program 'file' if that fails.
-#
-# To extend the script just follow the patterns that already exist, or
-# contact the author if you have problems.
-
-##############################################################################
-#
-# Change Log
-#
-# 2003-03-25
-# - make extension matching case insensitive
-#
-# 2003-03-23
-# - Support for MS Excel (xlhtml) and Powerpoint (ppthtml)
-#
-# 2004-03-09
-# - Support for HTML (html2text)
-#
-# 2004-02-13
-# - added support for perl and shell scripts, and recognize that
-# 'file' will always return 'text' somewhere in its output for
-# files that, well, contain text
-#
-# 2004-01-25
-# - added brief messages describing whats going on
-#
-# 2004-01-23
-# - added support for 'pdftotext,' from xpdf-utils debian package
-#
-# 2004-01-05
-# - added matcher and action for OpenOffice Writer documents
-# (requires ooo2txt)
-#
-# 2004-01-05
-# - changed page width parameter for antiword
-# - fixed matcher for 'diffs'
-# - added a matcher and action for bzip2 - bzip2 files
-# are decompressed and textviewer.sh run on the result
-# - similarly decompress gzip files and run textviewer.sh
-# on the result, insteading of doing 'gzip -l'
-#
-# 2003-12-30
-# added the script to claws-mail/tools
-#
-# 2003-12-30
-# - use 'fold' after 'unrtf' to wrap to a nice width
-# - added basic file sanity checks
-#
-# 2003-12-29
-# Added recognition for "Zip " from 'file' output
-#
-# 2003-12-19
-# Initial public release
-#
-###############################################################################
-
-if [ $# -eq 0 ]
-then
- echo "No filename supplied." >&2
- echo "Usage: textviewer.sh FILE" >&2
- exit 1
-fi
-
-[ -f "$1" ] ||
-{
- echo "File \"$1\" does not exist or is not a regular file." >&2
- exit 1
-}
-
-[ -r "$1" ] ||
-{
- echo "Cannot read file \"$1\"." >&2
- exit 1
-}
-
-FILETYPE=`file --brief "$1"` ||
-{
- echo "Please install the command 'file' to use this script." >&2
- exit 1
-};
-
-FNAME=`echo "$1" | tr [A-Z] [a-z]`
-case "$FNAME" in
- *.doc) TYPE=MSWORD ;;
- *.ppt) TYPE=POWERPOINT ;;
- *.zip) TYPE=ZIP ;;
- *.tar.gz|*.tgz) TYPE=TARGZ ;;
- *.tar.bz2|*.tar.bz) TYPE=TARBZ ;;
- *.gz) TYPE=GZIP ;;
- *.bz2|*.bz) TYPE=BZIP ;;
- *.tar) TYPE=TAR ;;
- *.diff) TYPE=TEXT ;;
- *.txt) TYPE=TEXT ;;
- *.rtf) TYPE=RTF ;;
- *.sxw) TYPE=OOWRITER ;;
- *.pdf) TYPE=PDF ;;
- *.sh) TYPE=TEXT ;;
- *.pl) TYPE=TEXT ;;
- *.html|*.htm) TYPE=HTML ;;
- *.xls) TYPE=EXCEL ;;
-esac
-
-if [ "$TYPE" = "" ]
-then
- case $FILETYPE in
- *"HTML"*) TYPE=HTML ;;
- *"text"*) TYPE=TEXT ;;
- gzip*) TYPE=GZIP ;;
- bzip2*) TYPE=BZIP ;;
- "POSIX tar archive"*) TYPE=TAR ;;
- "Zip "*) TYPE=ZIP ;;
- "Rich Text Format"*)
- TYPE=RTF ;;
- esac
-fi
-
-case $TYPE in
- TARGZ) echo -e "Gzip'd tarball contents:\n" ;
- tar -tzvf "$1" ;;
-
- TARBZ) echo -e "Bzip'd tarball contents:\n" ;
- tar -tjvf "$1" ;;
-
- BZIP) TMP=`mktemp "$1".temp.XXXXXXX` || exit 1;
- bunzip2 -c "$1" > "$TMP" || exit 1;
- echo -e "Re-running \"$0\" on bunzip'd contents of \"$1\":\n";
- "$0" "$TMP";
- rm "$TMP" ;;
-
- GZIP) TMP=`mktemp "$1".temp.XXXXXXX` || exit 1;
- gunzip -c "$1" > "$TMP" || exit 1;
- echo "Re-running \"$0\" on gunzip'd contents of \"$1\":\n";
- "$0" "$TMP";
- rm "$TMP" ;;
-
- TAR) echo -e "Tar archive contents:\n" ;
- tar -tvf "$1" ;;
-
- ZIP) echo -e "Zip file contents:\n" ;
- unzip -l "$1" ;;
-
- RTF) which unrtf > /dev/null 2>&1 ||
- {
- echo "Program 'unrtf' for displaying RTF files not found" >&2
- exit 1
- };
- echo -e "Displaying \"$1\" using \"unrtf\":\n";
- unrtf -t text "$1" 2>/dev/null | egrep -v '^### ' | fold -s -w 72 ;;
-
- TEXT) cat "$1" ;;
-
- MSWORD) which antiword > /dev/null 2>&1 ||
- {
- echo "Program 'antiword' for displaying MS Word files not found" >&2
- exit 1
- };
- echo -e "Displaying \"$1\" using \"antiword\":\n";
- antiword -w 72 "$1" ;;
-
- POWERPOINT) which ppthtml > /dev/null 2>&1 ||
- {
- echo "Program 'ppthtml' for displaying Powerpoint files not found" >&2
- exit 1
- };
- which html2text > /dev/null 2>&1 ||
- {
- echo "Program 'html2text' for displaying Powerpoint files not found" >&2
- exit 1
- };
- echo -e "Displaying \"$1\" using \"ppthtml\" and \"html2text\":\n";
- ppthtml "$1" | html2text ;;
-
- EXCEL) which xlhtml > /dev/null 2>&1 ||
- {
- echo "Program 'xlhtml' for displaying Excel files not found" >&2
- exit 1
- };
- which html2text > /dev/null 2>&1 ||
- {
- echo "Program 'html2text' for displaying Excel files not found" >&2
- exit 1
- };
- echo -e "Displaying \"$1\" using \"xlhtml\" and \"html2text\":\n";
- xlhtml "$1" | html2text ;;
-
- OOWRITER) which ooo2txt > /dev/null 2>&1 ||
- {
- echo "Program 'ooo2txt' for converting OpenOffice Writer files not files not found" >&2
- exit 1
- };
- echo -e "Displaying \"$1\" using \"ooo2txt\":\n";
- ooo2txt "$1" ;;
-
- PDF) which pdftotext > /dev/null 2>&1 ||
- {
- echo "Program 'pdftotext' for converting Adobe Portable Document Format to text not found" >&2
- exit 1
- };
- echo -e "Displaying \"$1\" using \"pdftotext\":\n";
- pdftotext "$1" - ;;
-
- HTML) which html2text > /dev/null 2>&1 ||
- {
- echo "Program 'html2text' for converting HTML files not found" >&2
- exit 1
- };
- html2text -nobs "$1" ;;
-
- *) echo "Unsupported file type \"$FILETYPE\", cannot display.";;
-esac
diff --git a/tools/thunderbird-filters-convertor.pl b/tools/thunderbird-filters-convertor.pl
@@ -1,519 +0,0 @@
-#!/usr/bin/perl -w
-
-use strict;
-use Getopt::Long;
-use URI::Escape;
-
-# * This file is free software; you can redistribute it and/or modify it
-# * under the terms of the GNU General Public License as published by
-# * the Free Software Foundation; either version 3 of the License, or
-# * (at your option) any later version.
-# *
-# * This program is distributed in the hope that it will be useful, but
-# * WITHOUT ANY WARRANTY; without even the implied warranty of
-# * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# * General Public License for more details.
-# *
-# * You should have received a copy of the GNU General Public License
-# * along with this program; if not, write to the Free Software
-# * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-# *
-# * Copyright 2007 Paul Mangan <paul@claws-mail.org>
-# *
-
-#
-# Convert Thunderbird filtering rules to Claws Mail filtering rules
-#
-
-#
-# TABLE OF EQUIVALENTS
-#
-# thunderbird : Claws Mail
-#------------------------------------------------------
-#
-# name="NAME" : rulename "NAME"
-#
-# enabled="yes" : enabled / disabled
-#
-# CONDITION LIST
-# --------------
-#
-# OR : |
-# AND : &
-#
-# subject : subject
-# from : from
-# to : to
-# cc : cc
-# to or cc : to_or_cc
-# body : body-part
-# date : ****
-# priority : ****
-# status : ****
-# age in days : age_greater/age_lower
-# size : size_greater/size_smaller
-# [custom header] : header
-#
-# 2nd level conditions
-# --------------------
-#
-# contains : [nothing]
-# doesn't contain : [append with ~]
-# is : regexpcase
-# isn't : regexpcase
-# ends with : regexpcase
-# begins with : regexpcase
-# is in ab : found_in_addressbook
-# isn't in ab : ~found_in_addressbook
-#
-#
-# status 2nd and 3rd level conditions
-# -----------------------------------
-#
-# [is|isn't] replied
-# [is|isn't] read
-# [is|isn't] new
-# [is|isn't] forwarded
-# [is|isn't] flagged
-#
-#
-# Date header 2nd level condition
-# --------------------------------
-#
-# is
-# isn't
-# is before
-# is after
-#
-#
-# Priority header 2nd and 3rd level conditions
-# --------------------------------------------
-# is [Lowest|Low|Normal|High|Highest]
-# is higher than [Lowest|Low|Normal|High|Highest]
-# is lower than [Lowest|Low|Normal|High|Highest]
-#
-#
-# ACTION LIST
-# -----------
-#
-# Move to folder : move
-# Copy to folder : copy
-# Forward : ****
-# Reply : ****
-# Mark read : mark_as_read
-# Mark flagged : mark
-# Label : ****
-# Change priority : ****
-# JunkScore 100 [mark as spam] : ****
-# JunkScore 0 [mark as ham] : ****
-# Delete : delete
-# Delete from Pop3 server : delete
-# Fetch body from Pop3Server : ****
-#
-
-my $script = "thunderbird-filters-convertor.pl";
-my ($tbirdfile, $account, $mailbox, $iNeedHelp) = 0;
-
-GetOptions("tbird-file=s" => \$tbirdfile,
- "account-name=s" => \$account,
- "mailbox-name=s" => \$mailbox,
- "help|h" => \$iNeedHelp);
-
-if ($iNeedHelp) {
- help_me();
-}
-
-if (!$tbirdfile) {
- print "ERROR: No filename given\n";
- print "Use $script -h for help\n";
- exit;
-}
-
-unless (-e $tbirdfile) {
- print "ERROR: $tbirdfile NOT FOUND!!\n";
- exit;
-}
-
-if (!$mailbox) {
- print "ERROR: No mailbox name given\n";
- print "Use $script -h for help\n";
- exit;
-}
-
-my $config_dir = `claws-mail --config-dir` or die("ERROR:
- You don't appear to have Claws Mail installed\n");
-chomp $config_dir;
-
-chdir($ENV{HOME} . "/$config_dir") or die("ERROR:
- Claws Mail config directory not found [~/$config_dir]
- You need to run Claws Mail once, quit it, and then re-run this script\n");
-
-my $acrc = "accountrc";
-my $acc_number;
-
-if ($account) {
- $acc_number = find_account_number();
-}
-if ($account && !$acc_number) {
- print "ERROR: Account '$account' NOT FOUND!\n";
- exit;
-}
-
-my @claws_filters = ();
-
-## check if matcherrc already exists
-if (-e "matcherrc") {
- print "matcherrc exists!\n";
- read_current_filters();
-} else {
- push(@claws_filters, "[preglobal]\n\n[postglobal]\n\n[filtering]\n")
-}
-##
-my ($rule_count,@thunderbird_filters) = read_thunderbird_filters();
-
-my ($conv_rule,$ignored_rule,$ignore_list) = convert_filters($rule_count,@thunderbird_filters);
-
-if (@claws_filters) {
- system("mv matcherrc matcherrc-safecopy");
- print "Moved ". $ENV{HOME}. "/$config_dir/matcherrc to "
- . $ENV{HOME}. "/$config_dir/matcherrc-safecopy\n";
-}
-# write new config
-open(MATCHERRC, ">>matcherrc");
- print MATCHERRC @claws_filters;
-close(MATCHERRC);
-
-print "We're done!\n";
-print "-------------\n";
-print "Converted $conv_rule rules";
-if (defined($ignored_rule)) {
- print ", ignored $ignored_rule rules";
-}
-print "\n-------------\n";
-print "$ignore_list";
-
-exit;
-
-sub help_me {
- print<<'EOH';
-Usage:
- thunderbird-filters-convertor.pl [options]
-Options:
- --help -h Show this screen.
- --tbird-file=PATH TO FILE The full path to the file to be converted
- --mailbox-name=NAME The name of the Claws Mail mailbox
- --account-name=NAME The name of the account to be used (optional)
-EOH
-exit;
-}
-
-sub find_account_number {
- my $cur_acc_numb;
- my $cur_acc_name;
-
- open (ACCOUNTRC, "<$acrc") ||
- die("Can't open the Accounts file [$acrc]\n");
- my @acrclines = <ACCOUNTRC>;
- close ACCOUNTRC;
-
- foreach my $line (@acrclines) {
- unless ($line =~ m/^\[Account/ ||
- $line =~ m/^account_name/) { next; }
- chomp($line);
-
- if ($line =~ s/^\[Account: //) {
- $line =~ s/]$//;
- $cur_acc_numb = $line;
- }
- if ($line =~ s/^account_name=//) {
- $cur_acc_name = $line;
- }
- if (defined($cur_acc_name) && $cur_acc_name eq $account) {
- return($cur_acc_numb);
- }
- }
-}
-
-sub read_current_filters {
- print "Reading current filters\n";
-
- open (CFILTERS, "<matcherrc") ||
- die("Can't open " . $ENV{HOME} . "/$config_dir/matcherrc");
- @claws_filters = <CFILTERS>;
- close CFILTERS;
-
- remove_last_empty_lines();
-}
-
-sub remove_last_empty_lines {
- my $line = pop(@claws_filters);
- if ($line =~ m/^$/) {
- remove_last_empty_lines();
- } else {
- push(@claws_filters, $line);
- }
-}
-
-sub read_thunderbird_filters {
- my @outer_array = ();
- my @inner_array = ();
- my $count = 0;
-
- open (TBIRDFILE, "<$tbirdfile") ||
- die("Can't open the tbird file [$tbirdfile]\n");
- my @tbirdlines = <TBIRDFILE>;
- close TBIRDFILE;
-
- foreach my $line (@tbirdlines) {
- if ($line =~ m/^version/ || $line =~ m/^logging/) { next; }
-
- chomp($line);
-
- push(@inner_array, "$line") unless $line eq "";
- if ($line =~ m/^condition/) {
- push(@outer_array, [@inner_array]);
- @inner_array = ();
- $count++;
- }
- }
- return($count-1,@outer_array);
-}
-
-sub convert_filters {
- my ($rule_count,@thunderbird_filters) = @_;
-
- my $tbird_action_no_value = qr/^(?:"Mark read"|"Mark flagged"|"Delete"|"Delete from Pop3 server"|"Fetch body from Pop3Server")$/;
- my $tbird_action_ignore = qr/^(?:"Label"|"Change priority"|"JunkScore"|"Fetch body from Pop3Server"|"Delete from Pop3 server"|"Reply")$/;
- my $exact_matches = qr/^(?:subject|from|to|cc)$/;
- my $ignore_matches = qr/^(?:date|priority|status)$/;
-
- my $conv_rules = my $ignored_rules = 0;
- my $ignored_list = "";
- for (my $outerloop = 0; $outerloop <= $rule_count; $outerloop++) {
- my $part_one = my $part_two = my $part_three = my $part_four = "";
- my $ignore_rule = my $move_rule = my $copy_rule = my $cond_count = 0;
- my %ignore_hash;
- my $bool = my $claws_condition = my $cur_name = "";
- for (my $innerloop = 0; exists($thunderbird_filters[$outerloop][$innerloop]); $innerloop++) {
- my $entry = $thunderbird_filters[$outerloop][$innerloop];
- if ($entry =~ s/^name=//) {
- $cur_name = $entry;
- $part_one = "rulename $entry ";
- } elsif ($entry =~ s/^enabled=//) {
- if ($entry eq "\"yes\"") {
- $part_one = "enabled $part_one";
- } else {
- $part_one = "disabled $part_one";
- }
- if (defined($acc_number)) {
- $part_one .= "account $acc_number ";
- }
- } elsif ($entry =~ s/^type=//) {
- # do nothing : what does 'type' mean??
- } elsif ($entry =~ s/^action=//) {
- if ($entry =~ m/$tbird_action_ignore/ && !$ignore_rule) {
- $ignore_rule = 1;
- unless ($ignore_hash{$cur_name}) {
- $ignored_list .= "Ignored $cur_name because it contains $entry\n";
- $ignored_rules++;
- }
- $ignore_hash{$cur_name}++;
- $part_one = "";
- next;
- } elsif ($entry =~ m/Move to folder/) {
- $part_four = "move ";
- $move_rule = 1;
- } elsif ($entry =~ m/Copy to folder/) {
- $part_three .= "copy";
- $copy_rule = 1;
- } elsif ($entry =~ m/Mark read/) {
- $part_three .= "mark_as_read ";
- } elsif ($entry =~ m/Mark flagged/) {
- $part_three .= "mark";
- } elsif ($entry =~ m/Delete/) {
- $part_three .= "delete";
- }
- } elsif ($entry =~ s/^actionValue=//) {
- if ($ignore_rule) {
- $ignore_rule = 0;
- next;
- } elsif ($move_rule) {
- $entry = rewrite_mailbox_name($entry);
- $part_four .= uri_unescape($entry);
- $move_rule = 0;
- } elsif ($copy_rule) {
- $entry = rewrite_mailbox_name($entry);
- $part_three .= " " . uri_unescape($entry);
- $copy_rule = 0;
- }
- } elsif ($entry =~ s/^condition=//) {
- if ($entry =~ s/^\"AND//) {
- $bool= "&";
- } elsif ($entry =~ s/^\"OR//) {
- $bool = "|";
- }
- my @tbird_conditions = split(/ \(/, $entry);
- foreach my $cond (@tbird_conditions) {
- my $exact = my $endswith = my $beginswith = my $addrbook = 0;
- my $age_condition = my $size_condition = my $exact_age = 0;
- $cond =~ s/\) OR$//;
- $cond =~ s/\) AND$//;
- $cond =~ s/\)"$//;
- $cond =~ s/\\"/"/g;
- my ($cpart_one, $cpart_two, $cpart_thr) = split(/,/, $cond, 3);
- if ($cond) {
- if ($cpart_one =~ m/$exact_matches/) {
- $claws_condition .= "$cpart_one";
- } elsif ($cpart_one eq "to or cc") {
- $claws_condition .= "to_or_cc";
- } elsif ($cpart_one eq "body") {
- $claws_condition .= "body-part";
- } elsif ($cpart_one eq "age in days") {
- $age_condition = 1;
- } elsif ($cpart_one eq "size") {
- $size_condition = 1;
- } elsif ($cpart_one =~ m/$ignore_matches/) {
- $part_one = $claws_condition = $part_three = $part_four = "";
- next;
- } else {
- $claws_condition = "header $cpart_one";
- }
-
- if ($cpart_two eq "doesn't contain") {
- $claws_condition = "~$claws_condition matchcase";
- } elsif ($cpart_two eq "contains") {
- $claws_condition = "$claws_condition matchcase";
- } elsif ($cpart_two eq "isn't") {
- $exact = 1;
- $claws_condition = "~$claws_condition regexpcase";
- } elsif ($cpart_two eq "is") {
- if ($size_condition) {
- $claws_condition .= "size_equal";
- } elsif ($age_condition) {
- if ($bool ne "&") {
- $part_one = $claws_condition = $part_three = $part_four = "";
- if (!$ignored_list) {
- $ignored_list .= "Ignored $cur_name because it matches an exact age and is an OR match\n";
- }
- next;
- } else {
- $ignored_rules--;
- $exact_age = 1;
- }
- } else {
- $exact = 1;
- $claws_condition = "$claws_condition regexpcase";
- }
- } elsif ($cpart_two eq "ends with") {
- $endswith = 1;
- $claws_condition = "$claws_condition regexpcase";
- } elsif ($cpart_two eq "begins with") {
- $beginswith = 1;
- $claws_condition = "$claws_condition regexpcase";
- } elsif ($cpart_two eq "is in ab") {
- $addrbook = 1;
- $claws_condition = "found_in_addressbook \"$claws_condition\" in \"Any\" ";
- } elsif ($cpart_two eq "isn't in ab") {
- $addrbook = 1;
- $claws_condition = "~found_in_addressbook \"$claws_condition\" in \"Any\" ";
- } elsif ($cpart_two eq "is greater than") {
- if ($size_condition) {
- $claws_condition .= "size_greater";
- }
- if ($age_condition) {
- $claws_condition .= "age_greater";
- }
- } elsif ($cpart_two eq "is less than") {
- if ($size_condition) {
- $claws_condition .= "size_smaller";
- }
- if ($age_condition) {
- $claws_condition .= "age_lower";
- }
- }
-
- if ($exact || $beginswith || $endswith) {
- $cpart_thr = escape_regex($cpart_thr);
- }
- if ($exact) {
- $cpart_thr = "^$cpart_thr\$";
- } elsif ($beginswith) {
- $cpart_thr = "^$cpart_thr";
- } elsif ($endswith) {
- $cpart_thr = "$cpart_thr\$";
- }
- unless ($addrbook) {
- if ($exact_age) {
- my $lower_limit = $cpart_thr-1;
- my $upper_limit = $cpart_thr+1;
- $lower_limit =~ s/^\"//;
- $lower_limit =~ s/\"$//;
- $upper_limit =~ s/^\"//;
- $upper_limit =~ s/\"$//;
- $claws_condition = "$claws_condition"."age_lower"
- . " $upper_limit $bool "
- . "age_greater $lower_limit ";
- } elsif ($size_condition || $age_condition) {
- $claws_condition = "$claws_condition $cpart_thr ";
- } else {
- $claws_condition = "$claws_condition \"$cpart_thr\" ";
- }
- }
-
- if ($tbird_conditions[1] && $cond_count < $#tbird_conditions) {
- $claws_condition = "$claws_condition$bool ";
- }
- }
- $cond_count++;
- }
- if ($part_one) {
- $conv_rules++;
- push(@claws_filters, "$part_one$claws_condition$part_three$part_four\n");
- }
- }
- }
- }
- push(@claws_filters, "\n");
- return($conv_rules,$ignored_rules,$ignored_list);
-}
-
-sub rewrite_mailbox_name {
- my ($path) = @_;
-
- my $new_path;
-
- my ($front,$back) = split(/\/\//, $path, 2);
-
- if ($front =~ m/^"mailbox/) {
- $new_path = "\"#mh/$mailbox/";
- } else {
- $new_path = "\"#imap/$mailbox/";
- }
-
- my ($box,$name) = split(/\//, $back, 2);
-
- if ($new_path =~ m/^"#mh/) {
- $name =~ s/^Inbox/inbox/;
- $name =~ s/^Sent/sent/;
- $name =~ s/^Drafts/draft/;
- $name =~ s/^Trash/trash/;
- }
- $new_path = $new_path.$name;
-
- return($new_path);
-}
-
-sub escape_regex {
- my ($string) = @_;
-
- my $escstr = "";
- my $symbols = qr/^(?:\[|\]|\{|\}|\(|\)|\||\+|\*|\.|\-|\$|\^)$/;
- my @chars = split(//, $string);
-
- foreach my $char (@chars) {
- if ($char =~ m/$symbols/) { $char = "\\\\$char"; }
- $escstr .= $char;
- }
-
- return($escstr);
-}
diff --git a/tools/update-po b/tools/update-po
@@ -1,66 +0,0 @@
-#!/bin/sh
-
-# * Copyright © 2002 Wilbert Berendsen <wilbert@oswf.org>
-# *
-# * This file is free software; you can redistribute it and/or modify it
-# * under the terms of the GNU General Public License as published by
-# * the Free Software Foundation; either version 3 of the License, or
-# * (at your option) any later version.
-# *
-# * This program is distributed in the hope that it will be useful, but
-# * WITHOUT ANY WARRANTY; without even the implied warranty of
-# * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# * General Public License for more details.
-# *
-# * You should have received a copy of the GNU General Public License
-# * along with this program; if not, write to the Free Software
-# * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-# *
-
-# update-po -- for Claws Mail
-# by Wilbert Berendsen
-# This script updates the .po files named on the command line.
-# Run this script from within the po/ directory!
-
-if [ "$1" -a -f "$1" ] ; then
-
-
- #
- # Make a messages.pot file containing all the msgid's from
- # the source
-
- make -C .. -f - <<EOF
-
-sources = \$(shell cat po/POTFILES.in)
-po/messages.pot: \$(sources) po/POTFILES.in
- xgettext --keyword=N_ --keyword=_ --keyword=Q_ --file=po/POTFILES.in \
- --output=po/messages.pot
-EOF
-
- #
- # Update all the xx.po files named on the commandline.
-
- for po in $@ ; do
-
- # Save xx.po in xx.po.old
-
- cp $po $po.old
- echo "Updating $po..."
- msgmerge $po.old messages.pot > $po
- done
-
-else
-
- echo
- echo "Usage:"
- echo
- echo " ./`basename $0` lang.po lang2.po ..."
- echo
- echo "to update one or more <yourlang>.po files from the sourcecode files"
- echo "named in POTFILES.in. The old .po file is save in a .po.old file."
- echo
- echo "When you e.g. want to update fr.po, run ./`basename $0` fr.po, then"
- echo "edit fr.po to update your translation."
- echo
-
-fi
diff --git a/tools/uudec b/tools/uudec
@@ -1,2 +0,0 @@
-#!/bin/sh
-uudecode -o - "$1" | display -
diff --git a/tools/uuooffice b/tools/uuooffice
@@ -1,25 +0,0 @@
-#!/bin/sh
-
-# * Copyright 2005 Tristan Chabredier <wwp@claws-mail.org>
-# *
-# * This file is free software; you can redistribute it and/or modify it
-# * under the terms of the GNU General Public License as published by
-# * the Free Software Foundation; either version 3 of the License, or
-# * (at your option) any later version.
-# *
-# * This program is distributed in the hope that it will be useful, but
-# * WITHOUT ANY WARRANTY; without even the implied warranty of
-# * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# * General Public License for more details.
-# *
-# * You should have received a copy of the GNU General Public License
-# * along with this program; if not, write to the Free Software
-# * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-#
-# uuooffice helper script to open documents attached to emails with OpenOffice
-
-FILENAME=$(grep -Em 1 "^begin [0-7][0-7][0-7] ." "$1" | cut -d ' ' -f 3-)
-TMPFILE=/tmp/${0##*/}_$FILENAME
-uudecode -o - "$1" > "$TMPFILE"
-ooffice "$TMPFILE"
-rm -f "$TMPFILE"
diff --git a/tools/vcard2xml.py b/tools/vcard2xml.py
@@ -1,310 +0,0 @@
-#!/usr/bin/env python3
-# -*- coding: latin-1 -*-
-"""
-
-Copyright © 2003 Bogdan Sumanariu <zarrok@yahoo.com>
-
- This file is free software; you can redistribute it and/or modify it
- under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 3 of the License, or
- (at your option) any later version.
-
- This program is distributed in the hope that it will be useful, but
- WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-
- script name : evolutionvcard2claws.py
-
- script purpose : convert an evolution addressbook VCARD file
- into a Claws Mail addressbook
-
- tested with evolution 1.2.x, and 1.4.x
-
-"""
-
-import string
-import sys
-import time
-import os
-from io import StringIO
-
-keywds = ('x-evolution-file-as','fn', 'n','email;internet','nickname', 'url', 'org')
-
-def normalizeLongLines(file):
- """
- Skip line breaks after 72 chars
- """
- buf = ''
-
- line = file.readline()
- while line:
- if line[0] == ' ':
- buf = buf.rstrip('\n')
- line = line.lstrip();
- buf += line
- else:
- buf += line
- line = file.readline()
-
- return buf
-
-def getEmailAddress(vcard):
- """
- Get email address.
- Supported formats:
- - email;something
- - email;type=something
- something := (internet,work,home, other)
- """
-
- for key in vcard:
- items = key.split(';')
- if len(items) == 2:
- if items[0].lower() == 'email':
- list = vcard[key]
- return list[0]
- else:
- if key.lower() == 'email':
- list = vcard[key]
- return list[0]
-
- return ""
-
-def findName(vcard):
- """
- Find a version 3.0 name
- """
- for key in vcard:
- items = key.split(';')
- if len(items) == 2:
- if items[0].lower() == 'n':
- return vcard[key]
- else:
- if key.lower() == 'n':
- return vcard[key]
-
- return None
-
-################################################################################
-## reads a vcard and stores as hash pairs key/value where value is a list ##
-################################################################################
-
-def readVCARD (buffer) :
-
- """
-
- skips fom <file> until a 'begin' tag from VCARD is encountered.
- from this point starts constructing a map (key, [values] )
- VCARD entry format -> tag:value
-
- key <- tag
- [values] <- list with the values of <tag> if there are more tags with the same name
-
- """
- r=' '
- bgn,end = -1, -1;
- d = dict()
- while r and bgn < 0 :
- r = buffer.readline()
- if len (r) == 0 : return dict()
- if r.strip().lower().find('begin') :
- bgn = 1
- while r and end < 0 :
- r = buffer.readline()
- s = r.strip().lower().split(':')
- if s[0] != '' :
- if s[0] in d :
- d[s[0]].append(s[1])
- elif len(s) > 1:
- d[s[0]] = [s[1]]
- else :
- d[s[0]] = ['']
- if s[0] == 'end' : end = 1
- return d
-
-##################################################################################
-
-###############################################################################################
-## writes on a given file an xml representation for claws-mail addressbook received as a hash ##
-###############################################################################################
-
-def writeXMLREPR (vcard,file,uid) :
-
- """
- based on <vcard> and <uid> writes only recognized tags (the ones defined in <keywds> list)
- NOTE: <url> and <org> tag will be written as attributes (there are such tags in claws-mail's
- XML schema)
- """
- if len (vcard.keys()) == 0 : return
- item = vcard.get(keywds[2]);
- if item:
- name = item[0].split(';')
- else:
- """ version 3.0 n ?"""
- name = findName(vcard)
- if not name:
- return
-
- fn, ln, nick, cn, a = '', '', '', '', ''
-
- if len(name) >= 2 :
- fn = name[0]
- ln = name[1]
- elif len(name) ==1 :
- fn = name[0]
-
- if keywds[4] in vcard :
- nick = vcard.get(keywds[4])[0]
- if len(vcard.get(keywds[1])[0]) :
- cn = vcard.get(keywds[1])[0]
- else :
- cn = vcard.get(keywds[0])[0];
-
- a += str('\n<person uid=\"' + str(uid[0]) + '\" first-name=\"' + fn + '\" last-name=\"' + ln
- + '\" nick-name=\"' + nick + '\" cn=\"' + cn + '\" >\n')
- a += '\t<address-list>\n'
- if vcard.get(keywds[3]) :
- for c in vcard.get(keywds[3]) :
- uid[0] = uid[0] + 1
- a += '\t\t<address uid=\"' + str(uid[0]) + '\" alias=\"' + nick + '\" email=\"' + c + '\" remarks=\"\" />\n'
- else :
- email = getEmailAddress(vcard)
- uid[0] = uid[0]+1
- a += '\t\t<address uid=\"' + str(uid[0]) + '\" alias=\"' + nick + '\" email=\"' + email + '\" remarks=\"\" />\n'
- a += '\t</address-list>\n'
- a += '\t<attribute-list>\n'
- for key in keywds[5:] :
- if vcard.get(key) :
- for c in vcard.get(key) :
- uid[0] = uid[0] + 1
- a += '\t\t<attribute uid=\"' + str(uid[0]) + '\" name=\"' + key +'\">'+c+'</attribute>\n'
- a += '\t</attribute-list>\n'
- a += '</person>\n'
- file.write(a)
- file.flush()
-
-###################################################################################################
-
-def convert (in_f, o_f, name='INBOX') :
- d = {'d':1}
- uid = [int(time.time())]
-
- try :
- print('proccessing...\n')
- o_f.write('<?xml version="1.0" encoding="ISO-8859-1" ?>\n<address-book name="'+name+'" >\n');
-
- buf = normalizeLongLines(in_f)
- buffer = StringIO(buf)
- while len(d.keys()) > 0 :
- d = readVCARD(buffer)
- writeXMLREPR (d, o_f, uid)
- uid[0] = uid [0]+1
-
- o_f.write('\n</address-book>')
- print('finished processing...\n')
- except IOError as err :
- print('Caught an IOError : ',err,'\t ABORTING!!!')
- raise err
-
-#################################################################################################
-
-def execute () :
- if len(sys.argv) != 3 and len(sys.argv) != 2 :
- print(str("\nUsage: vcard2xml.py source_file [destination_file]\n\n" +
- '\tWhen only <source_file> is specified will overwrite the existing addressbook.\n'+
- '\tWhen both arguments are suplied will create a new additional addressbook named \n\tas the destination file.'+'\n\tNOTE: in both cases the Claws Mail must be closed and ran at least once.\n\n'))
- sys.exit(1)
-
- in_file = None
- out_file = None
- path_to_out = os.environ['HOME']+'/.claws-mail/addrbook/'
- adr_idx = 'addrbook--index.xml'
- adr_idx_file = None
- tmp_adr_idx_file= None
- got_ex = 0
-
- try :
- in_file = open(sys.argv[1])
- except IOError as e:
- print('Could not open input file <',sys.argv[1],'> ABORTING')
- sys.exit(1)
-
- if len(sys.argv) == 2 :
- try :
- dlist = os.listdir(path_to_out);
- flist=[]
- for l in dlist :
- if l.find('addrbook') == 0 and l.find("addrbook--index.xml") < 0 and l.find('bak') < 0 :
- flist.append(l)
- flist.sort()
- out_file = flist.pop()
- os.rename(path_to_out+out_file, path_to_out+out_file+'.tmp')
- out_file = open(path_to_out+out_file,'w')
- convert(in_file, out_file)
- except Exception as e:
- got_ex = 1
- print('got exception: ', e)
- else :
- try :
- os.rename(path_to_out+adr_idx, path_to_out+adr_idx+'.tmp')
- tmp_adr_idx_file = open(path_to_out+adr_idx+'.tmp')
- adr_idx_file = open(path_to_out+adr_idx,'w')
- except Exception as e :
- print('Could not open <', path_to_out+adr_idx,'> file. Make sure you started Claws Mail at least once.')
- sys.exit(1)
- try :
- out_file = open(path_to_out+sys.argv[2],'w')
- convert(in_file, out_file, sys.argv[2].split('.xml')[0])
- l = tmp_adr_idx_file.readline()
- while l :
- if l.strip() == '</book_list>' :
- adr_idx_file.write('\t<book name="'+sys.argv[2].split('.xml')[0] +'" file="'+sys.argv[2]+'" />\n')
- adr_idx_file.write(l)
- else :
- adr_idx_file.write(l)
- l = tmp_adr_idx_file.readline()
- except Exception as e:
- got_ex = 1
- print('got exception: ', e)
-
-
- if got_ex :
- #clean up the mess
- print('got exception, cleaning up the mess... changed files will be restored...\n')
- if adr_idx_file :
- adr_idx_file.close()
- if out_file :
- out_file.close()
- if len(sys.argv) == 2 :
- os.rename(out_file.name+'.tmp', out_file.name)
- else :
- os.remove(out_file.name)
- os.rename(path_to_out+adr_idx+'.tmp', path_to_out+adr_idx)
- if tmp_adr_idx_file :
- tmp_adr_idx_file.close()
-
- else :
- #closing all and moving temporary data into place
- print('closing open files...\n')
- in_file.close()
- out_file.close()
- if len(sys.argv) == 3 :
- os.rename(path_to_out+adr_idx+'.tmp',path_to_out+adr_idx+'.bak' )
- if len(sys.argv) == 2 :
- os.rename(out_file.name+'.tmp', out_file.name+'.bak')
- if adr_idx_file :
- adr_idx_file.close()
- if tmp_adr_idx_file :
- tmp_adr_idx_file.close()
- print('done!')
-
-
-if __name__ == '__main__':
- execute ()
-
-
